Technical Support Guidelines

It is often not clear where the duties of the technical support staff end, and where the responsibilities of the end user begin. In many organisations, when things don't work, everyone blames the equipment. There's something wrong with my computer. What normally goes on in the mind of the technical support person is, "Yeah, there's something wrong with your computer. There's an idiot using it!"

Rule 1: Not everyone likes computers like you do.

For most people, it's just a tool, a thing to use to get stuff done. Like a car, it must be easy and comfortable. A mechanic will want to pop open the hood, stare at the twin cams and glow in admiration, but we're not interested. We just want to put the key in the ignition, hope it starts on the first turn and that the ride is quiet and smooth. So too with computers. Most people just want to push the on button, hope that it starts quickly and that they can click on their programs to get their stuff done. Who cares if it's Microsoft Windows, or Linux, or a Mac? So when you're talking to users, all you need to do is find out what they actually want to accomplish. What were they trying to do, what did they do and what did they see.

Rule 2: People generally don't like to type.

Clickety, clickety, click. In fact those were too many clicks. One click's the way to go. And don't ask them to remember more than one password. One password to get to everything's the way to go. So for those of us command line aficionados this click to access the world mentality, though simplistic, is what people want.

Rule 3: Teach them the language.

I used to think that users don't need to understand what the word protocol meant, but now I'm different. If they're using FTP to copy files from websites, and they need HTTP to browse the Internet, then they need to understand the different technologies at work. And I don't let them get away with saying FTP when they really mean SFTP. Yup, they need to realise that there's a difference between SFTP and FTP, just like there's a difference between HTTP and HTTPS. And those certificate thingys that bring up warning dialogs that people aren't reading. Well, you don't have to read the dialog warning if you're aware that it's a warning, but if you click on it, and accept it's warning not to proceed, but you proceed anyway, then if you get a flu, it's totally your own fault. Don't come crying to support that your fifty page essay that you've worked on for the past six months has just been shredded by the system and that you need it recovered from the backup tapes immediately. We'll recover it, but it won't be immediate. And there's a possibility that your copy on backup might have some infections too.

Rule 4: Teach them to fish.

There's a saying, give a man a fish and you feed them for a day, but teach them to fish and you feed them for a lifetime. Every technical support call is an opportunity to teach them to fish. And for this reason, sometimes, even if I know the answer right away, I'll see if I can point something out. This approach can backfire since all they really need to do is get an answer and proceed on their way. They don't need a lecture. And they might develop a habit of not asking you any questions, even when they have a problem, since they're thinking, Andrew's always so wordy and preachy when I ask questions and he makes me feel so dumb, and you don't want this to happen. But sometimes, there are opportunities to teach.

Rule 5: Know when to give up.

Some problems don't have a solution that's effective in a given time frame. Some answers take too long to find and the cost of all the searching doesn't pay off. The answer's not worth it. The problem isn't worth solving. It's possible that you've been asked a question which the person was only curious about. They've given you a ton of work to do and you don't really need to give them an answer since they don't really need it.

Rule 6: Be proactive.

Some people will approach you with every little thing that's bothering them and some won't ask any questions and will prefer to stew and simmer with the problem. It's those shy ones that need to be approached most of the time to find out if everything's going well. Like the shy kid in the back of the class. The teacher can choose to spend all their time with the kids that are asking the questions, demanding attention, and ignore the quiet one at the back painfully struggling through the exercises, or they can choose to go over to little Johnny and ask intelligent questions. Start an intelligent conversation and leave them with some tidbit of information.

Rule 7: Not every problem's a computer problem.

This should have been rule 1. And sometimes it's not a user problem either. Someone trying to send an email attachment but isn't getting very far. Perhaps a courier or snail mail might help. Someone's got a thousand page document that seems to black out and cause the entire computer to crash when they try to scroll down to page one thousand. Well, perhaps the document needs to be reconstructed, or broken down, or cut-and-pasted into a new document, or printed, or abandoned. I see these Excel-type requests all the time. How come the same document seems to work on their home computer, but when they bring it in to work, it blows up? Unfortunately we don't have access to the home computer so that troubleshooting bit can't be done. We'll just have to take your word for it. However, there may be things that you've inserted into the document that aren't available at work... so, it's so sad, too bad.

Rule 8: Some users are beyond help.

This should have been rule 2! They say we shouldn't judge people, pigeon hole them, categorise and label them, but it's tough to do. Some people just got it all wrong years ago when they were introduced to computers. To make matters worse, in most cases, it's this group of people who think that they actually know more than they do and so they tend not to listen when you're giving advice. It's tempting to put them in their place, but that's not right. It would be rude and of no benefit to you or them. So, my advice in this case is just to solve the problem and move on. When they tell you that they tried the steps that you just performed, and it didn't work for them, and how come it worked for you, you can politely shrug your shoulders, and say something like, there's a whole lot going on in there, it's tough to say. Let them off and move on.

Rule 9: Take time for lunch.

We're tempted to jump at every problem and solve it to the detriment of taking time for ourselves. This is really important. You have to work within schedules, taking time to help people, continue to grow in your profession, which means taking courses and reading and learning, as well as taking lunch, coffee/tea breaks and vacations. Many of the technical people I know, me included, spend way too much time in front of computers. They're warm and friendly. They interest us in how they can do so many things. We're always crunching out code, building web sites, bit fiddling, compressing files, squeezing memory and over-clocking the CPU. And there's a real danger of making them more than the tools they are. It's like a carpenter who's always sawing and shaping wood, just for the sake of it. Not building anything, but even during their down time, finding a piece of wood to shave. And like we have to say NO to people sometimes, there are times when we have to say NO to ourselves.

Rule 10: Pass it on.

One of the best ways to get better at something is to teach it to someone else. Learn to pass on your skill.