Why Ticket Categories Exist and Who Uses Them

Tuesday, 08:40. Omar has the queue open at Meridian Parts and the fourth new ticket of the morning in front of him: "My screen goes black when I log in from home, but it is fine in the office." The form has a field called Category with a pick list of four entries: Hardware, Software, Network, Other. Omar reads the list twice. The screen is hardware. The login is software. The "from home" is network. He picks Other, which is what the person before him picked for the previous three, and moves on. That is because the queue is not getting shorter while he thinks about it.

Nobody at Meridian Parts can say what the Category field is for. It was there when the tool was installed. Somebody typed four entries into it on the first day. It has been filled in, after a fashion, ever since. Nothing reads it. No report is built on it, no ticket is routed by it, and no knowledge article is found through it. It is a label on a filing cabinet that nobody opens. Omar is right to spend no time on it, because the field has not earned any.

A category is a label on a ticket that says what kind of work the ticket is, chosen from a fixed list. So the ticket can be routed, counted and found alongside others of its kind. A taxonomy is the list itself: the set of categories and the way they are arranged. This article is part of our Ticket Categorization & Taxonomy series. And it is the one to read first, because every other article in the series assumes you know what the label is for. Most desks never ask. They inherit a list, fill it in, and wonder why the monthly report says their biggest problem is Other.

It covers what a category is and what it is not. Next come the three people who use a category and what each of them needs from it. Then it covers the one test that tells you whether a category earns its place. It covers the mistakes that happen when a category is asked to do another field's job. It ends with where the category lives in a typical tool, the two moments a ticket gets categorized, and how few categories a small desk can get away with. The category purpose checklist at the end is built to be copied.

A Category Is a Label With a Job

A category exists to support a decision, and a category that supports no decision is filing. Filing feels productive. It has the texture of order: every ticket gets a label, the labels have a hierarchy, the hierarchy has a document. But a label that nothing reads is a cost with no return. The triager spends four seconds choosing it, times forty tickets a day, times every working day of the year. The return on those seconds is a field nobody queries. The category must do work. The work is one of three things: route the ticket to the right person, count it with others like it, or find the fix that worked last time.

The useful comparison is the label on a folder in a filing cabinet. The label is worth writing if someone will open the drawer and look for it. If the only person who ever opens the drawer is the person who filed the folder, and they remember where everything is, the label is decoration. Category lists on help desks are usually decoration, not because anyone intended that but because nobody asked the question this article is about. Who opens the drawer, and what do they need the label to say?

Three people open the drawer. The triager, who needs the label to decide where the ticket goes. The report reader, who needs the label to count what the desk is spending its time on. And the person searching for a fix, who needs the label to find the last ticket like this one. Each needs something slightly different from the same field, and a good taxonomy serves all three without becoming three lists. A bad one serves none of them and still costs four seconds a ticket.

The First User: The Triager, Who Needs to Route

Triage is the sorting step: someone reads each new ticket, decides what it is, how urgent it is, and who should have it. The triager uses the category to answer the third question. "Printing" goes to whoever handles printers. "Access" goes to whoever has the rights to grant access. "Network" goes to the person who understands the switches. At this moment the category is a routing instruction wearing a noun.

For routing to work, the category must map to a person or a group, and the mapping must be known. If "Printing" could go to any of four people depending on the day, the category routes nothing. In that case, the triager still has to think. If "Hardware" covers laptops, projectors, phones, the door entry system and the coffee machine, it routes nothing either, because the people who handle those things are not the same people. A routing category is judged by one test: when the triager picks it, do they also know who gets the ticket? If not, the category is too broad or the mapping was never written down.

On a small desk, routing by category is less useful than it looks, and it is worth saying so plainly. A desk of two technicians does not route; both of them see everything and take what is next. The category still helps the triager, but differently: it is a forced moment of reading. Picking "Access" instead of "Other" means the triager read the ticket closely enough to know what it was about. That reading is where the real triage happens. The discipline of that first touch is covered in What Triage Actually Is. The category is one of its outputs, not its purpose.

Routing also has a level above the category. Many tools route by department before anyone reads the ticket. In those tools, the requester picks a department on the web form. Each mailbox belongs to a department, and a chat visitor chooses one. The department is the coarse sort and the category is the fine one. A desk that puts "IT", "Facilities" and "HR" into its category list has confused the two levels, and will route every ticket twice, differently.

The Second User: The Report Reader, Who Needs to Count

The report reader opens the drawer once a month and asks one question: what is the desk spending its time on? The category is the only field that can answer it. Priority says how urgent the work was; status says where it is; the assignee says who did it; the category says what it was about. A month of tickets with honest categories can be counted into a short list, "Access 38 percent, Printing 14, E-mail 11". And that list is the beginning of every improvement the desk will ever make. Without it the desk knows it was busy and cannot say with what.

Counting makes different demands on a category than routing does. Routing wants a category to map to a person; counting wants it to map to a cause, or at least to something that can be fixed once. "Printing" is fine for routing and poor for counting. Forty printing tickets might be forty jams on one printer, which is one fix. Or they might be forty driver problems across forty laptops, which is a different fix. The report reader wants the category to say which. This tension, between what the triager can know at open and what the fixer knows at close, is the whole subject of Categorize at Close, Not Just at Open. The short version is that the category gets set twice.

Counting also needs the categories to be mutually exclusive and roughly even in size. If "Software" holds half the tickets and "Projector" holds two, the report says "half our work is software", which is true and useless. If a ticket could honestly be filed under two categories, two triagers will file it two ways and the counts will be fiction. A report is only as good as the consistency of the hands that filled the field. And the field is filled by tired people at four in the afternoon. The list has to make the consistent choice the easy choice.

A category report that nobody reads is the most common kind, and it is worth naming why. The report is produced because the tool offers it, lands in a folder, and sits beside eleven others. Reading it takes twenty minutes a month and produces one question, which is the subject of Categories That Make Reports Worth Reading. For now the point is narrower: the report reader is a real user of the category, with real needs. The list must be built for them even though they only turn up once a month. (They do turn up. Usually the week before budget.)

The Third User: The Person Searching for a Fix

The third user is a technician with a ticket open at 16:10 who is sure the desk has seen this before. The requester's e-mail will not send; the error mentions a certificate; somebody fixed this in the spring. The technician searches. If the previous ticket was categorized "E-mail" and the resolution note says what was done, the search takes a minute. If it was categorized "Other", or "Software", or under the name of the requester's department, the search takes the afternoon, or fails. In that case, the fix is rediscovered from scratch. The category is a search handle, and a search handle is only as good as its specificity.

The knowledge base is the formal version of this. A knowledge base is the desk's collection of written answers: how to reset the thing, what to do when the other thing fails. A knowledge article is far easier to find, and far easier to know you need to write, when the tickets it would answer share a category. Twelve tickets a month under "E-mail" with "certificate" in the close note is a knowledge article that has not been written yet. Twelve tickets a month under "Other" is nothing; they are invisible to the person who would write it. Categories make the gaps in the knowledge base visible, which is the only way gaps get filled.

Full-text search softens this but does not replace it. A good search across tickets and knowledge articles will find the word "certificate" wherever it appears. Most tools now search the full text of both. But the requester did not write "certificate". They wrote "my e-mail is broken again", and the technician who fixed it wrote "sorted" in the resolution. The category is the one piece of structure that survives bad prose. It is the field that lets a search for e-mail tickets return the one whose description says nothing useful at all.

The searcher needs the category to be about the thing, not about the person. "Finance department" is a terrible category for search, because finance has every problem everyone else has. "Payroll application" is a good one, because whatever went wrong with it last time is likely to go wrong again, in the same way, to the same application. Categories built on the organisation chart serve nobody who is looking for a fix. They serve the organisation chart, which was not asking.

The Test: What Decision Does This Category Support

Every category on the list must pass one test, and the test is a question: what decision changes because this category exists? There are three acceptable answers. It changes who gets the ticket, which is routing. It changes a number somebody acts on, which is reporting. It changes what a technician finds when they search, which is knowledge. A category with one of those answers earns its place. A category with none of them is filing, and filing is removed, however long it has been on the list and whoever added it.

Run the test out loud, with a colleague, because it is harder to pass than it sounds. Take "Hardware". Who gets a hardware ticket? "Depends what it is." What number does the hardware count change? "We do not really look at it." What does a search for hardware find? "Everything." Hardware fails three times. It is on nearly every category list in the world. Now take "Laptop battery". Who gets it? "Sam, who orders the batteries." What does the count change? "Whether we order in bulk, and whether that model is a lemon." What does the search find? "The eleven tickets about the same model." Laptop battery passes, if the desk sees enough of them to matter. That is the next test and belongs to Avoiding the 400-Category Monster.

The table applies the test to eight candidate categories from a general IT desk. Read the last column first; it is the verdict, and the verdicts are not always the ones the list-maker expected.

Three of the eight failed for the same reason: they were another field in disguise. That failure is common enough to deserve its own section.

What a Category Is Not For

A category describes what the ticket is about, and nothing else. The temptation to make it carry other things is constant, because the category is usually the only editable pick list on the form and it is right there. Four other fields get smuggled into it, and each one breaks the three users in a different way.

Priority is not a category. "Urgent" in the category list means the ticket has two priorities, one in the priority field and one in the category. They will disagree by Thursday. Priority is the rank that sets how fast the ticket must be answered, decided from how many people are affected and how soon it hurts. It has a field of its own. How to set it is the subject of Impact Times Urgency in Practice. The category's only job is to stay out of it.

Status is not a category. "Waiting on vendor", "Pending approval" and "On hold" describe where the ticket is in its life, not what it is about. A ticket about printing does not stop being about printing when the vendor is slow. Statuses belong in the status field. When the tool's status list is fixed, as it is in many small-team tools, put the waiting state in an internal note or the subject line. The category list stays out of it, because a category that is wrong the moment the vendor replies is wrong most of the time.

The department is not a category. "Finance", "Warehouse" and "Sales" are who asked, and who asked is already on the ticket, in the requester field, in their e-mail address and usually in the first line. Categories named after departments produce a report that says finance raises more tickets than the warehouse, which the headcount already predicted. Those categories make every search return everything. If the tool has departments as a routing concept, use that; if it does not, put the requester's team in a field of its own. The category stays about the thing.

The work type is not a category either, though this one is more arguable. Whether a ticket is an incident (something broke), a request (somebody wants something), a problem (a cause behind several incidents) or a change is a classification worth having. Desks that make the distinction get a cleaner report. But it crosses every category: there are printing incidents and printing requests. The work type wants its own field, and the case for the four types is made in The Four Work Types in Plain Words. Putting "Request" in the category list means a request for a printer is filed under Request or under Printing. Two triagers will choose differently. Both will be right, which is the problem.

Where the Category Lives in the Tool

Most ticketing tools have a category field of some kind, and the first job is to find out what yours does with it. Three questions settle it. Can the field route a ticket, or does it only store a value? Does the report section cut by it, and over what period? Does the search filter by it, or only match its text? The answers vary more than the brochures admit, and the taxonomy you build must fit the answers rather than the brochure. A tool that cannot route by category still benefits from a good list, for the other two users. A tool that cannot report by it benefits less, and the list should be shorter.

Where the tool has no category field at all, a custom field on the department's form can carry the category. That is the arrangement in tools that route by department and give each department its own form. The department is the coarse sort, and the custom field is the fine one. Counting by that field is a spreadsheet job if the reports cannot cut by it. It is not elegant. It is honest, and it works, provided the list on the field is short enough to fill in correctly at four in the afternoon.

Whatever the tool, make the category a required field at close, and consider leaving it optional at open. A required field at open gets the first entry on the list, because the triager has not read the ticket yet and the form will not submit without a value. A required field at close gets a thoughtful entry, because the person closing the ticket knows exactly what it was. This is the hinge of the whole series, and it has an article of its own. The one-line version is that the open category is a guess and the close category is a fact.

Two Moments, One Field or Two

A ticket is categorized twice whether the tool knows it or not. At open, the triager reads "my e-mail is broken" and picks E-mail, which is the symptom. At close, the technician knows it was an expired certificate on the mail relay, which is the cause. The cause is what the report reader and the searcher wanted all along. A desk that records only the open category produces a report on what users complain about. A desk that records the close category produces a report on what is actually wrong, which is the one that leads to fixes.

If the tool offers one category field, use it for the close value and treat the open value as provisional. If it offers two, or a second custom field can be added, record both. The gap between them is interesting in its own right. It is the list of things users describe one way that turn out to be another. That list is the reading list for the knowledge base. The mechanics, the etiquette of changing someone else's category, and a table of common pairs are in the article on categorizing at close. The purpose checklist below asks about both moments, because a category that makes sense at open and nonsense at close is half a category.

I learned the difference the slow way, on a desk where the category was set once, at open, by whoever answered the phone. The report said our biggest problem was "Slow computer". It was, in the sense that users said those words. The causes, when I finally read a hundred close notes by hand, were a full disk, a mapped drive to a server that no longer existed, and an antivirus scan scheduled for nine in the morning. Three fixes, three afternoons, and "Slow computer" fell off the top ten and never came back. The open category had been telling me what people said. I had wanted to know what was wrong.

How Few Categories a Small Desk Can Use

A small desk needs fewer categories than it thinks. And the number it thinks is usually arrived at by listing everything that could go wrong. The right number is arrived at by listing what the desk actually sees, in volume, and stopping when the next category would hold fewer than a handful of tickets a month. For most general IT desks of one to ten people that is somewhere between twelve and twenty-five top-level entries. Those have a second level under the busy ones and no third level anywhere. How to build that list from a month of real tickets, and what to name the entries, is the subject of Designing a Category Tree That Stays Useful.

The instinct to add is stronger than the instinct to remove, and nobody has ever been asked in a meeting why a category is missing. The list grows one reasonable entry at a time, each with a sponsor, until the pick list takes eleven seconds to scroll. Then the triager picks the first thing that fits. A category list is one of the few things on a desk that gets worse when more people care about it. Caring is for the pruning review, four times a year, with the volume numbers open and the sponsors out of the room.

A desk of one can run on eight categories and lose nothing. A desk of ten supporting four hundred people might justify twenty-five, with two levels. That is because the routing is real and the report has enough tickets in it to show a trend. Nobody between those sizes needs more than that, and most need less. The number is not a measure of thoroughness. It is a measure of how many distinct decisions the desk makes with the field, and a small desk makes few.

A Short War Story: The Filing Cabinet at Bellweather Logistics

Bellweather Logistics ran a desk of three for a company of nine depots. Its category list had 140 entries, one per depot, with sub-entries for each depot's building, office and yard. It had been built by a previous manager who had wanted to know "where the problems were". Every ticket was faithfully filed under its depot. And the monthly report showed that the biggest depots raised the most tickets, which the biggest depots had suspected. Ingrid, who took over the desk, spent a morning trying to answer a simple question from the warehouse director: why did the handheld scanners fail every Monday? The scanner tickets were spread across twenty-three depot categories, described variously as "scanner", "gun", "handheld" and "the thing". And the only way to count them was to read nine months of tickets by hand. She did, and found just over three hundred, at perhaps twenty minutes of warehouse time each. The cause was a weekend battery-charging routine that had been wrong for a year. The lesson she wrote at the top of the new list was short. A category that answers a question nobody is asking is not free, because it is standing where the useful one would be.

The Category Purpose Checklist

Use the checklist once per category, when the list is first built and again whenever someone proposes adding an entry. It takes about three minutes per category and it is designed to be failed. A category that cannot tick at least one box in the first section does not go on the list. Keep the completed sheets with the taxonomy document, because in a year somebody will ask why "Laptop battery" exists. The sheet is the answer.

CATEGORY PURPOSE CHECKLIST — ONE PER CATEGORY
Category name: ______________________   Parent (if any): ______________
Proposed by: ______________   Date added: ______________

THE DECISION IT SUPPORTS (tick at least one, or do not add it)
  [ ] Routing:   when picked, the ticket goes to ______________ (person or group)
  [ ] Reporting: the monthly count changes this decision: ________________
  [ ] Knowledge: a search for it finds the last fix; article exists / planned: ____

THE THREE USERS
  Triager:  can it be chosen from the ticket description alone?      [ ] yes  [ ] no
  Reader:   is it about the thing, not the requester's team?          [ ] yes  [ ] no
  Searcher: would two technicians file the same ticket here?          [ ] yes  [ ] no

NOT ANOTHER FIELD IN DISGUISE
  [ ] It is not a priority (urgent, critical, low)
  [ ] It is not a status (waiting, pending, on hold)
  [ ] It is not a department or a person's name
  [ ] It is not a work type (incident, request, change)
  [ ] It is not a vendor or product name standing in for what broke

VOLUME AND OVERLAP
  Tickets expected per month: ____     Fewer than five?  [ ] merge into: ______
  Overlaps an existing category?  [ ] no  [ ] yes: ______ (resolve before adding)
  Makes sense at open (symptom)?  [ ]   At close (cause)?  [ ]   Both?  [ ]

VERDICT
  [ ] Add     [ ] Add on 90-day probation, review volume     [ ] Do not add
  Reviewer: ______________   Review date: ______________

The sheet works for a list that already exists, too. Run it against every entry on the current list in one afternoon, and expect a third of them to fail the first section. Those are the entries that have been costing four seconds a ticket for years and returning nothing. Removing them, and merging their tickets into the categories that remain, is the subject of the last article in this series, Retiring, Merging and Renaming Categories Without Losing History. The process is less frightening than it sounds.

Omar's Tuesday ticket, the black screen from home, was an expired remote-access certificate. On a list built with this checklist it would have been opened as "Remote access" and closed as "Remote access: certificate". In that case, the eleventh ticket like it that month would have been the one that got the certificate renewal put on a calendar. Instead it was Other, like the three before it. Other does not have a calendar.

Frequently Asked Questions