Checklist: Do your incident categories make sense?

Your team probably spends a lot of time registering categorizations for your incidents. But to what end? Does it help your team handle incident faster? Check out these 6 questions to see whether you’re getting the most out of your incident categorization.

Why categorize your incidents at all?

First of all, let’s start with the most fundamental question: why bother with incident categorization at all? Do you really need that information? Can’t you just register a call and leave it at that?

Incident categorization serves two main goals: to route and report.

Categorization helps you to quickly route a call to the right team. In most cases this is a manual process, in some cases this automated by means of A.I. or based on trigger words.

Categories also help you with root cause analysis. You get insight into the nature of recurring incidents. This enables you to solve underlying problems, generate relevant knowledge items or automate processes such as password resets.

1. How should you organize your categories?

We see all kinds of solutions in practice, but I recommend to base your categories on your services and symptoms.

Your main category is the services you deliver, such as ‘email’, ‘workplace’ or ‘Onboarding/offboarding’. Per category, you list the symptoms concerning those services, such as ‘email blocked’, ‘request workplace item’ or ‘new hire’.

Some tips concerning these categories:

• Don’t make your subcategories too specific. I see a lot of organizations that define the service (‘email’) in the main category and the possible cause in the subcategory (e.g. ‘mail server down’, or ‘Outlook bug’). The thing is: when registering the call you’re not yet sure what causes the issue. If you make the wrong estimation at the start of the incident handling, you’ll have to adjust the categorization during call handling.
• Don’t get too hung up on aligning your categories with your self-service portal. Any service could consist of a number of different tasks for your teams. Even if these tasks are in different categories, you still want to display a single, complete service to your customers.

2. How many levels should your categories have?

Two. Well, the correct answer is: no more than strictly necessary. But in most cases, two categories should be more than enough. Here’s why:

• You don’t want your team to be logging themselves to death. And you don’t want the categories to get too involved for people who use your self-service portal. It’s tempting to create a pathway into the depths of your categories, but that just makes your categorization less transparent.
• You want to make choosing a category as easy as possible. Every additional category level makes the act of choosing the right category more complex and time-consuming. Sometimes you know which subcategory you need, but don’t remember which main category this is part of. Reverse engineering your way through two upper categorization levels can be quite a hassle.
• Not every bit of information needs to be part of your categorization. You don’t have to keep splitting incidents up into ever smaller categories. Which brings us to the next question.

3. What information has no place in your categorization?

Sometimes I see organizations use categorization to register information that can better be registered some other way. Here are two examples of information that does not belong in your categorization:

• Assets the issue applies to. If you use specific assets in your categorization, for instance a certain laptop type, you need to adjust your categories when your organization introduces new a laptop type. It’s better to mention to relevant asset in the call and link to it.
• Department or team. I often see that categories mirror departments (e.g. ‘IT services’, Facility services’) or team (e.g. ‘Database team’ or ‘Application management’. The problem is that when you register the call, you often don’t know who will handle the call.

4. Is there a maximum for the number of categories?

Not really. As with the number of categorization levels, the correct answer here is: introduce no more than strictly necessary.

We tend to use the 7x7-rule as a starting point. Try to limit yourself to 7 categories and 7 subcategories for each category.

But by no means should you adhere to that too strictly. If I’m at a service desk that is best served by having 8, 9 or 10 categories, we’ll go with that. If you find yourself defining more than 10, it’s best to give a long hard think to whether you really need all those categories.

5. Should we have an ‘Other’ category?

This question tends to spark pretty intense discussions. I say: yes, please do include ‘other’ as a category. I spoke to professionals who avidly rage against the boundless void that this category can become, so why am I in favour?

If you don’t have a specific place for incidents that are hard to categorize, people will be forced to use categories that don’t really fit, which defeats the purpose of categories entirely. Any category could contain any number of incidents that don’t belong there. An ‘other’ category tells you that you have incidents that are hard to classify and immediately pinpoints these incidents for you. And if your ‘other’ category is always filled, it may even provide some useful information to help you improve your categories.

6. What to look for when reviewing categorizations?

Once you’ve decided what categories work for you, keep reviewing and adjusting your system as you’re using it. Do a monthly review after implementing or adapting your categories. After a few months, a quarterly review should be enough. Here’s what to look for when reviewing your categorization:

• Check the ‘Other’ category. Does it contain a lot of calls? See if you need to introduce a new category. Do some team members use this category regularly? Provide more explanation to your team members.
• Check the usage of all categories. Do some categories contain a lot or only a few calls? Split up or remove a category. In a helpful blogpost, Julie Mohr provides the following guideline: ‘If you have a CTI element (bucket) that holds 25 percent of your ticket volume, then the structure may not be detailed enough. If a bucket holds less than two percent, then it is probably too specific.‘
• One of the great advantages of incident categorization, is root cause analysis. Your incidents are grouped together, so root cause analysis at every review will help you find and resolve underlying issues for similar or recurring problems.

Interested in more Best Practices?

We regularly share our service management best practices. Here’s a selection of articles that you might be relevant to you:

• Understanding the Incident Priority Matrix
• A best practice onboarding process for Service Management
• 5 checklist items for Best Practice Change Management
• 5 ideas for a better Problem Management process (step-by-step)

Or download our Best Practice Service Management ebook: