I have never been a waiter for a restaurant. However, because I have been a patron, I think I could do a decent job being a waiter because I would try to do all the things that I have liked and not do the things that I disliked from my other perspective. However, I know it’s not that easy, and there would be a lot of situations that would come up that I am not familiar with, and I would be lost.
Does the same thing happen with the Help Desk?
For better or worse, Help Desk or call center tech support is often an entry level job. People get trained on it and work there for years and then might move on to higher tiers or different skills as they gain proficiency. Just as most people have seen a waiter work, most people have also had to call into tech support. Would you be able to be a good tech support representative based solely on your experience calling for support or do you need to think about the process in more depth to catch those unfamiliar areas?
Tonight, a forum thread asked for an honest critique of a Help Desk process. I wrote a response that I think helps get the ball rolling to make tech support on the phone actually useful, not just a time killer.
The OP stated his existing process as follows:
[M]y direct line is the helpdesk line. I have no procedure, script, or any type of manual to follow. Basically, here is how I answer the phone
“Tech support”
Then they respond
My next question is usually “Have you restarted your computer”. If the answer is yes I say can “Can I remote in?”. I then remote in, ask them to show me the problem. I poke around for about a minute. After a minute if I haven’t figured out the issue I put them on hold for up to 10 minutes. If I still haven’t fixed the problem I take them off hold and tell them I will look into the issue and call them back.
A number of people commented on improving the professionalism of the telephone answer such as saying “Tech Support, this is Jason. How can I help you?” instead of just “Tech Support”. I wanted to take things a step further and address the generic process which seems to be:
- Answer phone and listen to problem.
- Ask if they have restarted computer.
- Connect remotely and try to solve problem for a minute.
- Put on hold and continue trying to solve problem for 10 minutes.
- Tell them you will need to research the issue and call them back.
This isn’t meant to be harsh criticism for the person. They asked for a critique and I wanted to offer my opinion on how to improve it based on my experience as a tech support consultant, help desk, and tier 2 employee.
According to the workflow you provided, none of the information the user provided influences your future path. If you’re doing this for every issue, it certainly makes no sense nor does it sound very helpful.
If I were a user and you asked if I restarted the computer for an issue that would not be resolved by restarting, I would be infuriated.
It seems like you’re thinking of the process as “What have I seen other people do or what do I remember other people doing when I needed support?”. Instead, think “What information do I need to be able to solve the issue?” Get that information.
How can I help you? (initial report)
Could you read me the exact error you are getting? (reading helps)
When did it last work? (new issue or ongoing)
Are you aware of anybody else also having this issue? (user/computer specific or system wide)
Does it work if you try [alternative]? (Different browser/computer/plugin/etc)Once you assess the issue, build on your knowledge and experience to come up with a solution. “We might need to reinstall the application.” or “We need to set your default printer.” or any other standard process users need assistance with.
Unless the user is not providing enough information to assess and solve the solution, I believe you should be able to hypothesize a solution before you even remote connect to the computer. Otherwise, you’re just connecting and guessing, wasting their time and yours.
If you don’t think you’re going to be able to fix it directly or quickly, log a ticket, tell them you will research the issue and see if you can recreate it, and then get back to them promptly. Collaborate with your team and do some research. Come up with a solution that logically sounds like it could address the issue. Get back to the user and try out your theory.
Use the information that you have gathered to eliminate possible causes (software, hardware, user, network, servers, domain services, etc.). Log the information you have gathered in your ticketing system and work it like solving a murder case until you find the culprit causing the problem.
Try to be helpful to your users, not just a sounding board for their theories or a generic process that works some of the time. Be polite. Cut to the chase. Save them time. Get on to the next issue.
I know this is only a rough draft of thinking through the process of tech support via telephone but I think it starts on the right path. The next step would be to document problems, error messages, and solutions so you can refer to that as part of your research. After all, that’s how 404 Tech Support got started all those years ago.