Why this matters
Ticket categories are the first decision every request passes through. They decide who gets the work, what the requester sees in the portal, and which bar shows up in your monthly report. A list knocked together in a launch week tends to survive for years, so it pays to spend a day on it.
A category should answer one question: what kind of work is this. When a list mixes request type, department, urgency and system, the reports stop being readable. You get a bar chart where nobody can tell whether volume rose because of new hires or because of a printer fault.
The cost shows up later. Agents reclassify tickets by hand, the weekly report has a fat Other bar, and the form asks so many questions that people give up and email the desk directly. Each of those points to the same problem: the category list is carrying work that other fields should do.
Before you start
Start with evidence, not memory. Export the last three months of tickets from the help desk tool, plus whatever arrived by email or chat to a shared inbox. Keep the subject, the description and the resolution note. Strip names and anything customer specific before the file leaves the tool.
Decide what the categories have to support. Usually that means routing to the right group, a report a manager reads each month, and a filter an agent uses to find similar past tickets. If a category does not serve any of those, leave it out.
Check what your tool can do. Zendesk lets you build ticket forms with required custom fields and route on them. Jira Service Management uses request types and queues for the same job. Freshservice and ServiceNow work in similar ways with categories and subcategories. Find out whether the field can be required, whether the requester can change it later, and whether it can trigger a routing rule.
Agree on names before you argue about structure. A noun plus a system works well: Laptop hardware, Email and calendar, Account access, Printing. Keep capitalization consistent and keep internal project names out of it.
How to do it
The work starts with the sample. Have two people sort the same three months of tickets separately, then compare. Where they disagree, the category name is usually the problem, not the person.
Keep the top level flat and small. Eight to twelve categories covers most IT teams of one to ten people. Anything with only a handful of tickets a quarter goes into a neighbor category, or becomes a tag if you still need to find it later.
Push detail into fields, not into the tree. The affected device, the application, the site and the urgency each deserve their own field. A category called Laptop Outlook urgent VPN tells you nothing you can count.
Write the requester-facing text last and read it out loud. Names that make sense to IT often fail on the portal: Wireless connectivity tests badly, while Wi-Fi and network works. Test with people outside the team and change whatever they hesitate over.
- Pull a real sample. Export three months of tickets from every channel, including the ones that arrived as email or chat to a personal address. Keep the subject, description and resolution note, and strip names before you share the file.
- Sort the sample by hand. Group tickets by the work an agent actually did. Write each group as the action taken, then turn it into a noun that fits a dropdown.
- Cut the list to eight or twelve. Merge any group with only a few tickets per quarter into its nearest neighbor. Count the sample again before you commit to a final list.
- Add subcategories only where you report. Add a second level for categories where someone asks for a split, such as new starter versus password reset inside account access. Keep each subcategory name readable on its own.
- Define the fields per category. For each category, list the two or three fields an agent needs before starting work. Make those required on the form and leave the rest optional.
- Write the routing rule. Map each category to a group or queue and to a first response target. Test the rule against a real ticket before you switch it on.
- Rewrite the requester wording. Replace internal terms with the words requesters use. Run five test submissions with people outside IT and note where they pause or pick wrong.
- Map the old tickets. Build a table from the old category names to the new ones and run it as a bulk update. Keep the old value as a tag so past reports stay readable.
- Schedule the reviews. Put a 30 day and a 90 day review on the calendar. At each one, merge, rename or retire categories based on the reclassification count and the Other share.
How to check it worked
Check two numbers after the first month: the share of tickets sitting in Other, and the share agents reclassified. Both should be small and heading down. If Other stays high, the form is missing a category or the options are unclear.
Look at reassignment by category. A category where tickets keep moving between groups has a routing rule that does not match the name, or a name that means different things to different people.
Read the volume and first response report by category. The top three or four categories should carry most of the work and have response targets set on purpose. If a small category has the same target as a big one, the targets were never designed, they were inherited.
Ask the agents one question at the end of each week: which ticket was hard to categorize. Ten minutes of answers beats any amount of guessing about the taxonomy.
Mistakes to avoid
Mirroring the org chart is the common failure. Finance IT and Sales IT both mean laptop, account and application problems, so the split adds a decision without adding information about the work.
Do not put urgency in a category name. Urgent laptop repair forces a re-categorization the moment the urgency drops, and it breaks any trend line you try to draw.
Do not keep a silent Other. Make the note field required there and read it every week. If a recurring ticket type keeps landing in it, that is a missing category or a form asking the wrong question.
Categories should retire. Merge them with a mapping table, keep the old name as a tag so past reports still read correctly, and tell the team what changed. If you want the category list, routing and the monthly volume report built alongside your team, the Cloudverg IT service desk setup package does that at a fixed price of $6,500 over two weeks, and it is one option among several.
Frequently asked questions
How many ticket categories should a help desk have?
Eight to twelve at the top level suits most small and mid-sized IT teams. Add a second level only where a report needs the split. Past that, agents spend more time choosing than working.
Should ticket categories include priority?
No. Priority is its own field, set by impact and urgency, and it changes as a ticket develops. A category containing urgent forces a re-categorization when the urgency drops and spoils your volume trends.
What should go in the Other category?
Keep one, but make a short note required and review it weekly. Every ticket parked there is either a missing category or a badly worded form. Move the recurring ones out at the review.