Seven rules for being a great help desk analyst

TechRepublic passport holder and professional trainer Pat Vickers lays the ground rules for running a successful help desk operation.

A good help desk analyst is hard to find. Ask any help desk manager and you will be told that staffing is by far the biggest headache of the job. The worst part is that just when the weeks of searching and months of on-the-job training are beginning to pay off, the good ones move on to greener pastures. It seems like a vicious cycle.

While finding and keeping good people will always be an issue, there are seven rules that make it possible for anyone who is intelligent and computer literate to be a great help desk analyst. Not only will they be great help desk pros, but they may actually like their jobs.

1. Gain the trust and confidence of the user first.
I know. I know. If you don’t get that employee ID and open the call record right away, you may never get another opportunity. Besides, it only takes a minute. The problem is, for most people, getting help over the phone is a bad experience. Often the caller has been waiting on hold for a few minutes and that’s after he or she tried to solve the problem without help. While this is a new call to you, it may have already been hours for the user. When a help desk analyst opens the conversation with a demand for information that seems impervious to finding a solution, the call begins on a bad note.

Just answer the call with “help desk” followed by your name. Give the user a few seconds to launch into a description of the problem and even make a remark or two before demanding information. The conversation may go something like this.

“Help desk, Pat Vickers.”

“Word won’t start and I need to get something typed.”

“Having a bit of trouble launching Microsoft Word, eh? Well you’re in luck because I’ve run into this a few times and I think we can get you squared away. If you don’t mind I’m gonna get your name and ID first so I can record this call while we’re working. That way my boss will quit calling me a slacker.”

Obviously it’s not always that simple, but finding ways to make a little productive chitchat gives you a few moments to establish that you’re listening, you care, and you can help. Once that has been accomplished, the caller will be more cooperative and the call will be more pleasant for everyone involved.

2. Before any attempt at solving the problem, restate the problem to the user.
I can’t tell you how many times I’ve wasted 20 minutes or more working on the wrong problem. A great help desk analyst knows that most users have a difficult time describing what is going on with a computer. It’s very important to verify even the most basic problems before proceeding. Here’s what happens when you don’t follow this rule.

“My mouse is stuck.”

“I see. Lint gets caught under the mouse balls quite often and that’s probably what’s happened to you. Try this. Turn you mouse over so you can see the bottom…”

You can imagine the rest of the conversation. If the analyst follows the rule, however, the conversation goes quite differently.

“My mouse is stuck.”

“So you’re saying that when you move your mouse around the pointer doesn’t move but everything else on your computer works. For example, you can use the keyboard to change to a different program and that works fine.”

“How do you do that? “

“Hold down the [Ctrl] key and press [Esc].”

“Nothing happens.”

“Oh. So it’s not just your mouse; the whole computer seems to be locked up?”

“I guess so.”

If a user points and clicks a lot, it may not be obvious that the entire computer is locked up. Most describe it as the mouse being stuck. The first analyst will spend about 10 minutes cleaning the mouse before realizing it’s not the problem.

3. Avoid asking the user questions that begin with the words “Did you...”
Most users will try a lot of things on their own before calling a help desk. They are usually very frustrated. They also know that if a computer geek was around he or she would get things working immediately, but they would do it so quickly that no one could follow. Most users suspect there are secret ways of getting computers to work. They figure if they can wait you out you will be forced to reveal the secrets. Since they know they’ve already tried everything, if you ask, “Did you…” the answer will always be yes.

“Did you try holding down the [Ctrl] and [Alt] keys while pressing [Delete]?”


“Did you press [Esc]?”


“Did you hold the computer over your head while executing the ritual disk drive dance?”


It’s usually not that bad, but many users just aren’t listening to the entire question. Instead of asking questions, try to get the user to attempt the tasks while you are talking. Sometimes they don’t want to do this, but you can usually convince them by using the method in the following conversation.

“Hmmm? That is unusual. Don’t you hate it when computers suddenly stop working? Let’s try this. I have the same program. Let me get it launched, and we can run this procedure at the same time. Maybe if we can pinpoint where my computer is behaving differently we’ll be able to figure out where your computer is messing up. If mine does the same thing, we’ll just have a talk with the programmers.”

“I have a thing or two I would like to tell those guys.”

“Don’t we all. Okay, I’m ready. You tell me every keystroke you’re using, and I’ll match it exactly here.”

Now the user has a logical reason to go through all those steps again. He or she can prove it’s the computer. It might not be fair to drag in the programmers, but with a particularly difficult user, bonding can help. Don’t overuse it, though. The programmers are your friends.

4. Do your best to have the same setup as your users.
Sometimes this is the most difficult rule. Very few offices are lucky enough to have all or even most of their users on the same setup. It may be necessary for every analyst to have a different configuration and then borrow each other’s workstations depending on the call.

The main reason this rule is hard to follow is the almost irresistible urge to upgrade. It’s a great idea to get new equipment and software before the user for testing purposes, but be careful. It’s very easy for the help desk to fall into the trap of getting the latest coolest equipment and software. No program is going to run the same on 400 MHz and 128 MB of RAM as it will on 166 MHz and 32 MB. It’s essential to be able to experience software as your users experience it.

5. Never pretend you know more than you actually do.
Most people—users, managers, and analysts alike—think it is the job of the help desk analyst to know everything there is to know about the user’s hardware and software. It’s a bit humiliating for help desk analysts not to know an answer, and they will usually try to come up with one—even if it’s a guess. Guessing becomes a bad thing when the analyst states guesses as if they were facts. If later in the conversation the analyst is proven wrong, all credibility is lost.

So what’s the answer? How do great help desk analysts remain great if they can’t answer their users’ questions? This is not as hard as it seems. Just be completely honest. Let’s face it. There is a lot of demands put on a help desk. It’s not uncommon for a help desk to receive software after the users. A great help desk analyst knows how to support software on the fly. The following approach usually works.

 “Boy! When you said new, you meant it. Can you believe they didn’t even tell us here at the help desk that this program was out there? Fortunately I can access it through our Web page. How much do you know about it yourself?”

“Just what the book tells me.”

“Book! You’re one up on me. Well they’re not going to defeat us. I’ve got it up now. You tell me what you want it to do and how you’re going about it and we’ll see if I can manage to fill in the blanks. Team effort. “

The funny part is most users like being able to help solve the problem. They usually feel stupid when they have to call for assistance. Being part of the solution instead of just the problem is a good thing. As far as credibility goes, the analyst who solves a problem after admitting ignorance will mount up credibility galore.

6. One word: Empathy.
The analyst with empathy will be a lot more helpful to the users, and the users will feel the empathy and be a lot happier and more cooperative. On top of everything else, empathy is just as important to the well-being of the analyst as it is to the users.

Empathy is something not found in a lot of help desks, and the lack of it is probably what drives analysts to leave, even though they don’t know it. Who wants to talk to a bunch of whiny, ungrateful crybabies who can’t even start their computers without help? The answer is no one. No help desk can ever be successful or retain analysts for any length of time if this is how the users are viewed.

The problem is that most of this computer stuff is easy once it’s been explained, so people forget how hard it seemed before. A great help desk analyst remembers what it was like not to know. They usually have reminders every day, at least those who follow rule number five.

7. Do everything you can to make the call an enjoyable experience for the user.
This rule may seem like overkill to many people. After all, these are computer professionals, not kindergarten teachers. Nevertheless, a great help desk analyst has fun with the users. The users know the analyst by name and are relieved to hear that individual answer the phone. This makes the call much easier and, therefore, quicker.

Not everyone wants to be a great help desk analyst. Many would rather be a programmer or trainer. For them the tenure on the help desk is a steppingstone to a higher plane. Regardless of your goals, for most people, being a great help desk analyst is actually easier than being a mediocre or bad one. Nothing ruins the day like a nasty user that just won’t quit. Great help desk analysts have very few of those.

Editor's Picks

Free Newsletters, In your Inbox