Avoiding the 400-Category Monster and Pruning the One You Have

Mei has a ticket open at Pinecrest Dental, a chain of nine practices. She needs to set its category before she can save it. She clicks the pick list. It opens, and keeps opening. She scrolls past Hardware, Hardware - Printers, Hardware - Printer (Reception), Hardware - Printer (Surgery 2), Printers, Printing, Printing Issues, and a long run of entries named after practices. Then she scrolls past a block of software names she does not recognise. Two of those are the same product spelled differently. Then she scrolls past something called "Legacy - do not use". The list has four hundred and twelve entries. The ticket is about a printer. She picks the first printer entry she passed, which is wrong, and saves, eleven seconds after she started.

Nobody built that list. Nobody would. It was planted as twenty reasonable entries by a careful person. It grew, one defensible addition at a time, for six years. Nobody owned it and nobody ever took anything off. By the time Mei scrolls it, nine of the four hundred and twelve entries hold most of the tickets. Other holds forty percent. The monthly category report is a column of ones and twos with a single large bar at the bottom labelled Other. The desk has a taxonomy the way a garden with no gardener has plants.

A category monster is a category list that has grown past the point where anyone can fill it in consistently. It is too long to scan, too deep to navigate, and full of duplicates and dead entries. It is therefore filled in by guesswork. This article is part of our Ticket Categorization & Taxonomy series. And it is about the growth: how lists get like this, why a huge list is worse than a small wrong one. It also covers the single rule that stops the growth. The design of a good tree in the first place is in Designing a Category Tree That Stays Useful. This article is for the desk that already has the monster, or is about to.

It covers the four ways a tree grows and why size itself is the problem. It explains the rule that a category must earn its place with ticket volume. It covers who is allowed to add an entry and how, and the quarterly pruning review and what it decides. It includes a worked pruning from four hundred entries to under twenty, and explains how to prune without breaking the reports. The quarterly pruning sheet at the end is built to be copied.

How a Tree Grows

Trees grow by addition without subtraction, and the additions are almost always reasonable on the day. Four patterns account for nearly all of the growth. Once you can recognise them you will see all four on any list more than two years old. Each one looks different on the pick list. And each one is stopped by a different rule, so it is worth knowing them by name.

The first is the one-off. A ticket arrives that fits nowhere. Rather than put it in Other and move on, the triager, or a manager reading over their shoulder, adds an entry for it. "Projector remote". "Label printer, warehouse". "Door entry fob". Each is accurate. Each holds one ticket. And each sits on the list forever, because nobody has a reason to go back and check whether a second ticket ever arrived. A one-off is a category created in response to a single event, and a list of one-offs is a diary, not a taxonomy.

The second is the vendor name. Somebody decides the list should say which supplier or product is involved. From then on every brand of laptop, every printer model and every software vendor gets an entry. The entries are technically precise and useless to the three people who use a category. The triager does not know the model yet. The report reader wants to know about laptops rather than brands. And the searcher is looking for a fix that applies to all of them. When procurement switches supplier, the old entries stay and the new ones join them. The list now records the company's purchasing history, in the wrong field.

The third is every application gets one. The company runs a hundred and sixty pieces of software, most of them used by three people. And a well-meaning review decides each should be a category so that "we can see which systems cause the most trouble". A hundred and forty of the entries never receive a ticket. The other twenty are the ones that would have deserved a second-level entry under "Business applications" anyway. The intention was a report. The result is a pick list that the triager cannot scan. It is also a report with a hundred and forty rows of zero.

The fourth is the reorganisation. The company restructures. The desk adds a branch for the new division, and the old branch stays because it still has tickets in it. Three restructures later the list contains the current structure and three previous ones, superimposed, with entries whose names refer to departments that no longer exist. The tickets in them are real. The categories are fossils. (The fossils are usually the best-documented part of the list, which tells you something about where the care went.)

Two smaller patterns are in the table because they are common enough to deserve a row. The sibling is two entries for one thing, created by two people on two days without checking. The personal entry is one technician's private vocabulary, added because they could. Neither is malicious. Both are what happens when the settings page is open to everyone and the list has no owner.

Why a Huge Tree Is Worse Than a Small Wrong One

A small wrong tree is better than a huge accurate one, and the reason is consistency. A list of fifteen entries that misses a few things is filled in the same way by everyone, every time, because everyone knows it. The report it produces is reliable, and the things it misses show up in Other, where the monthly reading finds them. A list of four hundred entries that covers everything is filled in differently by every person on every day. Nobody knows it and nobody can read it in the time available. The report it produces is noise, and there is no Other reading that can fix noise.

Size breaks the triager first. A pick list that takes eleven seconds to scroll is a pick list in which the triager stops reading after the first screen. The entries at the top of the alphabet get used; the entries lower down do not, regardless of what they say. "Access" is fine. "Wireless" is in trouble. And when nothing in the first screen fits, the triager does not scroll. They pick the entry they used last time, or Other, or the first thing that is not wrong. All three are the same decision made by a tired person with nine tickets waiting.

Size breaks the report second, by dilution. Four hundred categories over three hundred tickets a month means most entries hold zero, one or two. That is not a count; it is a rumour. The biggest real category, say printing, is split across nineteen printer-related entries and shows as nineteen small bars instead of one large one. The report reader sees a flat landscape and one mountain labelled Other. They conclude that the desk's biggest problem is Other. That is true in the sense that it is the only conclusion the report allows.

Size breaks the searcher third, because a huge tree is inconsistently filled, and an inconsistently filled field cannot be searched. The eleven tickets about the same printer fault are under six entries, and a search on any one entry finds two of them. The technician who needs the fix concludes the desk has not seen this before, and solves it again. That is the expensive failure, and it is invisible, because nobody records the fix they could have found.

The deepest cost is that the monster cannot be learned. A new technician can hold fifteen entries in their head by the end of the first week. Nobody holds four hundred, ever. So the monster guarantees that every person on the desk, forever, fills the field by reading rather than knowing. Reading at 08:40 with the queue open is where the first-plausible-entry habit comes from. A small wrong tree can be fixed with one mapping table. A huge tree cannot be fixed by anything except becoming small.

The Rule: A Category Must Earn Its Place With Volume

One rule stops the growth, and it is a number. A category stays on the list only if enough tickets visit it. The number is set in advance and applied every quarter without discussion. For a desk of three to ten people handling a few hundred tickets a month, a workable threshold is ten tickets a quarter for a second-level entry. For a top-level one, it is about two percent of all tickets, or twenty-five a quarter, whichever is smaller. An entry below the threshold merges into its neighbour at the next review. The threshold goes in the taxonomy document, next to the owner's name, so that the review is arithmetic rather than argument.

Volume is the right test because it is what the three users need. A category with ten tickets a quarter can show a trend, can justify a knowledge article, and can route to a person who will recognise it. A category with two cannot do any of those. It is a label on two tickets that would have been found just as easily by searching the description. The rule sounds harsh to the person who proposed the entry. It is kind to the person who has to scroll past it four hundred times a year.

Three kinds of entry are exempt, and the exemptions are written down. Security incidents may be rare and must be findable on the day the auditor asks. Exempt routing entries are those where the tool really does send the ticket to a different person on the strength of the category. That person must receive the two a quarter that arrive. And seasonal entries, like the year-end finance close, are empty for nine months and busy for one. These are judged on their busy quarter. Everything else earns its place or leaves. "It might be useful one day" is not an exemption. It is the sentence every one-off was added with.

Counting is a spreadsheet job and takes ten minutes. Export a quarter of tickets with their category. Count by category, sort ascending, and read from the top. Whatever the tool, the review wants ninety days. Most ticketing tools can show or export tickets over a chosen window. If yours cannot count by category, export the quarter to a spreadsheet and count there. The ascending sort puts the zeroes first, and the zeroes are the easy decisions. The hard ones are the entries with seven tickets. And the threshold decides those too, which is why it was written down before the review and not during it.

Who Can Add a Category, and How

One person owns the list, and additions go through them. The owner is usually whoever reads the monthly category report, because they are the one the monster hurts. Their job is mostly to say "not yet". A request to add an entry comes with the purpose checklist from Why Ticket Categories Exist filled in. It states what decision the entry supports, who the three users are, and how many tickets a month it is expected to hold. If the answer to the last question is "a few", the answer to the request is Other, with a note, and a check in three months.

New entries start on probation. An entry added this quarter is reviewed at the next pruning like every other entry. If it did not reach the threshold it merges back. This is the rule that stops one-offs. A one-off never reaches the threshold and leaves on schedule without anyone having to argue with the person who wanted it. Probation also calms the request conversation: "yes, for ninety days, and then the numbers decide" is easier to say than "no", and it is true.

Nobody adds an entry from the settings page in the moment, however easy the tool makes it. A triager who finds a ticket that fits nowhere puts it in Other. They write one line in an internal note: "no category fits; this is about the meeting-room booking screen". The monthly reading of Other collects those lines. When the same line appears six times the entry is created, with evidence. The settings page is the way the monster gets fed. Taking the keys away from everyone but the owner is most of the cure, and it costs nothing.

The Quarterly Pruning Review

The pruning review is forty-five minutes a quarter, with the owner and one technician who does triage. They have the quarter's tickets in a spreadsheet counted by category. The review asks three questions of every entry, in order, and each question has a yes-or-no answer. Did it reach the threshold? Does it overlap with another entry? Can anyone name the decision it supports? An entry that fails the first question merges. An entry that fails the second merges with its twin. An entry that fails the third is retired, whatever its volume, because a busy category that changes nothing is busy filing.

The review produces four outcomes per entry, and the sheet at the end has a column for each. Keep needs no action. Merge up means a second-level entry folds into its parent because it was too small to stand alone. Merge sideways means two siblings with the same meaning become one, under the better name. And retire means an entry leaves the list and its tickets are mapped to wherever they belong. The fourth outcome is rarer than it sounds, because most entries that fail are not wrong, just too small. Merging keeps their tickets countable.

The review also reads Other, which is the only entry that gets more than three questions. What is in it this quarter? Does any kind of ticket appear more than ten times? If so, that is the one addition the review makes, with the purpose sheet, on probation. A review that adds one entry and removes three is a review that is working. A review that adds four and removes none is a committee, and the list will be longer next quarter.

Keep the sheets. The quarterly sheet is the only record of why an entry disappeared. And a year from now somebody will ask why "Label printer, warehouse" is not on the list any more. The answer is on the sheet: it had two tickets in a year and was merged into Printing. The sheets also feed the mapping table that keeps old reports readable, which is the subject of Retiring, Merging and Renaming Categories Without Losing History.

A Worked Pruning: From 412 to 19

Here is the shape of a real pruning, with the numbers rounded. A desk of five with 412 entries exported a quarter of tickets, about 900, and counted. Two hundred and ninety entries had zero tickets. Sixty-one had one or two. Thirty-four had between three and nine. Eighteen had ten or more, and Other had 370. The review took the whole of a Friday afternoon rather than forty-five minutes, because the first one always does. It was mostly deletion.

The 290 zeroes were retired in one block, with their names kept in the mapping table in case an old ticket ever needed looking up. The sixty-one ones-and-twos were read individually, which took an hour. Nearly all merged up into a parent that already existed or sideways into a sibling. Nineteen printer-related entries became "Printing" with three children. Eleven software names became "Business applications" with four. The thirty-four middling entries were the hard hour. The threshold decided them: those below ten merged, and those above stayed. Two that were below ten but were security entries stayed by exemption. The eighteen busy entries were kept, renamed where the names broke the rules, and given second levels where their volume justified it.

The result was nineteen top-level entries, a second level under six, fifty-three entries in all. Other fell from forty percent to seven within the following quarter without anyone being told to try harder. The triagers had been trying hard all along. They had been trying to scroll.

Pruning Without Breaking the Reports

Pruning changes the categories, and reports compare quarters, so a pruning done carelessly breaks the comparison. Three habits prevent it. Prune at a quarter boundary, so the old tree describes one whole quarter and the new tree describes the next. Never rename an entry mid-month. Keep a mapping table that says, for every retired or merged entry, where its tickets now count. That way, last year's "Printer (Reception)" can be added to this year's "Printing" when someone asks for a trend. And write one paragraph in the taxonomy document, dated, saying what changed and why. The report reader in a year will see a line that drops to zero. That reader needs to know it was merged, not fixed.

The tickets themselves are not touched. A category can leave the list. The tickets filed under it are going nowhere, and in many tools they cannot, because tickets are never deleted by any route. Even where deletion is possible, do not. Whether to go back and re-tag old tickets with the new entry is a separate decision with a cost on each side. It is argued out in the retiring article. For most desks the answer is no. In that case, map the old entry in the table and leave the tickets as they were. Let the mapping do the work at report time.

Tell the team on the day, briefly, with the new list on one page and the mapping table beside it. The announcement is two sentences: the list is shorter, here is where the things you used to pick now live. Technicians adapt to a shorter list in a week, because a shorter list is easier. The only complaint I have ever heard was from the person whose personal entry had merged. They were filing under it alone. It had seemed, to them, very well used.

Reading the Pick List as a Requester Sees It

If requesters choose a category on the form, the monster hurts them worse than it hurts the desk. They see it once a quarter and have no idea what any of it means. A requester faced with four hundred entries picks Other, or the first entry, or closes the form and e-mails somebody. The fix is not a better list for requesters. It is a shorter one: six entries at most, in plain words. Or put no category on the form at all, with the triager setting it after reading. The desk's tree is for the desk.

Where the tool routes by department, let the requester choose that and nothing finer. In tools that work this way the requester picks a department on the web form. That choice is what routes the ticket before anyone has read it. The finer label is a field the desk fills in. A requester choosing between IT, Facilities and HR gets it right nearly every time. A requester choosing between "Network: wired" and "Devices: dock" is being asked to diagnose, and will guess. The desk will correct the guess. That is the same work as setting it in the first place with an extra step in front.

The same reading applies to the desk's own list, one more time, with fresh eyes. Open the pick list as a new technician would, on their first morning, with a ticket open. Can they find the right entry in three seconds without scrolling? If the answer is no, the list is too long, whatever the volume numbers say. In that case, the next pruning should start from the pick list rather than the spreadsheet. The spreadsheet measures the entries. The pick list measures the people, and the people are the ones who fill it in.

A Short War Story: The Settings Page at Stonebridge Insurance

Stonebridge Insurance ran a desk of six with a category list that had reached three hundred and eighty entries. The reason was that the settings page was open to every technician and each had added entries for the things they personally handled, in their own words, for five years. Ravi, who took over the desk, found that four technicians had each created an entry for the policy administration system under a different name. The report showed the system as four small problems instead of one large one. A renewal conversation with the system's vendor had gone ahead the previous spring. The desk's evidence of its failures had been understated by roughly three quarters. Ravi ran the first pruning on a Friday. He took the settings page away from everyone but himself and set a threshold of ten tickets a quarter. He put every new request through a one-page purpose sheet with a ninety-day probation. The list went to twenty-two top-level entries. The four names for the policy system became one. At the next renewal, that entry showed a hundred and forty tickets in a quarter and changed the conversation. The lesson he wrote at the top of the taxonomy document was about access rather than design. A category list grows exactly as fast as the number of people who can add to it. The cure is one owner and a number.

The Quarterly Pruning Sheet

The sheet is the forty-five minutes on one page, filled in from the quarterly export with the threshold already written at the top. Do the counts before the meeting, so the meeting is decisions rather than arithmetic. One row per entry below the threshold, plus a short section for Other and a short section for the one addition the review may make. Keep the completed sheets with the taxonomy document. Together they are the only history the tree has.

QUARTERLY CATEGORY PRUNING SHEET — ONE PAGE
Desk: ______________   Quarter: ______________   Owner: ______________
Threshold: second-level entries ____ tickets/quarter; top-level ____ or ____%
Tickets this quarter: ______   Entries on the list before: ______

ENTRIES BELOW THRESHOLD (one row each; count from the export, ascending)
  Entry                      Tickets   Overlaps with      Decision
  ________________________   ______    ______________     [ ] keep (exempt: ____)
                                                          [ ] merge up into ______
                                                          [ ] merge sideways into ______
                                                          [ ] retire; map to ______
  ________________________   ______    ______________     [ ] keep  [ ] up  [ ] side  [ ] retire
  ________________________   ______    ______________     [ ] keep  [ ] up  [ ] side  [ ] retire
  ________________________   ______    ______________     [ ] keep  [ ] up  [ ] side  [ ] retire

ENTRIES ABOVE THRESHOLD THAT FAIL THE DECISION TEST
  Entry: ________________   Decision it was meant to support: none named
  [ ] retire; map to ______      [ ] keep for one more quarter; owner to find a use

THE OTHER BUCKET
  Tickets in Other: ______   Share of all tickets: ____%
  Recurring kinds found (ten or more): __________________  __________________
  Addition this quarter (at most one, on 90-day probation):
    Name: ________________   Parent: ______________   Purpose sheet attached: [ ]

ENTRIES ON PROBATION FROM LAST QUARTER
  ________________   Tickets: ____   [ ] reached threshold, keep   [ ] merge back into ______

MAPPING TABLE UPDATED        [ ] yes   Rows added: ____
TAXONOMY DOCUMENT NOTE ADDED [ ] yes   Dated: ______________
TEAM TOLD                    [ ] yes   Date: ______________

Entries on the list after: ______   Change: ______
Next review: ______________

The first sheet is long and the fourth is short, which is the point. A tree that has been pruned three times has few entries below the threshold. Other is under five percent. And the review is twenty minutes of confirming that nothing has grown. That is the tree Mei should have been scrolling at Pinecrest Dental. On that tree the printer entry would have been the fourth one down, reachable in a second, and right.

Frequently Asked Questions