Helpdesk Best Practices

If you read 10 books on IT helpdesk best practices, you will no doubt get 10 different opinions on how to structure your helpdesk and respond to end-user issues. It can often be very difficult to separate the nonsense from good solid advice. Many experts simply regurgitate what they learned from their time working as a manager on an outsourced helpdesk by one of the large outsourcing companies. However, the structure of most outsourced helpdesks is to protect the vendor, not give the customer the best possible experience. This post will discuss some of the absolute best practices if your organization is focused on providing the best service to your end-users.

Levels

One of the first things that always comes up while designing or redoing a helpdesk is levels. What is the skill set of a Level 1 Technician? Level 2? Level 3?

Many companies have a policy that the level 1 technician can handle very basic helpdesk calls such as resetting the user’s password or reinstalling a software package. Most give the technician an arbitrary timeline to accomplish this task. The policy may be solve the problem within 5 minutes or escalate to L2. The reason for this is most helpdesks use faulty metrics to report their performance to their customer or management within their own organization. They want the L1 technician available to answer the phone for the next customer, solving problems is not the job of the L1 helpdesk technician. Of course, this causes frustration as people call the helpdesk for help, not to be put on hold or called back at some indeterminate time. Level two and three are responsible for solving problems, but aren’t traditionally held to any SLA and can pretty much call back the end-user when they feel like it.

The good news is, there is a better way. The Level 1 Technician does not have to know it all, nor does he have to solve problems on the first call. The frontline technicians should have the skill set to unlock accounts, reset passwords, answer basic questions, and solve basic problems. However, the L1 technicians should own every single call that comes into the helpdesk. At no point should the L1 technician assign a ticket to L2, the handoff should always be managed by L1. If he cannot solve a user’s problem, he puts the user on hold and finds someone to help, or tells the user he will be called back within whatever the companies standard SLA is. From there, the L1 technician must line up the resources to help the user and both the L1 & L2 technicians respond to the end user together. At no time is the ticket every assigned to anyone besides the L1 technician. It should not be up to the end-user to escalate their problem; this is what the helpdesk is for. The other benefit of doing it this way is the L1 technician is involved with every step of the process. Once L2 solves the problem, L1 may not need them in the future for other similar issues.

The L2 technician should be able to handle nearly anything and L3 shouldn’t really exist. The buck should always stop at L2. If in the rare case that L2 cannot solve a problem, “L3” would be senior non-helpdesk IT staff. This could be the AD administrator, IT Security Group, or the Messaging Group.

To summarize, L1 owns every ticket and either solves the problem or keeps escalating until they find the right person to help. Since your L1 techs will be involved with the entire process, over time you will have a world class L1 organization that can handle nearly anything that comes in.

Communication

Another area of the helpdesk that is misunderstood and is seldom done correctly is communication. When a user reports a problem that cannot be solved on the spot, the goal of the helpdesk should be to ensure that user knows exactly where their tickets stands at any given moment. Allowing the user to know the problem is being worked is the difference between a happy customer and someone that is calling the helpdesk manager three times per day. Communication should be concise, informative, and frequent. I know a lot of managers think there is a fine line between keeping the customer up to date and annoying them with constant emails, but they are mistaken. Good communication tells the end-user that the helpdesk are complete animals and are in a frenzy trying to fix their problem. Giving the customer the vibe that no one will rest for a second until their problem is fixed makes everyone happy.

Initial Helpdesk Contact

The second the L1 tech picks up the phone the call information should be logged. The L1 tech should capture the users name and the reason for the call before anything else. Also, the tech should verify the user’s phone number, email address, user ID, and office location. It’s very easy to become annoyed when you are a few minutes into your call and you are still reading your email address to the L1 tech. The L1 tech should be doing the talking and the end-user should only have to confirm the information the helpdesk has is correct.

Once the information is confirmed or updated, the tech should log the reason for the call and then try to solve the issue. All helpdesk personnel should be able to write well and quickly. There should not be any broken notes in the ticket as all information pertaining to the ticket should be public. Far too often L1 puts gibberish in the ticket such as – “EU call office prob l2”. This type of nonsense does not instill confidence in the helpdesk. Have L1 update the ticket with real English so non-helpdesk people know exactly why the user called and what the tech did to fix the problem. A proper problem description should look like this – “Mr. X called with a problem launching Microsoft Word. L1 reinstalled Word and the problem has been resolved. Ticket closed”. It takes any extra minute to write that out. It doesn’t have to be perfect, just short and informative. Once the ticket is closed, the end user should receive an email summarizing what took place. This email should include the following: Link to reopen the ticket, Link to leave feedback on the process, the helpdesk phone number, and the summary of the call.

Helpdesk Escalation

If L1 cannot resolve the problem and L2 is not available during the user’s initial call, the user should still receive an email with the summary of the problem and what the helpdesk is doing to resolve it. This email should include the L1 techs name that owns the ticket, his direct contact information, an expected timeframe, when the end user will receive the next update, and a link to view/update the ticket within the helpdesk system.

Expected Completion Time Passes

If the end user is expecting a call back within four hours, and four hours pass, there should be another communication. This time the ticket should be an automated email that informs the user their SLA has passed and the helpdesk manager has been notified and is working on the ticket immediately. The helpdesk managers contact information should be included and the end user should be encouraged to call the manager directly with any questions.

Within the next few weeks, I will update this site with some email templates that include all of the necessary information for every possible scenario. Check back soon.

Classifications

I know the ITIL people out there won’t like the classifications section of this post. However, ITIL simply does not work in the real world. I’ve worked on many helpdesks that spent a fortune to utilize the ITIL standards just to have the project fall apart after a few months. Simply, ITIL is too complicated and it is not worth the effort to train everyone on these standards.

Let’s just throw it out there…EVERYTHING is an issue. It doesn’t matter if the user is calling for a memory upgrade or to get an updated version of software, it is an issue. It’s not worth the time or effort to train your helpdesk techs to recognize the difference between a change, issue, problem or whatever else you want to call it. Simply, it doesn’t make a difference.

While we are here, a quick bit about upgrades and changes. If the user calls with an issue, it is up to the helpdesk to solve that issue. If it is determined that a memory upgrade fixes the problem, this isn’t a change or upgrade, it is solving the issue. If the helpdesk can solve the issue without the memory upgrade, they should. But if not, this is the fix and should be treated like any other fix. There should not be endless forms to fill out or 15 levels of approval. If the request is in a grey area such as a bigger monitor, the expense should be approved by the helpdesk manager, and one pre-designated manager from the business.

Severity

The vast majority of helpdesks choose the severity level based on how many people the issue is affecting. This is a flawed approach and only serves to help the helpdesks metrics on their reports to management.  Here is how it should look:

• Critical = Site wide network outage or production file server is down.
• Urgent = Site wide network problem or production server slowdown.
• Important = Issue preventing any employee from doing their job.
• Normal = Issue preventing any employee from doing a single aspect of their job.
• Low = Long term requests, insignificant changes, issue that does not interfere with an employee doing their job.

Based on severity, the appropriate L1 and L2 techs should be assigned immediately. As discussed earlier, the L1 technician should own the issue and have the authority to bring in the L2 techs he needs to resolve the problem for the higher levels of urgency.

Working Hours

The helpdesk should keep set hours to coincide with the business working hours in all time zones. In addition, after hours should be available to end users that have to report important, urgent or critical issues. The best way is a simple paging system that can email or txt the on call technician. A simple auto attendant that gives instructions – To report an urgent issue press #1, leave your call back number, the on call technician has been paged and will return your call within 15 minutes. For this reason, all helpdesk techs that will be on call should have the ability to login to the corporate network remotely to reset a password or solve important issues.

There are many other helpdesk best practices that will be discussed in other sections of the site. We will get into employment issues, helping moral, dealing with difficult customers, and a large variety of other best practices that will help you transform your helpdesk into world class support platform.