Categories
Category → Sub-category → Item: how tickets are classified.
Administration → Categories
How a ticket is classified: Category → Sub-category → Item. Each level narrows the next on the ticket form, so the list in front of an agent stays short enough to read. The same three levels ManageEngine, Freshservice and Jira Service Management use — if your team is arriving from one of those, this is the field they will look for first.
An example
Hardware → Printers → Paper jam, or Access → VPN → New account. A category is a department-sized bucket, a sub-category is the thing, and an item is what happened to it. Three levels is the cap: the point of the hierarchy is a short pick list at every step, and a fourth level is a taxonomy nobody keeps up to date.
What it is for
- Reporting — the real reason. "Which sub-category generates the most tickets" is the question a service desk manager asks every month, and a free-text field cannot answer it.
- Filtering — any of the three levels filters the ticket list on its own.
- Consistency — two agents filing the same problem pick the same path, instead of typing two spellings of it.
Optional, unless a tracker says otherwise
Classification is optional by default. Turn on Require a category on a tracker (Trackers & priorities → edit a tracker) to insist on it for that ticket type. Sensible for a Service Request, usually wrong for an Incident somebody is raising at 3am — which is why the switch is per type rather than workspace-wide.
Names are unique among siblings, not globally
"Other" under Hardware and "Other" under Access are two different things, and every service desk ends up with both. Only two entries sharing the same parent have to differ.