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?