Incident Categorization – Reasons and Consequences

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