Slashdot Mirror
eFax Hell?
RH Wesson asks: "We use eFax to distribute a 3 page fax once a week to about 75 customers of ours. Yesterday we uploaded a postscript version of our 3 page fax instead of the usual PDF version using the eFax Manager on Windows. We started getting calls from our customers about a 300+ page fax of garbage (it was really postscript source) We spent hours with eFax requesting them to stop the sending of the garbage. eFax was never able to stop it, in fact we spent hours trying to determine if the fax was even in their queue. In short we lost a lot of business that day and managed to piss off ALL of our customers at once. We are going back to using a regular fax machine. Has anyone else had a situation where the danger of technology loosing you business outweigh the efficiencies gained?"
It sounds like you didn't do much testing. I write programs to do jobs at my work, and though I believe in my abilities, I also don't believe I'm God. Therefore, I test everything thoroughly before I use them in production. And I'm public sector. In the private sector, it's even more crucial as your customers can actually walk away.
You should've tested this new fax technology, in house and then by setting up a group of "special" customers (give them a small discount as incentive) to beta test it with (and since they know there could be errors and they are being compensated, they won't be pissed when there are bugs). After the new fax technology works for a month or two (depending on how much it's used), then, and only then, begin using for everyone. Repeat this procedure on a smaller scale if you are using the software in a never-before-used-way. This technique really goes for most technology.
-- Political fascism requires a Fuhrer.
That's why businesses have policies, procedures, rules, and those sorts of things. I realize they're no fun, but they prevent shit like that from happening.
Was your switch to eFax just a whim too? I certainly hope not. Was the first thing you sent through it a full-scale mailing to all your clients? I certainly hope not.
Blaming and dumping eFax is not the solution here. You should've tested your change in procedure. They worked fine with the old procedure. If your your office building burned down, would you move all 50 people back to your company's old 4-person office because it never had that problem?
Random and weird software I've written.
I have to admit that I have experienced my share of frustration with EFax but this question rings of retribution more than a real request for answers.
Has anyone else had a situation where the danger of technology loosing you business outweigh the efficiencies gained?
If the tech industry will continue to be ruled by Business Major idiots, we'll see this every day or every week, and more of it all the time... *sigh*
I've been in the business for only 10 years, but I've seen this stuff every-day...
I understand your position and agree with it. But underlying the position is the assumption that the basic technology can't be trusted because it sometimes just doesn't work.
This is limitation resulting from first generation 20th century software. 21st century software will note that a person is sending an unusually large document and check (using OCR and a spell checker in the local language on the random portions of the file) to see if it is a rogue transmission (like the common occurance cited above of a PDF document misformatted as a PS). The eFax will communicate (why not with a voice synthesized cell phone message?) with the sender that a rogue document is queued.
It is the responsibility of the users of 20th century office equipment to guard against runaway applications like this. But it is the responsibility of the sellers of 21st century business solutions like eFax to incorporate advanced error checking like this into their product. As we enter the age of 4GHz CPU speeds, 128 bit processors, terabyte hard drives, and GigaByte RAM banks, our PCs demand truly advanced software too.
So I'm going to go against your decision that this was the customer's fault for not closely monitoring a format change. I believe that it's partially eFax's fault for not coding their service against a common and catostophic client error.
Programmers need to get out of the 20th century mindset that if a program works in the software lab then it is finished. Actually by 21st century standards, its development has simply completed the first and easest phase. It now needs to be developed so that it works flawlessly in the bizarre and common error situations found in the field.
That still doesn't answer the question of why switch from a format known to work to another without testing it. This is a production system. Someone wasn't thinking and they want eFax to take all the blame rather than own up to their share of it.
Lasers Controlled Games!
"So I'm going to go against your decision that this was the customer's fault for not closely monitoring a format change"
It's a case of "caveat emptor", or "let the buyer beware": on the one hand, you could blame eFax for the fault, but at the same time, as anyone who deals with business software knows, you always test first.
So I'm going to go against your decision that this was the customer's fault for not closely monitoring a format change. I believe that it's partially eFax's fault for not coding their service against a common and catostophic client error.
No, eFax's software did *exactly* what it is supposed to do. It is *designed* to accept text input as well as PDF, but not PostScript. This is not a bug, but a feature - you can very easily send faxes just by generating a regular ASCII text file. The PostScript output is one big, honking, ugly text file, which eFax's software sent exactly as the careless poster asked it to...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
Back in the Stone Age, when I ran batch jobs on mainframes, it was common feature of the operating system to automatically abort any jobs that exceeded their resource limits. The resources were things like CPU time, memory usage, number of pages printed. There were default values for the limits and the limits could be modified by Job Control Language directives included at the beginning of the job. The default values were large enough for most jobs, but small enough to quickly kill jobs that were malfunctioning due to bugs or bad input data. This was important because usage of the mainframe's resources was billed back to the user. It prevented a runaway job from wiping out an individual's or department's budget for computer use. Without these limits, one run of a buggy program could exhaust a student's entire allocation of computer usage for a semester.
The point is that people make mistakes, and these mistakes are often predictable. Designing the system to limit the damage caused by a mistake is just good engineering.
Mea navis aericumbens anguillis abundat