Top Questions Techies Need To Ask

A systematic approach to resolving computer problems

1.) Has the system ever worked properly?

Consider the extremes here - you could be dealing with a system that was dead on arrival, or that has been plagued by problems from the very beginning. In this case, you could be wasting everybody's time by trying to fix it. In the end, the most likely resolution is that the system will need to be replaced, in whole or in part, or a technician will need to come out.

This question is a variation of the most fundamental question of all, which is to decide if the question is for you. There are two pitfalls here to watch out for, which are to transfer a call you should be handling and, equally problematic, waiting too long to transfer the call.

Clients don't want to be given the run-around by seemingly lazy and/or incompetent technicians, but nor do they want to have their time wasted until you finally realize that the call should have been transferred long ago.

If a problem is not within your domain of responsibility or expertise, you need to be able to make this determination early. Don't assume you should be taking the call just because it was routed to you.

These should be your favorite calls because they are short and help bring down your handle time, but be sensitive to the client who senses that they could be in for a frustrating experience.

At the other extreme, you could be dealing with a system that has been working flawlessly for months or even years. Then the prospects are excellent for a troubleshooting session that is not only successful but also does not take very long.

Notice, as we go down the list of questions, how the prospects for resolving the customer's issue get dimmer and dimmer, until we find that the problem needs to be escalated to a senior technician.

It may well be that you will never get quizzed on any of these questions. However, if you come all the way down to question 13, you are very much at risk of being quizzed on any or all of the preceding twelve questions.

When all the senior technicians are over-stretched, perhaps because of an unexpected surge in support calls, and one of them stops by your work station and asks what you have done so far, the last thing that technician wants to find is that you don't really know, and so (s)he has to start all over.

Not a good use of their time, and not a ticket to job security for you...

Try to identify and resolve the easy cases early.

2.) When did the system start doing this?

We need to know if the problem just started, or if the client only now decided to call and ask about it.

3.) Has anything changed?

Probably the most common reason for problems is that the client changed something, and does not realize what consequences that is having.

4.) What was the last thing you were doing before this happened?

Notice how this is essentially repeating question 3. The only difference is, it is more specific.

5.) Have you added any hardware or software?

Again, we are just repeating question 3 in a more specific form.

6.) Did anyone else have access to the system?

Maybe a co-worker or family member is the one who made the changes.

7.) Is this happening in only one program or in more than one?

We need to know if the problem is system-wide or limited to one application (or a small set of applications).

8.) Is there an error message? If so, exactly what is it?

Ironically, there may have been an error message that makes excellent sense to you as a technician and that would have told you rightaway what you need to do to resolve it, but you have no way of knowing because it made no sense to the client, who therefore, understandably, doesn't remember much, if anything, of it.

You may need to educate them about the Print Screen ("PrtScn SysRq") button on the keyboard. They just hit it, and paste what is now on the clipboard into a Word (or Wordpad) document. They then have the option to email it for further analysis, or check back again anytime to see what the message was, even after they click "Cancel" or "OK" on any popup. I have a good example here.

On to the harder cases.

9.) Does it happen every time or just sometimes?

If we can duplicate the problem, we should be in good shape.
If not, we have less to go by.

10) Is everything else working properly?

The problem reported by the client could be just the tip of the iceberg...

11) Is the system on a network or attached to another system?

The problem could originate outside of the system we are able to troubleshoot.

12) Are there environmental concerns that may be affecting the system?

Lightning strikes and earthquakes come to mind. A lightning strike could fry their modem or other parts of their system. If so, uninstalling and reinstalling their drivers will not help.

Ready or not, time is up!

13) What have you done to attempt to resolve this issue?

Typically, the client is not under any obligation to do anything (except perhaps reporting the problem within a reasonable period of time).

Even though they are not required to do any trouble-shooting of their own, if they did anyway, we need to know about it.

If you've come this far down the list, this question will end up being one for you, as you realize that you need to escalate the call to a higher-level technician, who wants to know what was done and what hasn't yet been tried.

Just as you needed to convince the client that you have not wasted their time, now you need to convince the senior technician that you have not been wasting their time either.

As a practical matter, especially if you are a rookie, and if your call takes too long, a supervisor will intervene much earlier. That could mean anything from asking if you're stuck, or simply asking you to pick up the pace, or to hand over the call to another technician.

Then you will arrive at question 13 early.

You need to have some sort of answer to it by then.

Good Luck!

Valid XHTML 1.0 Transitional Valid CSS!

MCP icon
MCTS icon