IT Policies

Creating a process for fault resolution

How do you ensure that your help desk people ask the right questions without giving them a script to read out which will make them sound like robots?

It is helpful for everyone who deals with help desk calls to broadly use the same kind of approach when resolving callers’ problems. A unified approach means that callers know what to expect from you. If they get a different response from each member of the team, they will get an impression of a lack of cohesion and may reduce the trust of the customer .

-------------------------------------------------------------------------------------------------------------------

Don’t take this to mean that I approve the use of scripts. I hate scripts. They serve only to highlight a mechanized approach and can mean that the call sounds stilted and may even give the impression that the agent doesn’t really understand the job. My real bugbear is the closing part of our call taker’s script. They are required to ask every caller “Is there anything else I can do for you today?”

I always think that is a silly question. If there was anything else I wanted, I would mention it at the beginning of the call. They should have the necessary technical skills to be able to troubleshoot a problem from a skilled viewpoint while conforming to a call template. Template is probably to strong a term to use. Maybe checklist would be better. Start with the old favorite: Who, What, Where, When, and Why.

Call takers should know that any error messages should be recorded precisely. There’s nothing worse than getting a ticket that states, “User reported an error message” without detailing what the message was.

So, to break down the five Ws we should clarify them.

Who? Name and phone number: an accurate contact can sometimes mean that I can clear the fault without visiting the site.

What? The type of equipment, asset number, and the problem associated with it, including a precise record of error codes.

Where? The address of the place in which to go, so often the address I receive is that of the company’s head office or the address where the invoices are sent.

When? The time that the fault occurred, also take note of whether it has happened before and if other changes were made that might have caused the problem.

Why? Importance/function of the equipment. Why are we fixing the fault?

The same routine should apply when the ticket is a request for service. Who are we creating a login for? What systems do they need to access? Where do they work? Are the appropriate resources available at that location? When is the service needed? Why are we providing this service to this person at this location?

Apply this simple template to any request: change requests, fault logs, provisioning requests, even working out the staffing and holiday rotas.

Using the simple five Ws as a template for help desk calls means that you can ensure that all the bases are covered without having to resort to using a script that has been written by somebody who in all likelihood doesn’t use the language in the same way that you do.

6 comments
Buzz09
Buzz09

I have read numerous postings like these. I have always found the same problem occurs. Whether people would like to admit or not a technical service desk is different from a help desk. While they perform similar in scope, there has been a shocking increase in trying to mush one into the other for processes and procedures. This causes what I like to call, the Fast Food Tech effect, where the focus is on speed and creates unrealistic expectations on the customer end as it portrays the image that technical support fixes are quick fix solutions (and consequently employee burnout). This in turn makes the client unhappy with the service (as they believe it is a simple fix that should be done now), puts strain on the "help desk" and generally degrades service across the board which is, in the long run, counter-productive. I find that the main way to differentiate between if you have a help desk or technical service desk is to ask yourself the question when hiring "Do I require a person with computer education?". In the end the customer happiness is the paramount overriding factor and striking a balance of speed, quality of service and customer happiness is the eternal struggle.

jeremial-21966916363912016372987921703527
jeremial-21966916363912016372987921703527

One suggestion we have implemented at our HelpDesk under the category of what - "What were you doing at the time, what was the result, and what was the INTENDED result?" For a HelpDesk such as ours that supports about 250 applications, this goes a long way to gathering the correct information to properly troubleshoot the issue.

daniel.furrey
daniel.furrey

Jeff made a good point & started the conversation off well. Regarding scripts, I think they can be useful, but only during the Help Desk personnel's ramp up time. What we need to remember is that approx. 80% of break-fixes occur because something was changed & 80% of the Mean Time to Repair is spent trying to figure out what changed. "Is there anything else I can do for you today?" - GREAT!!! Close out of the call a positive note. "When? The time that the fault occurred..." - my only suggestion is also ask - when did it work last. When my group was supporting Market Data Trading Systems, we used email to reports problems. Whenever I received an email, I would respond back with "Checking..." Even though my customers knew I was not checking at that right moment, they knew that I read their email & were more understanding because we acknowledged their call for help. In other words, put yourself in the shoes of YOUR CUSTOMERS when they call for help & you will be loved!

sidekick
sidekick

Great article, but I must disagree with you on one point. Not only should the call taker ask, "Is there anything else I can do for you?", but the tech that addresses the issue as well. It shows you care about the customer and their issues. Sometimes they even come back with "Now that you mention it, there is this other thing...". Now you can address an issue they may have forgotten about, which will make the customer even happier.

gamerider
gamerider

you can achieve quality of service by diffrend ways. You must always remember that at the end of the process is Your Customer. When customer has a problem he doesn't always think rational. Most of all he thinks emotional. 5xW is good way too.

Editor's Picks