Improving Categorizing Incidents

Recently a customer asked me how many different categories they should have for managing incidents. They seemed to think that, like a magician, I could pull an “ideal” number of incident categories out of a hat, and that they could somehow compare themselves to this to see if they had the right number. I gave them the typical consultant’s answer of “it depends”, because there really isn’t any right answer to this question. If you only have 3 or 4 categories then you are almost certainly doing something wrong, but if you have more than 1,000 categories then you probably have it wrong in the other direction. Between these extremes it really does depend on the scope of your service desk and what you’re using the categories for.

---

What Are Incident Categories Used For?

There are lots of different things you might use incident categories for. Typically organizations use incident categories to help them:

• Determine what information the service desk should ask for when logging an incident; for example if the user cannot log in to their laptop then you may want to find out what username they are using and what domain they are logging in to.
• Identify the correct SLA for the incident, which will tell the service desk how quickly the incident needs to be resolved.
• Identify scripts or tools that should be used for initial diagnosis of the incident.
• Decide which group or team will carry out initial diagnosis of the incident; for example there may be a dedicated team providing support for a critical line-of-business application.
• Identify when multiple incoming incidents are all related to a single problem, so they can be managed together to avoid duplication of effort.
• Decide when an incident should be escalated and which group or team it should be escalated to if the service desk cannot resolve it within the required time frame.
• Analyse trends to identify problems and improvement opportunities.
• Create reports that record the reliability and availability of individual IT services.

This is not a definitive list; you may have other reasons for categorising incidents. The important thing is to think about why you are categorising incidents, so that you can make sure the categories you define are appropriate for how you intend to use them.

How Many Category Fields Should You Have In Your Service Desk Tool?

It is very common to use categories and sub-categories to allow a larger number of overall categories to be easily managed. Many organizations use a three level hierarchy of categories. This has the advantage of limiting the number of choices presented to the service desk agent at any one time, while still allowing a larger number of overall categories. For example if the first level has 10 categories, and on average each of these has 8 sub-categories and these in turn have an average of 8 sub-categories then you have a total of 640 categories, but the dialog boxes from which categories are chosen only have 8 to 10 entries.

If you use this kind of approach then you need to be very careful that the hierarchy makes sense to the people entering the information. I have seen a situation where a service desk agent knew exactly what option they wanted to select in the final dialog box, but had to keep guessing to find the right higher level choices to get them to it.

As well as setting initial categories, you also need suitable closure categories for your incidents. Closure categories cannot be set when a call is logged, as they depend on the outcome of the incident. Closure codes are vital, however, in helping with your incident analysis, and they often have options based on the outcome of diagnosis, such as “user training issue”, “faulty hardware”, and “known error”.

Defining Categories

The best way to set about defining incident categories is to get all the people who need to be involved into a workshop. Start by agreeing on the purpose of your categories; you can use my list above as a starting point for your discussions. Based on what you intend to use the categories for, you can decide on how many different categories you need. At this stage you will answer questions like “How many different levels of categories do we need?” and “Is the impacted IT service the top level category or should it simply be a separately recorded item of information?”

In my experience, it’s better to have too few categories than too many. Very large numbers of categories cause problems for service desk agents who have to look through many different entries to find the correct one, and later on have little value in analysis, as each category has very few incidents.  This makes it harder to identify trends that you need to think about, or issues you need to address. So start with as few categories as you can, and add more as you find the need for more information.

Summary

In summary, you need to think about incident categories in terms of what you use them for, rather than just allowing people to define more and more categories that may be of very limited value to you or your customers.

If you haven’t reviewed your incident categories recently then why not spend a bit of time looking to see if they are still fit for purpose. Improvements you make in this area can make life much easier for your service desk agents, and ultimately for your customers.

Image credit

Like this article? You may also like: Defining Metrics for the Service Desk

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.