The Greatest Ever Code to Incident Categorization

3436159484_32392fe584_b

Ok maybe not greatest ever… but it sounded like a sexier title, like I’m a super hero or something. Anyway…

I can’t even begin to tell you how many hours, even days, I’ve spent talking about categories in IT tools.  First, it never seems like there’s such a thing as a perfect category scheme; it just doesn’t exist.  Second, a lot of companies out there don’t even fully understand their own services, so how can you categorize something that’s not fully understood? For example, how should an incident with an Exchange server be categorized:  Server issue?  Email issue?  An issue with an email service?  And often errors will show at an end-user’s computer before it’s known that an item in the infrastructure is the cause.  Third, it’s not always clear why incidents need a category anyway.  Are you hoping to improve routing?  What about your knowledge base?  Then there’s always the input into problem management.

Since every company has their own culture, I can’t prescribe a cure-all method for your categorization.  What I can do though is give some tips and guidelines for how to create or reorganize your categories.  I’ll just call this Joe’s Rules to Not Messing up Categories

Rule #1

Plan on continually improving your categorization scheme over time.  I had a friend that would say, “I can 100% guarantee this will not be 100% correct.”  If you’re starting over in a new tool, or cleaning up existing categories, don’t fall into “paralysis analysis” as you, or your team, discuss and decide the future categories.

Rule #2

Know why you’re using your categories.  Incident categorization can be used for researching recurring problems, auto routing of tickets, input into a knowledgebase, or even to help with prioritization.  Knowing “why” will help you decide on what to categorize, what categories to use, and even how they should be named.

Rule #3

It’s better to start small and expand, then to start with hundreds of detailed categories that need to be combined later.  A good example is email.  Start with a simple email category.  Later in time if you notice there’s a large amount of client based email issues compared to server issues, and it’s difficult to differentiate between the two, split “Email” into “Client Email” and “Server Email.”

Rule #4

Never simply delete or rename a category in your IT tool.  Historical data is one of the most important parts of an ITSM program, so preservation is key.  If you’re splitting a category into two more specific categories, create the two new categories and, if possible, set the original so that no one can select it as an option.  Of course, this all depends on the technology you’re using, but it’s a good rule of thumb.

Rule #5

Don’t limit categorization to a single field.  The most versatile type of system I’ve seen is a combination of a CI, a service, and a category.  To show an issue where a user was having a problem with email, the ticket may be filled-out as:

  • Service:     Email
  • CI/Asset:   Dell-123456
  • Category:  Application -> error message

This type of structure, with each field independent of each other, allows reporting on a specific CI, a specific service, a category, or a combination of those fields.  This allows data to be reported on by different means.

Rule #6

Probably the most important rule, never, ever, ever, ever, ever, ever….use “Other” or “Miscellaneous” as categories.  If you do, I can guarantee that over 50% of the tickets will have end up submitted into those categories.  If something doesn’t quite fit a category, have the service desk analyst select the best fit and then include a note on the incident for later review.

Rule #7

Plan on periodic category reviews.  Be sure to include representatives from every level of IT.  You can bet that a service desk analyst would categorize an incident as something different than a server administrator, so plan on lots of discussion.  It would also help to have someone from the business side of your organization involved in those discussions to help give insight as to how users are describing the “broken stuff.”

Rule #8

To continue from rule #7, it’s also a good idea to have a resolution category alongside the reporting category.  This can help correlate the types of errors occurring with the types of problems.  It can even be used to help with auto-routing of tickets.

Rule #9

Try to stay away from specific vendor names.  While Outlook is a very common email application, there’s no guarantee it will be around in a few years.  Keep with “Client Email” or “Email Application” and you’ll save yourself renaming categories when vendors come and go.

Rule #10

Always keep the final result in mind – reporting and metrics, with maybe even a little bit of routing.  It could take a few attempts to put together the best scheme for your environment, but during your journey don’t forget that this is to help transparency within your organization.  From spotting trends, to root cause analysis, getting your categories to add value will be a key to success – no pressure then!

And remember this code may not necessarily be a perfect fit for your organization. Treat it as guidelines, as one set of rules certainly does not fit all.

If you’re looking for a starting point for reorganizing your categories, check out the SysAid post IT Benchmarks: Incident Classification Categories.

Image Credit

  • Pingback: The Greatest Ever Code to Incident Categorizati...()

  • Pingback: The Greatest Ever Code to Incident Categorizati...()

  • Juan Esposito

    Thanks you for excellent tips! But I don’t agree with rule #6.
    I would say that an “Other-category” is good to have and it’s better than having wrong categorizations made. In this “bucket” you will get everything that is not/can be correctly categorized and can analyse the types of tickets and then create some new categories(if needed) and then re-categorize the tickets.
    Or else it will be completely impossible to find theese tickets. One agent categorize it as Server, the other as Software, for example…

    • Thanks for your comment, Juan. I do understand what you’re saying but I still say that while an “Other” category might look helpful, in reality it can cause time-strapped agents to use it as a dumping ground without due consideration of a more appropriate category. Probably best to check it and see whether this is true for an organization – use one for a short period and access whether it is home to just a few tickets or full of tickets that should have been categorized elsewhere. Let me know how it goes.

  • Dave Foote

    I am really interested in how rule 5 has played out in the real world!

    Do you have any example schemas you can share or further experiences you’ve had with using it?

    • Michael Slabodnick

      Most traditional incident categorization involved a nested tree hierarchy. I’ve commonly seen two levels of categories, but have also come across those companies that have taken their categorization to a third, and even fourth level! Imagine having over 1300 possible categories in three levels – the administration alone would be a nightmare! Limiting categories to be simpler, and taking advantage of other useful pieces of data, administration can have less overhead while maintaining useful reports.

      A real-world example that proved to be useful for a hospital in central Ohio involved a service as one field. Some example services that were entered into the ITSM system included email, Epic (their electronic medical record system), Windows, etc. Some of the services could even be more specific. Instead of just Epic, there could also be Epic – ED (for emergency department). The goal was to try and report on the application, or service, that was being used at the time of the incident.

      Another field on the form would be the CI or asset, with a reference to a data source that was populated by asset management. From using this piece of data, they could report on which device they were using. Since a device type was also included as part of the asset record, reporting allowed to break reports down by device type.

      The third field used for the classifying was the category itself. The category was meant to describe the type of issue the user was experiencing, with a two-level hiearachical system. Some examples used would be Application -> Error Message, or Network -> Connectivity. There’s a lot of combinations for categories but they kept it as simple as possible to keep the incident process efficient.

      With all incidents containing three different fields of data, reports could be created by services, with breakdowns to show the “errors,” or categories. If needed, the same service report could then have breakdowns by device type. Also, reports could be generated by the category with breakdowns by services. It was the flexibility of viewing trends by different breakdowns that gave a better view into potential problems. Once a potential problem was identified, incident tickets could be reviewed for further details to determine if a problem existed, or if the trends were simply a coincidence.

      • Awesome, Michael – thanks for your input – great example!