You’ve probably heard a call like this one before:

User: “My new printer is incompatible with Outlook; I want my old printer back immediately.”

You: “Are you having problems printing from Outlook?”

User: “No, the printer is making empty lines appear on the screen each time I create a new message. I need my old printer.”

You: “Something is definitely wrong, but I don’t believe the problem is caused by the printer.”

User: “Yes it is. This problem started when you installed the new printer. Just give me my old printer.”

When end users attempt to diagnose their own PC problems, they often compound the difficulties of determining the actual cause of the problem. Handling such situations requires more than just technical intervention from the support staff. I’ve identified three techniques to help you successfully deal with end users’ misdiagnosed computer problems so that you can find the problems and fix them while earning the trust of your end users.

Acknowledge the user’s diagnosis
A good approach to take when dealing with a possible end user misdiagnosis is to acknowledge the diagnosis as the actual cause of the problem. Showing an interest in their diagnosis and how they arrived at the conclusion will increase users’ trust in you and improve the likelihood of their providing you with useful information.

When using this approach, remember that perceived problems may require creative solutions. For example, when a support tech received a call from a user who reported that his computer was running slow, the tech sympathized with the user’s frustration and encouraged him to explain the symptoms. During the conversation, the tech realized that the user was basing his assessment of the computer’s speed on the brightness of the power light on his monitor.

After discussing the symptoms, the tech decided there was no real problem. So after the user had left for the day, the tech cleaned the monitor, paying particular attention to the light. The next day the user called the help desk to report a marked improvement in performance.

Ask the user to reproduce the problem
You can also try to engage the user in determining a real solution to the perceived problem. Often, if users can be led into discovering the actual cause of the problem for themselves, they will see the error in their own misdiagnosis.

A good way to start is to simply ask the user to demonstrate the problem. For example, in one incident, a user claimed that closing a single Word document exited the whole application. By observing the user actually recreating the problem, the tech determined that instead of selecting Close from the File menu, the user was selecting Exit. And during the re-enactment, the user actually realized his mistake without the tech pointing out the error.

However, even if the user is unable to reproduce the error, don’t doubt the validity of his or her claim. Ask users to keep an error log detailing the date/time, open applications, and their actions each time the error occurs. Engaging users in the diagnostic process lets them know that you’re taking their problem seriously.

In one such case, a user called the help desk to report persistent Spool32 errors. Unable to reproduce the error, the user was asked to keep a log. When the tech checked back with the user, the problem had not recurred, and the user closed the work order. Either the error was not occurring with the frequency the user claimed or it was not sufficiently bothersome that the user wanted to waste time to document its occurrence. But if the problem is genuine, and the user creates a log of information, this documentation can be an invaluable troubleshooting tool.

Find a solution that works
Often, the hardest part of dealing with users who misdiagnosed a problem is convincing them to buy in to your solution. Consider the outcome of the Outlook/printer incompatibility problem presented at the beginning of this article.

Perplexed by the user’s report, the tech asked the user to demonstrate the problem. Sure enough, each time she opened a new message, about ten blank lines were inserted at the top of the message. It took several re-enactments of the procedure, but eventually, the tech noticed that each time the user moved the mouse to click on the New Message icon, she inadvertently depressed the [Enter] key.

However, at this point, the tech felt the irritated user might not be receptive to being told that she was the cause of the problem. So the tech informed the user that she was correct, there was indeed an incompatibility problem that could be resolved with a new keyboard. The tech connected a spare keyboard with a slightly different layout to the user’s PC and the user was happily unable to reproduce the error.

Honesty is always the best policy, but…
Ideally, it is always better to be honest with users, but sometimes their state of mind or lack of technical knowledge might clue you in to trying a different approach. In these circumstances, be sympathetic, acknowledge the reality of the problem, work with the user to determine the cause, and then offer a solution that doesn’t undermine his or her knowledge or trust in you. This is the best way to keep your end users content.