How to categorise tickets so the numbers become usable

Short answer: A ticket category should answer what the customer asked about, not which department owns the question. Build one dimension at a time, keep the top level under thirty categories and require every category to lead to an action. Fields give structure and reporting, tags give flexibility and grow wild if nobody owns them. The category is set at closing, spot-checked, then used for knowledge gaps, staffing and automation.

Every customer service tool has categories, and in most teams they mean nothing. The list was inherited from whoever set the system up, someone added a tag for a campaign in 2023, and 40 percent of tickets end up in "Other" in the report. Then management asks what customers are getting in touch about, and the answer is a guess. This article is about building a categorisation you can steer by, and keeping it clean.

Why do ticket statistics say so little?

Because the categories usually describe your organisation rather than the customer's question. "Logistics", "Finance" and "Technical" say who received the ticket, not what the customer wanted to know, and two tickets in the same category can require completely different actions. The category "Logistics" holds both "where is my order" and "you sent the wrong item", which have different causes, different solutions and different ways of being designed away.

Three patterns recur in teams that find their statistics unusable:

The categories follow the departments. Good for routing, useless for analysis.
The tags have grown freely. In its guide on working with ticket tags, Zendesk reminds users to use specific tags, avoid common words and keep formatting consistent, precisely because tags otherwise become impossible to report on. Without an owner you get return, returns, Return and return-2024.
Nobody decided what the category is for. A category that does not lead to a decision is just one more click for the agent.

What should a category answer?

What the customer asked about, phrased so that someone can do something about it. The test is simple: if you read the category name aloud and cannot say which action would reduce the number of tickets in it, the category is wrong.

"Delivery" fails the test. "Where is my order" passes, because the action is better notifications and an order lookup in self-service. "Delivered but missing" passes too, with a completely different action: an investigation with the carrier.

So build one dimension at a time, and keep them as separate fields:

Dimension	Answers	Example	Used for
Ticket type	What the customer asked about	Where is my order, size exchange, incorrect invoice	Knowledge gaps, self-service, automation
Cause	Why the question arose	Unclear product page, delayed transport, system error	Fixes outside customer service
Outcome	What you did	Resolved with information, replacement, refund, rejection	Cost and policy
Channel and time	Where and when	Chat, email, hour of day	Staffing

The most common confusion is between ticket type and cause. "Late delivery" is a ticket type when the customer asks about it, and a cause when it explains why the customer got in touch about something else.

How many categories should you have?

Fewer than you think at the top level, and only as many at the second level as you actually use. My benchmark from several rollouts: fifteen to thirty ticket types at the top level is enough for a team with a few hundred tickets a week. More than that and agents choose differently, which makes the data worse than a shorter list would have.

Think in domains rather than in one long list. The Knowledge-Centered Service method describes a knowledge domain as a collection of articles around a common topic, function, process or product family; the Consortium for Service Innovation uses the domain as the unit you analyse and improve. The same division works for tickets: the domain "delivery" contains five ticket types, and it is in the domain that you see the pattern.

Three rules that keep the list short:

Every category must have a conceivable action. If you cannot formulate one, merge the category with another.
No category under one percent. If it is not used often enough to show in a report, it belongs at the second level or nowhere.
"Other" should be small and read. More than ten percent in "Other" means the list is missing something. Read twenty such tickets and name what is absent.

Fields or tags?

Fields for what you will report on, tags for what is temporary. Which fields a system should have from the start is in the buyer's guide to ticketing systems. Zendesk describes the difference in its comparison of tags and ticket fields: fields give a defined set of values and structure, while tags are looser and can be set from several places. The principle applies whatever the tool.

In practice: ticket type, cause and outcome should be mandatory fields with fixed values, since they must be comparable over time. Tags suit campaigns, an ongoing incident, a recalled batch or an experiment you want to follow for six weeks. Put an end date on every tag when you create it, and have someone clear the list every quarter. Without that clearing, the tags become an archaeological layer nobody dares remove.

Who sets the category, and when?

The agent, at closing, in at most two clicks. Categorisation that takes time gets sloppy, and sloppy categorisation is worse than none, because it looks like data.

Four things make it actually happen:

Set it at closing, not on arrival. Only then do you know what the ticket was about.
Let the system suggest. An AI suggestion the agent confirms or changes takes a couple of seconds, and the changes show where the list is unclear.
Show the same list in every channel. Chat, email and phone should use the same ticket types, otherwise they cannot be added together.
Spot-check. Twenty tickets a month, read by the knowledge manager. Where two people chose different categories for the same kind of ticket, the name is unclear. The role that does this is described in the article on the knowledge manager.

An agreement test is the quickest quality measure: have three agents categorise the same ten tickets separately. If they differ on more than two, it is the list that is wrong, not the people.

What do you use the categories for?

For four decisions, and categories not used in any of them can be removed.

Which answers to write. The largest ticket types without a reviewed article are next week's work, following the method in the article on knowledge gaps.
What can be automated. Gartner predicts that agentic AI will autonomously resolve 80 percent of common customer service issues without human intervention by 2029. "Common" is the key word: without a categorisation you do not know which tickets are common enough to be worth automating.
How self-service performs. The share of tickets per type that reaches a person is the metric that shows whether the help centre is carrying its part. Gartner reports that only 14 percent of customer service issues are fully resolved in self-service, and the difference between ticket types is large.
What to fix outside customer service. The cause dimension is the one that gives the most to product, logistics and the website, and the only one that explains why the volume looks the way it does. How these numbers fit with the other metrics is covered in the article on customer service metrics.

What to do

Read a hundred tickets from an ordinary week and write down what the customer actually asked about, in the customer's words.
Group them into fifteen to thirty ticket types and formulate a conceivable action per type. If you cannot, merge them.
Create three mandatory fields: ticket type, cause and outcome. Keep tags temporary and give them end dates.
Run an agreement test with three agents and ten tickets before rolling the list out.
Set the category at closing with a system suggestion, and review twenty tickets a month.
Read "Other" every month and name what is missing.
Clear the list every quarter. Remove categories that have not led to a decision in six months.

Common questions

Can AI categorise the tickets for us?

Yes, and it is usually the right way to do it, but only against a list someone has decided. A model can suggest a ticket type from your own categories and learn from the agents' corrections, which is fast and more consistent than doing it by hand. Do not let it invent categories freely, though: then you get a new set of names every quarter and cannot compare over time. Follow how often agents change the suggestion; a high rate of changes means the category is unclear.

How often should we change the category list?

Rarely at the top level and more often below it. The ticket types should be comparable across years, so change them only when the business actually changes, for example with a new range or a new service. Subcategories and tags can change quarterly. Document every change with a date, otherwise a curve that bends becomes impossible to interpret afterwards.

Should the customer choose the category in the form?

Only if the choice helps the customer, and then in the customer's words and with few options. Customers often choose wrong, since they do not know your internal boundaries, so use their choice as a hint for routing but not as your statistics. The real category is set at closing by whoever read the ticket.

What do we do with tickets that belong in several categories?

Choose what the customer got in touch about, and put the rest in a note or a tag. A customer who asks about delivery and also wants to change their address is a delivery ticket with an extra action. Do not allow several values in the ticket type field; that makes the shares impossible to add up. If the same combination recurs often, it is a sign that it deserves a ticket type of its own.