There has been a lot of negative sentiment on technical support and customer care representatives lately. I’ve voiced some frustration with Sprint’s front-line technical support staff before. Poor customer service over the phone has also been publicized with Vincent Ferrari’s AOL episode as well as a recent video taping of a Comcast technician sleeping on a customer’s couch while waiting for assistance from his peers. Because people are likely driven by self-interest, there really is no reason for customers to give feedback for anything other than complaints.
This entry bucks the trend. I was recently frustrated with my DSL connection. I have had this connection for almost three years, and I have never before had a problem. My connection started dropping multiple times throughout each day. I reached for technical support at AT&T (formerly SBC). The phone support was mediocre, but the people that provided service at my house were exceptional technicians. Both of these technicians did their job above my expectations and perhaps outside of their protocol.
Now, my connection is stable, and I am a content customer once again. Their equipment may or may not have been faulty, but my home’s phone wiring is a more likely cause of the service disruptions. There were two ways to resolve the problem: go with cable or fix my inside wiring. Since the necessary wires were readily available, ahem, my inside wiring was fixed quickly.
In Tales of Vista development at MSFT, Scott Berkun finds a money quote from a former Vista development manager. After finding resistance when reporting the truth, particularly of but not limited to slipping project schedules, engineers tend to fold. Travel 3,000 miles on foot within 2 hours? You, got it boss!
An article claims that Backward Switches Doomed Probe. This does not mean that Lockheed Martin’s engineers are incompetent. Aerospace engineers are highly respected for the engineering problems they have solved and continually face. The article, instead, discusses the possibility that time and cost constraints on the production of the probe resulted in the probe’s failure. This brings to mind a chef analogy that I consistently use to control production schedules and damper client demands for immediate results.
Fred Brooks states in The Mythical Man-Month:
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it is not set in two minutes, the customer has two choices–wait or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save–burned in one part, raw in another.
Although euphoria or a sense of power may be experienced by tightening a production schedule, doing so for artificial reasons unnecessarily minimizes a key resource that is available to an engineer for producing a quality system. Engineers pride themselves on the quality of their work. They gain pride in developing efficient systems in an efficient manner. Time is a fundamental resource used throughout the development effort. Most time is spent on coordination and planning to minimize the amount of time that is used on implementation and error correction. If an engineer takes time in implementing a system, it is simply because the engineer is building a system that works well. Fred Brooks notes, “More software projects have gone awry for lack of calendar time than for all other causes combined.”
After setting up and testing network monitoring software for one of our co-lo sites, it became apparent that mx.messaging.sprintpcs.com was rejecting connections from the monitoring server. I used typical methods, which include using telnet to connect to the SMTP port while analyzing the connection with a packet sniffer, to determine that the problem was with Sprint’s messaging server. It is fairly obvious that mx.messaging.sprintpcs.com closes the connection immediately after the initial TCP connection handshake. Another person shares his experience with this problem, and he can only wish that others fare better than him.
Dealing with Sprint’s front line technical support is pretty wearisome. The experience parallels the “our computer must be right (and you must be wrong)” scenario that was popularized throughout the 80s. One support representative stated, “You’re doing too much to send out text messages and making it hard for yourself.” I expressed my opinion that I would be better served by a person who did not see difficulty in resolving the problem. I was later contacted by a network engineer with knowledge of Internet protocols and using SMS over their SMTP server. He was better equipped to investigate the problem on their side, and he was very capable of helping me with any issues on my side. He actually introduced me to SenderBase, a spam monitoring service that is supposedly used by many large ISPs to minimize spam. The problem was ultimately resolved, and I continue to be a content Sprint subscriber.
One thing that I relearned from the front line technical support representative is the need to treat every problem with some attention. Because a problem seems typical, it is easy to resort to scripted responses. This might be a knee-jerk reaction that is rooted in a combination of both laziness and misplaced pride. Over the phone, the front line technical support representative sounded very authoritative with years of experience in her position and required some persuasion in forwarding my trouble ticket to a network engineer. Only through a more careful investigation can a problem be found to require a new solution.
I, too, served on technical support’s front line. Control of the conversation is very important. Effort needs to be made by both parties in keeping the dialogue from degenerating into a shoutfest. After all, in the typical case, the technical support representative accepts outbreaks from the outraged client as part of their job and simply shrugs it off at the end of the day. With a reasonably calm voice, it is almost always better to seek out solutions and keep communication open when forced to do so over the phone. Talking with a phone representative should always support the underlying objective of trying all available options, which is inhibited by frustration and raised voices.
“Few businesses are as spread out as MySQL, which employs 320 workers in 25 countries, 70 percent of whom work from home,” says Fortune’s Josh Hyatt in MySQL: Workers in 25 Countries with no HQ. A discussion of this can be found on Slashdot.