Categorization is a critical aspect of many IT service management (ITSM) processes. Categorization helps us:
There’s a lot of good advice about categorization that is readily available via an internet search. A couple of great articles can be found right here on the SysAid blog. Stuart Rance shared his thoughts about categorization in his post titled Improving Categorizing Incidents. Another SysAid blog post, Incident Categorization – Reasons and Consequences, discusses the benefits of a good categorization scheme and the consequences of poor categorization.
But how do you go about defining your categorization scheme? I have some ideas about categorization that I’d like you to consider.
The most important thing to understand about categorization is that it is all about balance. If a categorization scheme is too simple, it will inhibit work flow and trend analysis. The categories will simply be too broad or vague to facilitate effective process execution or continual improvement.
The other end of the spectrum is a categorization scheme that is overly complex. While further definition may help with more precise workflow and analysis, this comes at a cost – the up-front time it would take a service desk agent to determine the exact category of an incident or request. While good documentation may mitigate this risk, keep in mind that a primary objective of a service desk is to complete its tasks in a timely manner. Service desk agents don’t necessarily have time to read through a lengthy procedure while the consumer is on the other side of a telephone call or chat session.
Also, categories can and should change over time. As services are introduced or retired from the managed environment, there will be impact to a categorization scheme. A good categorization approach recognizes that, and should strike a balance between the need for consistency for managing day-to-day activities with the flexibility needed when services do change.
Unfortunately, many organizations don’t take the need for balance into consideration when defining their categorization schemes. They often don’t think about how they want to leverage their categorization schemes in terms of workflow routing, reporting, or identifying improvements. As a result, I’ve seen them make the following mistakes:
Consider this – what is the trigger for categorization? How an incident is categorized is essentially based on what the consumer has said.
So why not take a consumer-centric approach to categorization?
In my experience, most categorization schemes have been defined following an “inside-out” approach. The scheme is defined based on the IT organization’s processes and services, and is pushed from “inside” IT “out” to the consumer. So why not look at it from the consumer’s perspective? Looking at this from the “outside,” or consumer’s perspective, what should the consumer’s experience be? This is known as “outside-in” thinking.
So rather than trying to categorize incidents by “hardware” or “software” or “network” (all IT-ish ways of looking at an incident), why not categorize based on the consumer’s perspective? This might look something like “can’t print,” “error message,” “not working or slow,” or “need help.” From this top level, the service desk agent can then drill into the issue to identify further symptoms that will assist in determining how to manage the issue. Following this approach essentially defines the roadmap for helping the service desk agent categorize the issue; for example, “not working > intranet > broken link” or “need information > software > excel”.
Here’s a few advantages of taking an outside-in approach to categorization:
Taking an outside-in approach to categorization may seem awkward at first. But by taking this approach, both the consumer and the service provider will benefit by facilitating a good customer experience (and for more on that, I highly recommend you read Sarah Lahav’s blog Bridging the Gap Between Service and Customer Experience).