Is it Finally Time to Fix Your IT Service Desk’s Incident Classification System?

Do you occasionally stop to wonder whether your IT service desk’s incident classification system, or structure, is fit for purpose? Whether it makes life easier or harder for service desk analysts and the people they serve, and/or is sufficient for service desk reporting including highlighting where the key issues are. If so, then you’re not alone in facing this data architecture challenge. Especially because this vital element of effective IT service delivery and support is often overlooked, or continually dropped down the service desk to-do list, thanks to the pressures of the incoming incident calls and tickets.

To help, this blog calls out some of the common adverse consequences of incident classification issues before offering up ten guidance points on how best to design, or redesign, an effective incident classification system.

The common consequences of incident classification issues

Where do I start? Most of what we do in IT support is built upon the employed incident classification.

For example, if an IT service desk’s incident classification structure is a mess it can be tricky for service desk analysts to correctly classify incoming issues. Which incurs more time than it should do and, more importantly, the resulting misclassification of issues leads to many other unwanted consequences.

These include issues with ticket prioritization and routing – where incidents might not receive the timely attention they need and could be passed to the wrong resolution group. Potentially being bounced from group to group and causing not only further delays in resolution but, more importantly, higher levels of lost productivity for the employees being supported.

At the other end of the spectrum, reporting and analytics – and improvement identification – is reliant on the quality of ticket data. So, if tickets are wrongly coded (or the “Other” option overused), any decisions made on the resulting data and information (in particular through trending) might be misinformed and, for example, improvement activity is targeted in the wrong places (with potentially important issues and problems missed).

Classification issues also arise across IT service management (ITSM) capabilities when there’s no agreed classification structure. Because when incidents, events, changes, problems, known errors, and workarounds use a common/similar classification structure it’s easier to link them in reporting and analytics. For example, when reporting all the incidents, events, changes, problems, known errors, and workarounds related to a given service to the service owner. IT’s knowledge management capabilities might also be reliant on the classification structure, again across multiple recordsets.

Designing the best incident classification system for your organization

Some might ask “Where can I buy a pre-built incident classification structure?” but this wouldn’t work. Or, at least, it wouldn’t work well – because one size doesn’t fit all when it comes to classification.

Instead, it’s best for organizations to create their own incident classification system using good practice guidance, such that it’s tailored to their own particular needs – from incident logging through to management information, including business needs that go beyond core ITSM practices.

To help, below are ten starter guidance points and readers are encouraged to add to them in the comments section below:

1. As with everything we do in the ITSM space, ensure that the incident classification structure is driven by business rather than IT needs. For example, look at what’s needed from a value creation perspective rather than trying to simply mirror the IT infrastructure.
2. Recognize that less is often more when it comes to incident classification. Make it as easy as possible for analysts to log and categorize incidents – here too many levels of classification slow things down, cause misclassification, and encourage the use of the “Other” option (either through confusion or to save time). In my experience, organizations should aim for three to four levels of classification.
3. Understand the various needs of incident classification. For example, in dictating priority (urgency) and routing a ticket to the appropriate resolution group during incident triage. Such that the classification capability drives the workflow and the efficiency of resolution.
4. Address all of the desired outcomes. Because, while making incident logging easier (and quicker) is desired, there’s also a need for sufficient granularity for any later analytical activities. For example, in meeting management reporting, proactive problem management, and continual improvement needs.
5. Work out which type of classification structure will work best for all your organization’s needs. For example, Category/Type/Item or Service/Category/Type/Item or Type/Service/Component/Symptom. There are pros and cons for each structure, with the most appropriate for your organization driven by its needs, i.e. what the captured information will be used for.
6. Do the math on what the level-by-level options mean and use this to drive simplicity and “leanness.” For example, if there are ten level one categories, where each has ten level two categories, where each then has ten level three categories. That’s already a lot of permutations. Whereas if you start with 20 level one categories the number of permutations adds far more complexity and greater scope for classification error (and the consequences that come with the errors).
7. It helps to start with a minimum number of categories/options – think “minimum viable product” – and to add more over time rather than starting with too many, including those options that rarely get used.
8. While there will likely always be a need for an “Other” option (although some organizations prefer analysts to take a “best fit” approach”), regularly monitor its use to identify the issues that are causing this, rectifying them whether they’re training/education-based or related to classification system oversights (or perhaps new needs). The use of closure or resolution classification codes can help to identify issues here (and beyond the use of the “Other” option).
9. It might be obvious but I’m going to say it anyway – don’t let analysts add new, potentially duplicate, classification options on the fly. This shortcut simply adds more work for everyone.
10. Review the use of the classification system over time. Needs change and issues – like the one in bullet #7 – will arise that necessitate a tweak, or perhaps a rethink, of the status quo. But remember that any changes will affect historical data trends though, with linkages potentially needed for analytics.

What else would you add to my list of incident classification guidance points? Please let me know in the comments.