Help Desk Ticket Categories: Examples and How to Design Them

Good help desk ticket categories are few (roughly 5–10 per team), named in the requester's words, and each carries three things: the team that owns it, its type (incident or service request) and its target time. Derive them from what you actually receive — group the last three months of requests — rather than from an org chart or a vendor template. Categories exist to route work, set deadlines and produce useful reports; if a category doesn't change any of those, merge it.

What categories are for

A category does real work in a request desk:

1. Routing — it decides, or confirms, which team's queue a request lands in.
2. Deadlines — each category has a target, so the request gets a due time the moment it's categorized. See the SLA tracking guide.
3. Type — it tells you whether something is broken (incident) or asked for (service request), which drives workflow. See incident vs service request.
4. Reporting — volume and attainment per category show where demand and problems are.
5. Self-service — the knowledge base can be organized by the same categories.

A category that does none of these is decoration.

How many?

Fewer than you think. Signs of too many categories:

• Requesters (or triage) pick "Other" often, or pick different categories for the same thing.
• Some categories get one request a quarter.
• Reports have so many rows that nobody reads them.

Signs of too few: one category ("IT problem") contains everything from outages to monitor requests, so its target and reports mean nothing.

A useful rule: 5–10 categories per team, each receiving at least a few requests a month. Merge anything smaller.

Example category lists

Adapt these; don't copy them. Targets are illustrative starting points, to be replaced by your own measurements.

IT

Category	Type	Example	Starting target
Can't work (locked out, device dead)	Incident	"Laptop won't turn on"	1 h response
Something's broken or slow	Incident	"VPN disconnects every 10 minutes"	4 h response
Access to a system or folder	Service request	"Need access to the finance drive"	1 business day
New equipment or software	Service request	"Second monitor for home"	5 business days
Account and password	Service request	"Reset my MFA"	4 h
How do I…?	Service request	"How do I share my calendar?"	1 business day

HR

Category	Type	Example
Pay and payslips	Service request	"My overtime is missing"
Leave and absence	Service request	"Correct my leave balance"
Contracts and letters	Service request	"Employment letter for a visa"
Benefits	Service request	"Add my partner to health insurance"
Workplace concern (private)	Service request	Sensitive — private queue

Finance

Category	Type	Example
Expenses	Service request	"Reimbursement not received"
Invoices and suppliers	Service request	"Supplier asking about late payment"
Purchases and approvals	Service request	"Approve software subscription"

Facilities

Category	Type	Example
Something's broken	Incident	"Meeting room screen not working"
Desk, keys and access cards	Service request	"New starter needs a badge"
Supplies and cleaning	Service request	"Kitchen out of coffee"

What each category should carry

In the data model, a category is more than a name:

• Team — the owning queue.
• Type — incident or service request.
• Target — response and resolution times (LetRelay stores an sla_hours target per category; the request's deadline is stamped from it).
• Description — one line shown to requesters and to any AI that suggests categories. "Access — permissions to systems, shared drives or SaaS tools."
• Optional: an approver, a checklist template, linked knowledge-base articles, and whether the queue is private.

The description matters twice: it helps humans choose, and it's what an AI classifier reads. Clear descriptions improve automatic classification more than a bigger model does — see AI request classification with structured output.

Naming: the requester's words

Categories are for people who don't know your internal structure. Compare:

Team-centric name	Requester-centric name
IAM	Access to a system or folder
EUC hardware	Laptop, phone or accessories
Service desk – L1	How do I…?
Payroll operations	Pay and payslips

When requesters pick the category, requester-centric names reduce misroutes. When triage picks, they still make reports readable to managers.

One level or two?

Two-level categories (Hardware → Laptop → Won't boot) look tidy and cause trouble: requesters guess at the second level, "Other" becomes the most popular choice, and reports split data too thinly to be useful. For most internal desks:

• One level of categories per team.
• Tags for finer detail when it's genuinely needed (device model, application name), added by agents, not requesters.

Let the requester choose less

The fewer decisions a requester makes, the better the data. A common pattern:

1. The requester picks a team (six or so options in problem language).
2. They describe the request in their own words.
3. The category is suggested — by rules, AI or triage — and confirmed by an agent.

In LetRelay the requester picks the team; the category and priority are suggested by AI and applied automatically only when the model is confident, otherwise shown to triage. See support ticket routing.

Fixing a category list that isn't working

Every quarter:

• Look at "Other". Group its requests; a cluster of five or more is a missing category.
• Look at recategorizations. If triage often changes A to B, the names or descriptions of A and B are confusing.
• Look at tiny categories. Merge anything with almost no volume.
• Look at huge categories. If one category is a third of volume with wildly varying durations, split it by type or target.
• Change the knowledge base too. Categories and articles should use the same words.

Change categories carefully: renaming is fine, but merging or splitting breaks trend lines. Note the date of any structural change on your reports.

FAQ

How many ticket categories should a help desk have?

Roughly 5–10 per team, each with meaningful monthly volume. Merge rarely used categories and split any category whose requests have very different targets.

Should ticket categories have subcategories?

Usually not for internal desks. Use one level of categories and add tags for finer detail when needed; two-level menus push requesters toward "Other".

Who should choose the ticket category?

Ideally not the requester alone. Let them pick a team in plain language and describe the problem; have rules, AI suggestions or triage set the category.

What should each ticket category include?

An owning team, a type (incident or service request), response and resolution targets, a one-line description, and optionally an approver, checklist and linked articles.

Sources

• Atlassian — What is ITSM?
• Atlassian — Incident management
• Wikipedia — Help desk
• GOV.UK Service Manual — Writing for user interfaces