The Importance of Help Desk Process and Evaluation, Part II

In my last post, I explained how to do self-evaluation on your help desk process. In this post, we'll look at how to analyze the results.

Hopefully by now you are beginning to see holes and gaps and you might not be sure what to do with your findings. Also, hopefully you're not feeling overwhelmed by what might seem to be insurmountable gaps. If you don't know where to start, let's go back to those "pain points" I mentioned in the previous post.

Please note that in order to perform accurate root cause analysis, you will need a way to extract mined reporting data from your incident management ticketing system. You will need information about your product/service - most taxonomy is cataloged down to three levels. Also, you'll need to be able to filter your data by days and weeks in order to measure your error rate and monitor improvement. You will also want to do analysis on data such as technician name, resolver group, satisfaction surveys (if available), number of ticket "touches" or "bounces", and anything else that might shed light on trends. Let's look at some possible scenarios.

NOTE: This analysis assumes that you know how to navigate Excel pivot tables, as you'll want to export your taxonomy in order to filter and sort your data.

• Misroutes - Tickets are being misrouted to incorrect resolver groups on a consistent basis.
  
• Poor Documentation - Tickets are being escalated/dispatched without enough information in the ticket.
• Incorrect Taxonomy Selection - Technicians select the incorrect product/service causing the ticket to be incorrectly dispositioned.
• Unclear Support Path - This occurs often with new product roll-outs, products/services that are infrequently called about, or new technicians that may not have been trained adequately.
• Poor Troubleshooting - Informaton documented about the problem and associating symptoms to the problem are so far off, causing "dead-end" troubleshooting or incorrect support.

So, those are some common symptoms. Now, ask yourself some questions. Look for commonalities or trends surrounding:

1. What product/service types are being misrouted?
   
2. Do you see any trends with regards to specific dates the problems began to occur?
   
3. Filter by product/service and see what's being misrouted. Was there a new product roll-out? Change to an existing service?
   
4. New agent training that recently occurred?
   
5. What group is receiving the incorrect tickets? If there are several, capture them individually as you may have different reasons why it's happening to each group.
6. Was there a recent change to a support process and was it effectively documented and communicated?
7. Is the knowledge management system (KMS) up to date?
8. Is the KMS easily indexed and searchable? (Note: To help stay on topic, I'm saving KMS's for another time, as it is definetly a subject worthy of it's own topic)
9. Is there a "shadow process"? This occurs when diligent knowledge management falls to the wayside and "tribal" knowledge takes it's place. Basically, your support process might be dependant on whoever is giving direction on how to do it. Who knows the correct way to do it?
10. Is the product/service in question something that is not utilized frequently? Perhaps due diligence to capture the support information was not performed.
    

As you can see from this evaluation, most issues about poor support and quality surround:

• Training
• Knowledge Management
• Communication
• Change Management

While it may seem that we've drifted from our topic, I can tell you that all of these components fold in to what I would define as solid service desk process. You might also notice that complete service desk process is not exclusive to the actions of the technician. Meaning, solid process begins way before the technician gets to the phone. The point of this excercise is to look at all the extraneous variables that led you and your help desk to where you are.

For some, you may conclude at this point that you have more work to do than direction from just a single blog can provide. For the sake of others, we will assume that your processes are not as internally flawed as in the examples. I'll stop for now and in the next post we'll look at a more realistic view of where your desk might be and I promise we'll get to building the elements of a solid process.

Additional Reading...
How to do Root Cause Analysis?
How to create an Excel pivot table?

The Importance of Help Desk Process and Evaluation

Recently I had an experience with a transitioned help desk that really showed me how a lack of thorough processes and a solid knowledge management system can really sink your help desk right out of the gate.

This made me reflect on how detailed processes play such a big part to the success of a service desk. In this post, I will detail how I approach process analysis and/or creation. For this topic, I will not go in to detail about knowledge management, as we will cover this later.

To determine the strength of your processes - whether transitioning, creating, or analyzing an existing desk you must look at the pain points you are suffering. Pain points come by way of:

• Nasty emails from your tower/business peers such as a manager in another department wondering why their subordinates are sitting idle "waiting on IT to fix things".
  
• They may come from your customers in the form of negative surveys or continuous call backs wanting ticket updates.
  
• Perhaps your technicians continuously complain that they don't know where to send a ticket or they always have "those strange, one-offs" for which no support is known.
  
• Even worse - tickets are being mis-routed to incorrect groups en mass causing frustrations, flare ups, and finger pointing in your weekly status meetings.

If you find yourself
sitting in front of email all day...
being tapped on the shoulder constantly....
hiding in the bathroom to take breaks....
explaining yourself to your boss more than envisioning the future of your desk... then you probably have weak or inadequate processes.

So, where are you at? Do you have processes at all? No, I mean documented processes. If sharing the process means you have to tell me what it is, then it's not really a process. Well, I suppose you could call it a process, but it's a process prone to change, error, miscommunication, you might forget it, or heaven forbid it "walks" out the door. That reminds me of a story about this guy Vinnie who was my team lead when I was a support technician.

Vinnie had the life....he didn't have to be on the phones, he only had to answer our "next-level" questions if they weren't in the knowledge base. But he mostly played around with little trinket puzzles and surfed video game blogs. Vinnie hoarded all the information he could find and locked it inside his head. He wouldn't share or document things. Naturally, he was the most valuable player on the team. He had sponged everything. The desk was very unstable after he left.

My point is a process should be clear, hold accountable those who create, change, and implement the process, and provide clear direction to anyone who should read the process.

So, analyze where you are currently and get a good starting point. Create a focus group consisting of one of your brightest technicians...not necessarily the most technical. You want to see what's broken with your internal processes and this will be very different than just something your run of the mill technical person might be good at. If you don't have someone to help then perhaps you are the best to pick apart your process.

First, use the Input | Process | Output methodology to build a "road map" of your current processes. I've included a basic example above. Start at a high level such as the example above and begin "peeling the onion". You will find yourself creating more process boxes, decision trees, and you will probably find some questions. If you get to a dead-end or if questions start to arise then "light bulbs" might begin going off. That's okay. Make notes, but don't try to create solutions yet. You probably don't have all the correct information to complete the exercise in it's final state. We're just looking at the current state process.

Complete this exercise and we'll discuss more on the analysis and solutioning of the process problems in my next article.

A quick introduction...

Hello there....if you're reading this then you probably have an interest in trends surrounding IT, Service/Help Desk. For some time I've wanted to get my thoughts and ideas out for other's to ponder, as the direction of service support is ever evolving making the need for individuals and groups to share best practices all the more important. Please email me with any questions or suggestions you may have for topics.