You might think that "tech support" is a solved problem. You're probably right. Someone has solved it and written down The General Procedures For Troubleshooting and How To Give Good Tech Support. However, surprisingly enough, not everyone has learned these lessons. And if the manual exists, I can't seem to find it so I can RTFthing.

The titles of the two unheard of holy books I mentioned above might seem at first glance to be different tales. After all, troubleshooting is a broad topic applicable to any kind of problem-solving from chemistry to mechanical engineering to computer and biological science. Tech support is the lowliest of Lowly Worms for top-of-the-food-chain programmers.


(And don't ask me how sad it makes me feel that my favorite book as a kid has only a 240px image online. I need to find my copy and scan it.)

But just like its more enlightened brethren, tech support consists of troubleshooting. In fact, it should be the first line of defense to keep your coders coding and off the phone. Who wants them to man the phones? Certainly not the programmers. Certainly not management. Tech support is a cost center, not a customer service opportunity.

That's a lie of course. It's a bajillion times more likely that you'll sell to an existing customer than someone else¹. So why do we see such poor customer service? Especially in our own industry?

Perhaps when you have a virtual monopoly over a market like most cable companies or utilities in a given locale, you can afford to have poor customer service. The cable sphere seems to be opening up, what with satellite TV and internet and now AT&T and Verizon offering television and decent-to-good internet packages. Even still, AT&T's UVerse has its own problems, I've heard, and (at least personally) I've not witnessed the kind of customer service that competition promises with regards to cable TV and internet access.

Is tech support really that bad? Maybe it's not. There are some folks that have decent starting advice. Even if it's not How To, at least Some Ways is better than no ways.

The fact is we tend to treat support like a second class citizen. It's a position we want to fill with a minimum-wage worker (or less, if we can outsource it) who has no expertise, no clue, and doesn't care to learn the product since he can get a job in the fast food industry at about the same rate. And with no stress!

It makes it worse that we don't even want to take the time to train him, since it would take away from the productive code-writing time to do so.

The person we want to treat as an ape or worse always seems expendable. We treat them so. Should they be?



I say no. Not only am I a big fan of dogfooding, I feel like Fog Creek's giving customer service people a career path nowadays matches a lot of my ANSI artist peers' experiences from back in the day. Smart people start in support, and they can move themselves up in the organization to play more "key roles."

Bill puts on a headset, sits down, and answers the phone. "Hello, this is Microsoft Product Support, William speaking. How can I help you?"

Bill talks with the customer, collects the details of the problem, searches in the product support Knowledge Base, sifts through the search results, finds the solution, and patiently walks the customer through fixing the problem.

The customer is thrilled that William was able to fix the problem so quickly, and with such a pleasant attitude. Bill wraps up the call. "And thank you for using Microsoft products."

At no point did Bill identify himself as anything other than William. The customer had no idea that the product support engineer who took the call was none other than Bill Gates.

Like Bill.

I don't think it needs to be a full-time thing, but it certainly helps if programmers are their own support team. Like Bruce Johnson who posted that linked message, I work on a small team and can vouch: it's downright embarrassing to have to support our customers. I'm glad to do it, but when it happens, more than likely I've got to take blame for the problem I'm dealing with. You know how hard I try to make sure my code works as expected before I deploy it?

"OMG I'm sorry, that's my fault, I'll fix it for you right away." Can you get better support than that?

I'm not so sure I'd have tried that hard without the customer experience pushing me.

I think I've made my first point: that customer support is customer service is important to the health of your business. While I agree that tech support in the common use of the term is useful to shield your programmers from inane requests, I also recognize the value in having programmers take those calls from time-to-time.

Given that, I do in fact have some do's and do-not's with regards to support. The list here deals mostly with how to be a good support technician for your team, as opposed to the customer. Still, the customer is central to the theory. Although it does not make an exhaustive list, here are four contributions to The General Procedures For Troubleshooting:

1. After listening to the problem description, the first thing to do is recognize whether or not you can solve the problem while the customer is on the phone, or if anyone can. If you can, then do it. If you think only someone else can do it, and work for an organization that has multiple levels of live-support, then escalate it.
   
   If you don't think solving the problem is possible without escalating it to a level of support that won't get to it immediately, thank the customer for reporting the issue, let them know the problem is being worked on, and boogie on to step 2.
   
   
2. As support, the first thing you need to do before escalating the issue is confirm there is an issue, and do it with a test account, not the user's.
   
   It's ridiculous to ask for the user's credentials. Don't do it. If someone were to ask you, "What is your username and password?" what would you think? The average user isn't going to know your query is tantamount stupidity, but if you get someone who is slightly security-conscious, you're going to lose a customer. Hopefully, he's not a representative of your whale.
   
   If anyone found out that you're in the habit of asking users for their passwords, they can easily call anyone who uses your software and get in by just asking. Further, since many people use the same password for everything or many things, that person would also have access to your customers' other sensitive information, wherever it resides.
   
   You can point the blame at your stupid customer for using the same password everywhere they go all you want. You're being just as stupid by opening the door for that type of attack. Further, you should always try to recreate and fix the problem with as little inconvenience to the user as possible. That means doing it with test accounts as opposed to asking the user for theirs, or changing their information.
   
   Keep things simple for the user. Don't jump immediately to using their time to make things easier on the support team. Doing that is lazy at best, sloppy most of the time, and could result in disaster at worst.
   
   
3. After confirming the existence of the problem, provide the steps of how to reproduce it. Give some screen shots. If it's a web app, provide links. Don't constantly send and email and ask the higher levels about it. Doing so once or twice is one thing, but doing it for every request is a time-waster. Just send the email and the next level will get to it when they can. If they don't get to it within the acceptable time-frame for your organization, send a reminder. Include the boss if you need to. But don't do that prematurely (and that's another subject altogether).
   
   
4. Don't jump to conclusions about the source of the problem. Although Abby Fichtner wasn't speaking directly to support ...
   
   
   
   ... This is the opposite of my general approach. The parallel here is code : customer :: you : dumb². I've learned (even if through a bit of self-torture) that I should always look at the code first, if for no other reason than I don't want to be foolishly blaming others when I'm to blame. In the case of support, I've always hated the term "User Error," and that's what the tweet reminds me of.
   
   By framing it as an external problem, we miss an opportunity to teach the user how to use the product, or a chance to improve the product to make sure they can't use it "incorrectly."

What are your thoughts about tech support? What can you contribute to The General Procedures For Troubleshooting?


Notes:

1) I know this statistic, it's even intuitive, but I can't seem to find it online for free. Here's some apparently made-up stats to satisfy you. Go back to what you were reading.

2) "word1 : word2 :: word3 : word4" is SAT (and elsewhere) notation for the analogy "word1 is to word2 as word3 is to word4." See freesat1prep.com for a few examples.

Some links in this post are affiliate links. This message brought to you by the Federal Trade Commission.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment




Leave a comment

Leave this field empty

	Your Name
	Email (not displayed, more info?) Privacy Information x Your email address is not displayed. It is used only to respond to you if needed, and send comments if you subscribe to this comment thread. It is stored in a cookie if you choose to "Remember my details".
	Website

Comment:

Subcribe to this comment thread
Remember my details