Mon - Fri 9:00 AM – 5:00 PMClosed on weekends

13ThingsBeforeCallingHelpdesk_SQIf you work in IT, at some point in your career you formed part of the ‘the helpdesk’ team. You may have started there or you might still be leading the team. In many organizations, the sysadmin fulfils all roles so they can rarely escape those phone calls.

You all had those ‘dreadful’ callers who always seem to have the worst technology day of their lives, demanding you solve the problem yesterday because they have an important meeting or file to print out…

Been there, done that, most of you will say; but is there something you could have done to reduce the number of calls? Yes, there is and it begins when a new employee joins the company. That’s when the training begins.

Here are 13 things every employee should be asked / taught to do before they call or email helpdesk. You will still get the odd call from those who can’t be bothered, but the majority of employees will be happy to try and solve the issue themselves if they are allowed to. These are not fancy command line shortcuts or PowerShell scripts – just steps not all employees know about or think they can perform themselves.

1. Reboot

Face it, odds are you are going to ask the employee to reboot pretty early on since it clears the DNS cache, reestablishes the network connection, forces them to restart all their applications, picks up on new group memberships, and gives you time to undo whatever it is you did. Okay, so if you use rebooting for that last one, you may not want your users to reboot before they call, but for the rest of them, since rebooting really does fix so many things, getting your users to reboot first may cut down on calls by a noticeable percentage.

2. Leave on the screen/write down/screenshot the error message

You can often get the error message from the logs, but that takes time. If the user either left the error where you could see it, wrote it down, or otherwise captured it, you could jump right into fixing their problem instead of first trying to figure out what the problem is. Easiest way to do this is to train end-users to leave errors on the screen if they plan to call support.

3. Their username

They use it to log on every day, but unless they have to type it in, they probably don’t remember it. Make sure that if you are not using UPN and making that match email addresses, users know what their username is.

4. Their computer name

While users may never need to know their computer name, being able to tell you what it is can save a huge amount of time. Show them how to right-click on ‘computer’ in the menu, or how to open a cmd prompt and type in hostname.

5. Their operating system

Unless you are one of the few fortunate enough to really have 100% of your users on exactly the same operating system version, you really need to know which OS a user is running before you start doing much troubleshooting over the phone, since every major release, the vendor moves/hides/changes everything. Make sure users know whether they are running XP, 7 or 8 or OSX before you start talking them through how to do something.

6. How to do an “ipconfig”

Connectivity issues often come down to being on the wrong network, or not getting an ip.addr from DHCP, or using the wrong DNS servers. IPCONFIG/IFCONFIG are incredibly useful and very difficult to get a user to type in correctly, let alone read to you the juicy bits. Make sure they know how to do this, or put a script in place to grab it easily.

Protip: if you use Windows, BGInfo from Microsoft to configure desktop wallpaper, you can put many of the important pieces of data on the user’s screen so that it is easily accessible.

7. Their major application details

At the very least, users should be able to tell you whether they are trying to do something with IE or Chrome, Word 2013 or 2010, ApplicationX or ProgramY, so that you can start with the proper troubleshooting steps. “The Internet” is not a program on most company computers.

8. Confirm Internet access

Since so many calls have to do with reaching a website, getting to email, or other things that come down to Internet access, teaching users how to confirm they have Internet access will also be a big time saver. You could use http://www.whattimeisit.com since it is easy to remember, pays homage to Run DMC, and confirms that the user is not looking at something cached. If you are feeling really lucky, you can also give them a bookmark to http://www.downforeveryoneorjustme.com/ so they can see if a website is down or not. http://isup.me works just as well!

9. Confirm spelling

Until the day address bars, run dialogs, and cmd prompts have a spellcheck function, typos will still be a major root cause of support calls. Check twice, enter once, and we will be happier!

10. Check to see if anyone else has the same problem

One of the first things a support analyst has to do when working an issue is to scope the problem. If the user has already checked with a colleague to see whether the problem is limited to one person or several, a lot of time can be saved and resolution is that much closer. Getting users in the habit of simply asking the person in the next cube to confirm something before calling is a simple thing to do.

11. How to ping a site/server

More advanced users might even be able to handle pinging something first before calling for help, just to see if the system they want is even available. Of course, since many Internet hosts block ICMP, and some companies restrict outbound ICMP this could cut both ways, as a non-responsive server outside your network may still be up, so use your own discretion on this one and consider your own network and security posture (and the employees’ technical abilities).

12. What options are available

Not every issue requires a frantic call to the sysadmin or support desk manager, or even more drastic, a drive by. Make sure your employees know how to open a ticket through email or the web portal, and how to set the severity so you can properly prioritize them.

13. How to leave a voicemail

“Hey, this is Soandsofromofficeso. My system is broken and I need you to call me back right away! <Click>”. Have you ever received a voicemail like that? Unless your voicemail has envelope info and you have the time to go through that, you are just as likely to let the person get impatient and call you back, rather than trying to track them down. Make sure users know how to leave a voicemail that includes enough information for you to be able to identify them, the severity of the issue, and that they slow down when reciting their telephone number so you can understand it, write it down, and actually be able to call them back!

The results could be surprising and if they save you even 20% of the time spent answering calls, you’ve already made huge gains. And a happier workforce too…

Are there any other tips or skills you share with end users to make your life easier? Leave a comment and let us know!