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.
There are lots of different things you might use incident categories for. Typically organizations use incident categories to help them:
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.
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”.
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.
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.