Tuesday, May 29, 2012

Problem solving tips for helpdesk personnel


Working on a helpdesk is all about problem solving. Users have problems and look to us for a solution. 

We all know that there are some people who are very good at solving problems and there are those who sometimes struggle. The good ones aren't necessarily more technical, they just have an almost uncanny ability to solve problems which have everyone else stumped.
If you are one of those that sometimes struggle, don't worry, it is possible to improve by following some very simple guidelines which we will show you on this site.

On this site we will take you through some of the key steps. The examples are all based on a IT helpdesk but the principles are universal. 

We present this guide in the form of several numbered steps. This doesn't mean to say that problem solving is a linear process, very often you will need to loop back to an earlier stage.

The Symptoms: It is vital you identify the symptoms. Quite often a user will call with "My computer is not working", but we all know how useless that is ! Here are some questions that are applicable to practically all problems:

1. What is the exact error message?
This maybe obvious, but sometimes it is easy to jump to conclusions based on partial information. If possible, get the user to send you a screen dump (hold down the ALT button, then press the PrtScr buttons, go to e.g. Word, create a new document and select Paste from the Edit menu)

2. What were you doing at the time?
By determining this you can identify which program or which part of the program is causing the problem.

3. Has the error always occurred or just started?
If the program has never worked, then it is possibly a fault with program. If it used to work OK, then you will need to find out at what point in time it stopped working.

4. If it has just started, have you recently installed any other software or made any other changes?
People are very reluctant to admit they have made changes - perhaps they are worried they will get into trouble? So, you will generally find that the answer to this question is "No", but never believe it. The program was working, now it isn't - something must have changed. Bear in mind that the user might not be aware of changes (e.g. many programs and even the operating system may do automatic updates) or they might not realise the significance of some apparently unrelated change.

5. Does it affect all machines or just yours?
If there are other machines that can use the program without problem, then the fault obviously lies with the configuration of this individual's machine.
If every machine has the same problem, it might be that they all have the same configuration problem or it might be a problem with the application's data.

6. In the case of networked programs. if you use the program from a different machine, do you get the same error?
If the error does not appear when you use the same application program from a different machine, then it is likely to be a fault in the configuration of the user's machine.

Examine the Evidence

What evidence is relevant? Do you have enough evidence? These are two key questions when problem solving but you aren't going to know the answers to them until you start postulate possible causes and want to test them further.

Experience may sometimes tell you that certain facts are irrelevant. This is good, and will help you concentrate on what you think is relevant, BUT, don't forget about them and keep an open mind.
Your biggest tool for gathering evidence is of course your question and answer sessions with the user, but there are other tools which you can use:

Filemon is a great utility which logs all file activity. Set it running, the go to the problem program and generate the error. Stop Filemmon and look at the log. It generates a great deal of information but it is very easy to see problems.

Event logs: Most operating systems have both application and event logs. Check these to see if anything is relevant.

Confirm everything:  Quite often you have to tease the information out of a user over several question and answer situations. Once you feel that you understand the problem, make sure you confirm it with the user :

"So, as I understand it, if you clck the Update button while creating a new record, the screen crashes with an error "Record must be unique". This was working fine on Friday, no-one else has this problem, and you haven't made any changes to your machine over the weekend. Is that correct?"
If they don't confirm then you must repeat step 1 until you are both happy that you are talking about the same problem.

Research: You know what the symptoms are, you know in what circumstances they appear, now you have to start finding a solution.

Of course, it might be that someone has already done the hard work for you - others may have had, and solved, this problem. There are several sources of information you might try:

Knowledge base : Somewhere, you should have a record of all past problems (and their solutions), otherwise you are going to keep wasting an awful lot of time. This should be in a form that is easily searched. You could use e.g. a spreadsheet, a simple document, a database, or a program designed specifically for the task. As long as it is easy to use.

The Internet : The Internet is a fantastic resource. The only problem is the sheer volume of information. A good search engine is key to getting the best of it. One of the most useful tools is the Google Usenet search tool. This allows you to search an archive of all usenet postings. You can almost guarantee that someone, somewhere has had the same problem as your user and if you are lucky, there might be an answer already.

Colleagues: You might try asking your workmates, they may have seen this problem before. Of course, this will disrupt their work so it is not the most efficient use of resources and they will soon get tired of you if you make it a habit. This should only be used as a last resort.

Postulate and test:  By now, you know what the symptoms are and you have done some research on similar problems. You should by now have some theories as to the cause of the problem.

Now you need to test your theories. This usually involves further questioning of the user:
"Your monitor is blank; can you check if there is a green light on the front, bottom right of the monitor?"
If there is, then you know there is power to the monitor, but is there a signal?
"Do you have another monitor nearby that you can plug in instead?"
If the new monitor works, then it is a problem with the old one. If the problem persists, chase it back up the wire...
"Can you put the original monitor onto a different machine? Does it work Ok there?"
If it does, the the fault is with the original PC.
"Is there a green light on the front right of the PC?"
If there is, the problem is probably with the PC itself.

Don't assume or jump to conclusions. Take a step by step approach, eliminating possibilities as you go. Sometimes when there are many possible answers you are able to narrow the field considerably by taking an initial broad brush approach. In the above example the first question we asked was "...can you check if there is a green light ...". If the answer was no, then either the monitor wasn't plugged in or there was a power failure. Perhaps a better first question would be "Plug a desk lamp into the same socket - does it work?"

Keep an open mind. You might find yourself going right down one avenue of investigation only to come to a full stop. Don't forget your other theories, go back and test these as well.

Identify the Problem

You know what the symptoms are, you have confirmed everything with the user, had one or more ideas as to the problem and now you have narrowed it down to just one. You must double-check that this you have identified it correctly. There is no point in telling your user to buy a new monitor if all they have to do is wait for the power failure to be restored!
In the ideal world you will be able to devise one test that identifies the problem without doubt.
Of course, in the real world, all you can do is take your best guess, try your solution and hope. The mark of a good support person is how accurate that "guess" is. If you have followed the steps so far, gathered enough evidence, confirmed everything with the user and eliminated other possibilities logically, then your "guess" should be pretty accurate.

Provide a Solution:  This is what the user expects you to do, right? After all, you know what the problem is so fix it.

Most of the time you might have an easy solution. Other times there might not be an immediate fix available - you might need to order a spare part or it might require a new software release. There are even those situations where you don't know what the problem is. In any case, you need to communicate and manage expectations.
·         If you have a solution, communicate the fix to the user clearly and ensure they understand.
·         If you don't have an immediate solution, again make sure the user understands this and the likely timeframes. Make sure you schedule an action for yourself to monitor this.
·         If you don't have any solution to the problem, do you have a work-around 

Confirm the Solution: You have told the user how to fix their problem, or you have arranged someone to do it for them. After the fix has gone in, you must confirm with the user that their problem has been solved. You can't assume that the engineer visited, or that the new part worked.
Keep in touch with the user until you know the problem has been resolved.

Communicate and Record : The worst thing for a user is if they believe their problem is not being given attention. They don't care that you have dozens of other users to deal with. That isn't (and shouldn't be) their concern. 

You must manage expectations, if you say "I'll get back to you", their idea of when you should do so might be very different to yours. Instead, say "I'll get back to you before 12:00 tomorrow" and make sure you do, even if it is to tell them that there has been no progress.

Record everything. No one has a perfect memory and no one only ever deals with one thing at a time. You must make a note of conversations, actions, agreements etc.
·         You can easily hand tasks over to other personnel
·         You rarely work on one problem to the exclusion of others until it is completed. So you will be switching back and forth and will need some sort of reminder as to what has happened beforehand.
·         You will build up a knowledge base of problems and solutions for use in the future.
·         If there are recriminations, you have a record of what was done!
In what form you record this is up to you. You could use a document, a simple database, write your own program or use software specifically designed for use by helpdesks.

Sample Ticket Template #01
Which application is the user having issues with?
 - Please include the URL if it is a Web application.
 OR - Please include the folder path if it's a file.
---------------
What is the Incident?  What is the User Experiencing?
/-Type description
What is the Error Message?
Capture message number or description
When did this problem happen?
---------------
What is the Impact to the Business/User?
---------------How many users affected by this one or more / is it happening across the organisation?
How urgent is the resolution of this incident?
 (Delete as necessary)
 COB today/ 1 day/ 2 days/ End of week
---------------
Do you have a work around?  Is there any other work you can do, can you use someone else's PC?  Is there another means by which you can get the required task completed?
---------------
What is the name of the users machine? *
 - Shadow user's machine to get this information
Ask user to open command prompt then type hostname
---------------
What is the IP address of the users machine? *
 - Shadow user's machine to get this information
Or Ask user to open command prompt then type ipconfig [windows]/ifconfig [linux]
 Please attach a screenshot of the error
 - Shadow user's machine to get full screenshot
Or ask user to take screen shot and email it to you.

Sample Communication Template #01
Hello 

As a standard procedure, we require approval from your manager so we can fulfil your request.
Please provide this at your earliest convenience (via email if possible).

Thank you
ICT Service Desk Team

Sample Communication Template #02
ICT Service Desk Call Back No Response: #01
Dear [         ],

We have attempted to contact you on 1 occasion to resolve your service request, however we have been unsuccessful. 

If you still require assistance for this request, please contact the Service Desk on 00 0000 0000.

Regards
ICT Service Desk Team

0 comments:

Post a Comment

Twitter Facebook Favorites More