Help Desk Ticket Categories: Build a Taxonomy That Survives Reporting

The best set of help desk ticket categories is a short, two-level list where every ticket has one obvious home and “Other” stays under 10% of your volume. Anything longer or vaguer looks organised inside the ticketing tool and falls apart the first time somebody asks you for a report. The category field is the only thing that turns a month of tickets into a trend, so it deserves more care than it usually gets.

ITIL v3 came out in May 2007 and a lot of teams are tidying up how they log incidents because of it. The framework says to categorise every incident. It doesn’t say how many categories to use or what to call them, and that’s the part that decides whether your data is any good. I started on help desk and network operations desks, and the pattern is the same everywhere: the list gets built once in a meeting, then it grows by one entry every time somebody can’t find a fit.

How many levels should a category list have?

Two. A category and a subcategory, nothing deeper.

The arithmetic is what settles it. Take ten categories with six subcategories under each. Ten times six is 60 places a ticket can land, and an agent can scan 60 options in a few seconds. Now add a third level. Eight categories, each with eight subcategories, each with eight sub-subcategories gives 8 × 8 × 8 = 512 places a ticket can land, and nobody scans 512 options while a caller is talking. They pick the first thing that’s close enough, and your data fills with near misses. ITIL training firm Purple Griffon says the same thing more politely: overly complex schemes lead to miscategorisation, so the scheme has to be easy to use as well as complete.

Phone and email tickets behave differently here. On a phone call the agent is typing while the customer talks, so the choice has to be fast. Email tickets get filed after the fact, often in a batch at the end of the shift, and that’s where lazy defaults creep in. If your tool lets you leave the category blank, some of those tickets will be, so make the field mandatory.

What should you call a category?

Name it after what the customer experiences, in words the customer would use. “Email: can’t send” survives a reorganisation. “Exchange team” doesn’t, because the day the team changes name or the product changes hands, every historical ticket in that bucket becomes a riddle.

Keep requests and breakages apart at the top level. Something that’s broken and something somebody wants are measured differently, and mixing them makes your resolution times meaningless. A new starter’s account request and a mailbox that stopped working shouldn’t sit in the same average. Keep priority out of the category too. A category can suggest a default, but urgency depends on who’s affected and what they can’t do, which is the logic behind the tiered SLA matrix. “Email: can’t send” is a nuisance for one person and an emergency for the sales floor on the last day of the quarter, and a category that dictates priority will under-serve the second case every time.

Then test the list with a simple exercise. Take 20 closed tickets, hide the category, and ask two agents to file them independently. Count the tickets where both agents chose the same category and subcategory. Divide by 20 and multiply by 100 to get the agreement rate. If 18 of 20 match, that’s 18 ÷ 20 = 0.9, or 90%, and I’d want 85% or better (17 of 20) before I trusted the list. Every disagreement points at two categories that overlap, such as “Password” and “Account access”, and you fix it by merging them or writing a one-line rule for which one wins.

Why is “Other” the category to watch?

Because it’s not a category. It’s the queue of tickets nobody could be bothered to file properly, and it grows in the dark. Everyone adds an “Other” to be safe, which is fine, but nobody measures it, which isn’t.

Here’s an illustrative example, not a real data set. Say you handle 1,200 tickets a month and 264 of them are filed as Other. The share is 264 ÷ 1,200 = 0.22, so 22%. Nearly a quarter of your volume is invisible in every report.

Next, pull a random sample of 60 of those 264 tickets and read them. Say 36 of the 60 clearly belong in categories you already have. That’s 36 ÷ 60 = 60% misfiled. Apply the same 60% to all 264 and you get 264 × 0.6 = about 158 tickets that were simply put in the wrong place. The other 264 − 158 = 106 tickets, the remaining 40%, cluster into a couple of themes that deserve categories of their own.

Once you refile the 158 and create the new categories for the 106, Other holds only the tickets that genuinely fit nowhere. If you left those 106 in Other, the share would be 106 ÷ 1,200 = 0.088, or 8.8%, which is under the 10% line. Either way, you’ve found two things your customers were asking about that your reports never showed.

You can track this share in Excel. Set up a worksheet called Tickets with one row per ticket and headings in row 1. Put the ticket number in column A, the date opened in column B, the month in column C, the category in column D and the subcategory in column E. If you have 1,200 tickets, they fill rows 2 to 1201. On a second worksheet called Report, click cell B2 and type: =COUNTIF(Tickets!D2:D1201,"Other")/COUNTA(Tickets!D2:D1201). Format the cell as a percentage.

Here is what that formula does, reading left to right. COUNTIF(Tickets!D2:D1201,"Other") counts how many cells in the category column say exactly Other. COUNTA(Tickets!D2:D1201) counts how many cells in that same column are not blank, which is your total number of categorised tickets. Dividing the first by the second gives the Other share. In the example above it returns 264 ÷ 1,200 = 22%. Add the new month’s tickets to the bottom of the Tickets sheet and extend the range in the formula (D2:D2401 for 2,400 tickets, say), or format the data as a table with Ctrl+T so the range grows by itself.

My rule of thumb is that when Other passes 10% for a full month, someone reads a sample and either fixes the filing or adds a category. Don’t delete Other. Make it visible, and make it embarrassing to let it grow.

How do you keep a category list stable enough to report on?

Change it on a schedule, not on demand. If agents can add a category the moment they feel the list doesn’t fit, you’ll have 40 entries by spring and no two months you can compare. Review the list once a quarter, add what the Other sample told you to add, and merge rather than delete anything you retire so the history still adds up. Keep a third worksheet in the same workbook, called Categories, with three columns: the category name, the date you added or retired it, and the reason. When a number moves in the report, that is the first place to look.

Reporting is then a pivot table built from the Tickets sheet. In Excel 2007, click any cell in the data, then choose Insert, then PivotTable. Drag Category into Row Labels, drag Month (column C) into Column Labels, and drag Ticket number (column A) into Values so Excel counts the tickets in each cell. One glance tells you which category grew from one month to the next, and that’s the question most of the KPIs in my post on tracking KPIs quietly depend on. A number you can’t break down by the cause of the ticket is a number you can’t act on.

Last, resist the urge to add a category whenever a manager asks a question the list can’t answer. Ask first whether it’s really a question about the problem or about the context. Which site, which product and which customer tier belong in their own fields, and categories should describe only what went wrong.