Category: Tech Support

HOWTO: RTFM

I know Wil Wheaton already linked to this, but I also know that you guys aren’t reading his blog, so I thought I’d share the love. This HOWTO should probably be expanded on in more detail and shared with the people who deserve it, but for now it can still be appreciated by anyone in any technical support position. I especially like the link in the upper-right-most-corner of the page.

What version was that?

At the beginning of the call, she said she was using version 20 of our software, and described a problem unique to v20. I answered her question and resolved that issue for her. Then she said she was having a problem with the macro list in a particular part of the software.

I tried to get her to tell me what the problem was by dexcribing what she was seeing on the screen, but the more she described what she was seeing, the more it became clear that she was not looking at the same peice of software I was. After a while, it seemed like she had never even used out software. Then I worked out that she was just doing a very bad job of describing an old version of our software. In v18, that part of the software was radically different. The third time I asked her, she admitted that she was in front of a computer using v18, and then promptly went to the computer running v20, where she saw that there was not actually a problem.

What the heck?

Tech support rocks ass!

Is it wrong for me to assume that when someone calls in about a particular technical question, and they ask to be walked through a particular fix, that the computer they are in front of and allow me to walk them through the steps for the fix on is the one with the problem? I don’t think so, but maybe I’m mistaken.

Is that like taking your station wagon to the shop, asking them to change the alternator, and when they’re done changing the alternator in your station wagon, while you watch them do it, mentioning that the alternator they needed to change is in your minivan? That’s what it seems like to me.

Poor communication of the problem

Why is it that when people call technical support, they sometimes (oftten) explain in detail what was working, how it was working, what they liked about it working, before ever mentioning that they have a problem now or what the problem might be? I don’t usually care about what it was doing when it was working fine; I usually know exactly how it was working when it was working fine! I want the customer to tell me what the problem is, so I can explain the solution to them and help the next customer. I don’t want to sit on the phone with the customer for 45 minutes because they couldn’t tell me what the problem was within ten minutes, and then didn’t believe that my solution would work and need to spend twenty minutes verifying that whet we walked through fixing in two minutes works to their satisfaction.

(Also, I am right now speaking to a person who spelled out “dot” when saving a file with an extension. So instead of .pdf, he was putting .dotpdf. How clever!)

Of course, worse are the customers who aren’t interested in anything i have to say because they have their own explanation for what is going wrong. Why did they call me in the first place? What do they expect me to do? Tell them that their incorrect assumptions are true? Leave them with non-functioning software? Somehow magically make it possible for them to use the software incorrectly and it to work at the same time? Aargh!