Working on a help desk 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 help desk 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 realize 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. 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 organization?
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 fulfill 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