The Greatest Ever Code to Incident Categorization

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