Follow us

Incident Categorization – Reasons and Consequences

By | August 30, 2016 in ITIL

ITSM Incident Categories

I was thinking about incident management and categories and it came to me that really, every single day, we find ourselves being categorized and pushed into a specific pigeonhole. In fact, it happens so often and naturally that we’ve come to expect it:

  • Like in the frequent surveys after online purchases when we’re asked to choose from a pre-set list of responses, for example  “good, average, bad,” or “rate us from 1 through 9”
  • When we buy insurance or complete a tax return, we must always choose a work classification. If we don’t fit into one of their pre-set categories, then we just have to pick the nearest fit.
  • And, of course, when we log a call, even if we (as end users) aren’t presented with a list to choose from, we know the operator, whether human or automated, is deciding which of their little virtual boxes we best fit into. And if it’s via a self-service portal, we’ll end up choosing our own best-fit pigeonhole.

I mentioned insurance above deliberately since a friend of mine just changed his job role from marketing support to a training role. When the insurance company was advised of this role change, the premium increased by 7%. Now that’s the power of categorization!

Categories Help Us Process Data Meaningfully

While we may not always like it, or might feel that it isn’t human-oriented, this kind of categorization is a vital part of getting data and metrics collected, analyzed, interpreted, and used for improvement. Without categories, the data we collect cannot be easily turned into useful information and knowledge. But with categories our technology can process the data. It becomes more science, less art, and we have far easier reporting, trending, and pattern recognition – all of which should make managing the service delivered better, for suppliers and customers alike.

Why Incident Categories Matter

What that means for us in IT service management (ITSM) is that we need to take this seriously, get it right and keep it right.

The most obvious part of ITSM that needs good categorization is incident management (that’s where I started, at the beginning of this blog) – designing, capturing, and maintaining the incident statuses that will help us in our work. While you might think that an incident category only affects incident management folks, in fact the consequences of this categorization are far reaching. And because of the range of impact, one set of incident categorization isn’t likely to be enough. Instead there is usually a need for two sets: opening and closing categories, plus a great deal more of pre-set categorization along the way from one to the other.

Allow me to illustrate that with a simple example. Say you’re trying to create an invoice using a financial support service, but when you print it the figures don’t line up and the total overlaps the edge of the page. For sure, something is wrong,  so you call the service desk. Sometime in the future, the support professional who diagnoses and resolves this mistake will establish what caused it. We can imagine it might be the financial software, a hardware issue in the printer being used, network transmission, a mistake by the user, or something else entirely. But at this point, and certainly from your perspective as the caller, this is a fault with the financial service, and it should be categorized that way. If the service manager is not going to be aware of issues, it will look very unprofessional going to a review meeting without knowing how many calls have been logged relating to that service.

Getting the categorization wrong, or failing to categorize in a way that’s meaningful to service managers, will mean that the right information is not gathered and not having the right information inevitably makes other folks’ jobs that much harder.

Reaping the Benefits of Categorizing

On the other hand, once the investigation is done and an underlying cause found and fixed, it’s important to get a closing categorization that matches to the cause. Here you’re more likely to be looking at hardware, software, and the like – and perhaps also identifying the source, age, location, etc. of the offending item. If this categorization is wrong, then it’s hard to pinpoint faulty items and prevent them from causing future issues, like suspect batches or suppliers (internal and external) going unnoticed for too long.

The data collected during incident management needs to be categorized to allow easy and meaningful processing into information and knowledge. We need enough categories to reflect the range and indicate areas for concern; but not too many categories that we make it difficult to select the right one in the limited time we have when logging calls or updating records. It should be an ongoing challenge and balance between too many and too few, and to keep the categories reflecting our needs – and that changes over time. You can read more about that in this blog by Stuart Rance.

Could This Be a Lever for Your Improvement?

Do your categories reflect your organization’s needs? Do they offer initial matching to the customers’ and the users’ concerns? When incidents and errors are closed, does your categorization match the needs of problem, knowledge, capacity, availability, and supplier management? And if not, who is responsible for getting it right? And do they have the budget, support and understanding to make it better? If they don’t, then your ITSM performance will not be anywhere as good as it could and should be.

Image credit

Roy Eldar

About Roy Eldar

Former SysAid VP Support, with over 15 years’ experience in IT and large-scale production operations, Roy was responsible for the cloud infrastructure that powers SysAid and for our signature customer-centric support. Outside of work, Roy is an avid photographer, who also loves road cycling.

2 thoughts on “Incident Categorization – Reasons and Consequences”

  1. Avatar Ray

    First off, great article! What are your thoughts on not using categories in favor of CI/Business Service? I’m in a very large organization and we have no standardized definitions of when to use what and multiple categories that can equal the same thing? I understand we should minimize, but if all reporting is based on CI/Business Service, is there a real value to category?


  2. Joe The IT Guy Joe The IT Guy

    Hi Ray, Roy who authored this article is no longer with the company so I thought I’d pick up on your comment.

    There are pros and cons of both approaches – and are you using a single level of “categorization”? For instance, if every single email service issue is tagged simply as an email service issue, then it will overlook if it’s related to the software/service itself, relaying, mailbox sizes, user education, a third party receipt issue, etc.

    The key for me is to ensure that there’s sufficient granularity to use the collected data for some positive purpose such as improvement. But without making it harder to find the right category (and thus end up with 30% of issues in Other).

    These tips might help


Leave a Reply

Your email address will not be published.