
TL;DR: In one real service desk's data, more than a quarter of tickets had no useful subcategory: about 15 percent were dumped in "Other" and about 14 percent were blank. A small share even had junk in the category field, like dates and pasted email footers, because most tickets arrive as free-text email and phone notes that a human has to categorize by hand. That bad data quietly breaks routing, reporting, automation, and every workload metric downstream. So we built a Ticket Categorizer Coworker. It loads the target workspace's own category and subcategory list, reads the ticket, and applies the right values when it is confident. When it is not, it does not force a guess; it drops ranked options into a private note for a human. It never writes a category that does not exist in that workspace, and it starts in a shadow mode so you can measure it before it touches anything.
Categorization looks like a solved problem until you look at real data. Across roughly eleven thousand tickets from one real IT service desk, the picture was not pretty: more than one in four tickets carried no useful subcategory, about 15 percent sat in a catch-all "Other" and about 14 percent were simply blank. Around 41 categories were in active use, and they had drifted into near-duplicates, "Data Warehouse" alongside "Datawarehouse," "Network" alongside "Networking," "Software" alongside "End User Software." A little over 1 percent of tickets had outright garbage in the category field: dates, ticket ids, even pasted email footers, because the field is free for an agent to type into. More than 80 percent of tickets came in through email and phone, unstructured text a person has to read and classify, one at a time, under queue pressure.
None of this is a knock on the team. It is what manual categorization always becomes. And it is not cosmetic. Category and subcategory are what your routing rules, SLAs, automations, dashboards, and capacity planning all read. When a quarter of the tickets say "Other" or nothing, every number built on top of them is soft.
This is a common pain, not a local one. Community threads are full of it: service desk agents asking how to stop tickets landing with the wrong team, and admins asking whether anyone has a sane taxonomy for categories and subcategories in the first place. In ServiceNow forums people report that even the built-in triage does not reliably set the category. The category field is everyone's problem and nobody's job.
The Ticket Categorizer is an AI Coworker with a deliberately narrow job. When a ticket needs a category, it does four things. It loads the taxonomy for that ticket's workspace: every Category, the Sub Categories under each, and the group they belong to. This is what lets one Coworker work across every workspace, IT, security, finance, facilities, people, with no hardcoded list.
It reads the ticket: subject, description, requester, channel, and any conversation. Most of the signal is in the description, because most of the intake is free text.
It decides with a confidence gate. High confidence, one clearly best match that exists in the workspace, and it applies the Category and Sub Category. Medium, the category is clear but the subcategory is ambiguous, and it applies the Category and recommends the subcategory in a note. Low, several plausible categories or a weak signal, and it applies nothing and writes a private note with the top two or three ranked options, each with a one-line reason.
It explains itself. Every action leaves a short private note: the intent it detected, what it set or recommended, its confidence, and the previous values, so a human can review and revert.
Two rules keep it safe. It only ever writes a value that exists in the current workspace's taxonomy. And it only ever touches the Category, the Sub Category, and that note, never status, priority, assignee, or the requester.
Anyone can write a classifier that always returns an answer. The reason those are not trusted on a real queue is that a confident wrong category is worse than a blank one, it sends the ticket to the wrong team and corrupts the reporting at the same time. So the Categorizer is built to know its limits.
In a shadow run over a spread of real tickets, a phishing report, an email impersonating a CFO asking staff to buy gift cards, came back high confidence and mapped cleanly to Security and the Phishing subcategory, an exact match in that workspace's taxonomy. A one-line ticket that just said the system was broken came back low confidence, and instead of forcing a category, it recommended three plausible options with reasons and suggested asking the user for more detail. A dead-laptop ticket exposed a real gap: that workspace had no hardware or device category at all. The correct behavior is not to jam it into the nearest wrong bucket. The Coworker left it blank and recommended that an admin add a hardware category.
That is the trust story. It is right when it is sure, honest when it is not, and it never makes up a category to look decisive.
Because it writes to real tickets, you do not flip it on and hope. You run it per workspace in shadow mode, where it is granted note-only access and physically cannot change a field. It writes what it would have applied, and you compare that against the tickets your team already categorized. Measure the category accuracy, confirm it never invents a value, and check that spam and no-fit tickets are handled the way you want. When a workspace clears your bar, you switch that workspace to live. Every workspace earns its own promotion; a workspace going live never changes how the Coworker behaves anywhere else.
Does it work across different workspaces with different categories? Yes, that is the core design. At the start of every run it loads the current workspace's own category and subcategory list and maps only to those values. Drop it in IT, security, finance, or facilities and it uses that workspace's taxonomy automatically.
What happens when a ticket does not fit any category? It does not force one. It writes a private note recommending the closest existing options, and if the right category genuinely does not exist in that workspace, it says so and suggests adding one.
Will it overwrite a category a human already set? The design is to categorize uncategorized tickets and to leave a clear, reversible note on anything it does set. You decide the policy for tickets that already have a category.
How is this different from a rules engine or keyword routing? Rules break on the free text that makes up most intake, and they multiply into unmaintainable spaghetti. The Coworker reads the ticket the way a person would, maps to your live taxonomy, and tells you its confidence and reasoning on each one.
Is it safe to run on live tickets? Start in shadow mode, where it cannot change anything, and measure. Promote a workspace to live only when its accuracy clears your bar. Even live, it touches only the category, the subcategory, and a note, and every action is logged and reversible.
The category field is where service desk data quality is won or lost, and manual categorization loses it slowly, one "Other" at a time. An AI Coworker that reads the ticket, uses your own taxonomy, applies the right values when it is sure, and recommends when it is not, fixes the problem at the source without pretending to be certain when it is not. Confident where it should be, honest where it must be. That is the only kind of automation a busy queue will actually trust.
Sources and notes: the categorization statistics are de-identified aggregates from one real IT service desk's ticket export (roughly eleven thousand tickets); shares are rounded, verify against your own data before quoting. The behavior described is from a shadow-mode run of the Ticket Categorizer Coworker on a demo workspace; category and subcategory names shown are that workspace's own taxonomy. No customer names or personal data are used.