Incident Management Categorization

[Chris Shakespea]

Introduction

Although every organization is different, there are several points of prescriptive guidance when advising customers on configuring categories. Please also refer to the Incident Management Implementation Workshop deck and Incident Management Process Guide for areas to discuss with customers and general recommendations.

1. Consider why the customer is categorizing – Reporting?  Routing?  A different purpose?
2. Consider what else the customer is using to accomplish or segment their incidents – Do not duplicate efforts.  For example, if you have a CI, do you need the category to be extremely specific?  The general guidance is that if you are very specific, then you run the risk of being less accurate as well.
3. Analyze the customer’s current categories – What does that look like?  Are there categories that could be eliminated or need splitting?  Is there correlation between any categories and major incidents or problems raised?
4. Routing vs Root Cause – Categories are inherently set at the start of the Incident process.  Therefore, they are good for guiding the initial routing but not necessarily effective for reporting the root cause.  Some customers choose to modify closing codes to give more insight into root cause or look at the starting and ending categories for correlation.  Categorization is not the primary means for root cause determination, as customers are moving to a more business service approach to determining the root cause of the incident.

Common Pitfalls

• Making categories too granular – More categories do not mean better data.  Agents will categorize incidents incorrectly because they won’t search for the correct category.
• Adding an “Other” category – If agents cannot find the correct category, they often put it in the “Other” bucket.  For example, if 30% of the incidents in the “Other” category are password resets, then “Password Resets” needs to be a specific category.  

Here is a simple starting template that is detailed enough so customers do not just pick the first thing or can’t figure out where to put things, but simple enough that customers do not start getting similar incidents categorized differently.  This is meant to be a starting place only.

Once there are no ambiguities within your categories/subcategories, then customers can start applying AI to predict those categories much more effectively.  The guidance that applies to using categories manually applies to that for AI as well.

[jMarshal]

Great article! I feel as though Incident categorization is something that most organizations do not pay enough attention to, from the user's perspective (both T1 agents and customer users, that is).

A lot of the time, the categories are set up from a "ITOM perspective" in an effort for the business to "improve their services", in an attempt to "reduce incidents"...but this is folly, IMO. You will never eliminate incidents, nor should you want to -- restoring a customer's service to pre-incident state should be the only goal of incident management...there are other ITSM processes to account for that CSI (along side Incident Management). There is no shame in a high number of incidents, but rather in the MTR of those incidents. This affects the T1 agents fielding the first contact, the most -- they are trying to balance this categorization between what the customer is saying and what they think the T2 technicians (or business leaders) want to hear (usually information about "how to fix the incident").

At my organization, we took an approach of categorization where we start with "Service" as the top category -- which is what the customer saying that they are having a problem with. Please note that this "service" is NOT mapped/synchronous to our actual Business Services, but instead it is just a descriptive label to help the T1 agent's interpret the end-user's experience with the technology that they are using. It is a choice list. The "second-level categorization" (granularity) is then "symptom", which is another choice list with selections that are dependent on the first category. To round this out, we require a CI to be added - to describe what the problem is with.

We then also re-classify on resolution, to analyze what the customer reported the issue was against what we did to fix it. There is a client script which will automatically copy the initial values to the resolution values, to save our agents time (a lot of the time, it is unchanged).

---

@Chris Shakespea wrote:

Common Pitfalls

• Making categories too granular – More categories do not mean better data.  Agents will categorize incidents incorrectly because they won’t search for the correct category.
• Adding an “Other” category – If agents cannot find the correct category, they often put it in the “Other” bucket.  For example, if 30% of the incidents in the “Other” category are password resets, then “Password Resets” needs to be a specific category.  

"Other" is such a double-edged sword! I feel it is necessary...but must be analyzed regularly. We used a UI Policy to pop a custom, mandatory write-in field for "Other", which we use to determine categorization effectiveness, so we can maintain it and keep it effective.