Help Desk Categories & Subcategories — All Support Ticket Categories

Support ticket categories are the labels used to sort the tickets coming into a help desk. That category then decides a few things, which team picks the ticket up, the SLA it runs on, and how the reports read at month-end. So it is worth getting right. When the categories are wrong, the tickets go to the wrong desk, the priorities slip, and the numbers stop telling you much.

Every ticket is classified on three things at once, the what (the issue type), the who (the department or service it affects), and the how (the urgency). The post takes each of the three in turn.

There is a size to aim for too. A taxonomy that works keeps to about 5 to 8 top-level categories, and you put subcategories under them where the extra depth is needed.

The rest covers the classification principles, a full set of starter categories you can lift and adapt by industry, and keeping the whole thing clean as it grows.

How Support Tickets Get Classified (The Three Axes)

Take the three one at a time.

• The first axis, the what, is the issue type. This is where the ITIL classification comes in, incident, request, problem, change, and it is the one most teams already have in some form. It sets how the ticket gets worked, a broken laptop does not get handled like a request for new software.
• The next is who, which is the department or service the ticket touches. On an internal desk, you are looking at a business function, Sales, Engineering, IT, HR, Finance. For a SaaS product, it is usually the product area instead, billing, the API, the mobile app.
• Urgency is the how, and it is really the priority, worked out from impact and urgency together. Priority is what the SLA clock runs on. How you actually calculate it is a topic on its own, so this stays brief.

Most help desks let these three run into each other, one dropdown trying to be all of them at once. Keeping them apart, with the right kind of field doing each job, is what makes the reporting hold up over time.

The ITIL Classification: Incident, Request, Problem, Change

Most It Teams Classify the "what" with the ITIL scheme, and it splits into four types. Getting them right matters, because misclassification is the main reason help desk metrics end up skewed. Log half your incidents as requests, and your resolution times and SLA reports stop meaning much. The ITSM frameworks behind ITIL go deeper, but for categories you mostly need these four.

An incident is something broken. A service is down or degraded, and the user wants it working again, a laptop that will not boot, an app throwing errors, the VPN dropping. Incidents run on tight SLAs because someone is blocked right now, and the full workflow for handling them is the incident management lifecycle.

A request is not a break, it is someone asking for something, access to a shared drive, a new laptop, a license for an app. Requests are planned work, so they carry different SLAs, and mixing them with incidents, the service request vs incident confusion, is where a lot of reporting goes wrong.

Behind repeating incidents there is usually a problem, the root cause. You fix the problem to stop the incidents coming back. That shift, from a one-off incident to a recurring problem, is the point at which an incident becomes a problem.

Then a change, which is any planned modification to the environment, a deployment, a config update, a server move. It is controlled work, tracked on its own because it carries risk if it goes wrong.

How Many Top-Level Categories Should You Have? The 5-To-8 Rule

So how many top-level categories are right? The sweet spot is 5 to 8. Enough to tell the tickets apart, and still short enough that people pick the right one without thinking too hard about it.

Go under that, and the reports stop being useful. With two or three categories nearly everything lands in "Technical Issue" or "Other", and a report that says 80% Other tells you nothing you can act on.

The other direction is its own problem. Once you are past 20 top-level categories, agents stop reading the list and just grab the nearest one, users pick the wrong thing, and the data gets unreliable fast. A long dropdown looks thorough, but the data underneath gets worse.

If you genuinely need more depth, that is what subcategories and custom fields are for. Put the detail underneath, do not flatten it all into one giant top-level dropdown.

Common Help Desk Categories By Industry

The quickest way to build a taxonomy is to copy one that already fits your business, then trim it. Here are starter sets for the common desks, the categories with a few example subcategories under each, ready to lift and rename.

Internal IT Help Desk

The internal IT desk is the classic, and most of them land close to this.

• Hardware. Laptops, desktops, monitors, the peripherals that go missing.
• Software, the installs and licensing, errors, and requests for a new tool.
• Network and connectivity, mostly Wi-Fi and VPN, and the internet going down.
• Accounts and access. Passwords first, then permissions, MFA, provisioning.
• Email and collaboration, Outlook or Gmail, Slack or Teams.
• Telephony and conferencing, the desk phones and the Zoom or Webex side.
• Printers.
• Security, phishing reports and lost devices, the stuff you deal with fast.

Most desks will not need all eight. Small teams can fold Telephony into Hardware, and pull Security out on its own once the volume is there.

SaaS Product Support

A SaaS product desk splits around the product, not the hardware.

• Bugs and product errors.
• Feature requests, the can-you-add tickets.
• How-to and configuration questions.
• Billing and subscription, upgrades, invoices, and cancellations.
• Integrations.
• Account and user management, the seats, roles, and permissions.
• Security and compliance questions.

Bugs and feature requests are the two to keep really clean, the product team reads those reports.

E-commerce Customer Support

An e-commerce desk is mostly the order, before it ships and after.

• Order status and tracking, the where-is-my-order tickets.
• Shipping and delivery.
• Returns and refunds, usually the biggest pile.
• Product issues, defective or the wrong item sent.
• Pre-sales questions.
• Account and payment.
• Promotions and discounts.

Internal HR or Employee Support

HR desks are the people's side, and a good chunk overlaps with IT.

• Onboarding and offboarding, the joiners and leavers.
• Benefits and payroll.
• Policy questions.
• Workplace issues.
• PTO and leave.
• Equipment and access, usually shared with IT.

Professional Services and Agencies

Agencies and professional-services teams tend to organise a level up, by the work itself. Usually by client, or by engagement, or by matter or project, with the issue categories nested underneath. Smaller audience, so this one stays short.

Categories vs Tags Vs Custom Fields (And Why Most Teams Get This Wrong)

These three get mixed up all the time, and using the wrong one for a job is where a lot of taxonomies go wrong.

• A category is the one required label on a ticket, one value only. It does the routing, sets the SLA, and says which team owns the thing.
• Tags you can stack as many as you want, or skip entirely. They are free-form, and nothing routes off them, so they hold the context, a "vip-customer", a "needs-engineering", an "overdue".
• Custom fields are the structured stuff, a dropdown, a date, a text box. Good for data you want to filter and report on the same way every time, the product version, say, or the plan tier.

Most teams go wrong by making one of the three do all three jobs. Everything in categories, and you get 50 of them and bad data, or you keep five and lose the detail in the reporting. Modern help desks let you combine all three. Use each one for its own job.

3-Tier Ticket Categorization — Category, Subcategory, Item

The industry lists above stop at the top level. In practice, a working taxonomy goes three tiers deep, a category, then a subcategory, then the item, which is the actual thing that went wrong. Three tiers is about the limit. Go deeper and agents start skipping levels or guessing.

Here is how it reads. Category is the broad bucket, say Hardware. Subcategory narrows it to a Laptop. Then the item, the specific issue, a battery that needs replacing. That third level is what makes the reporting useful, because "12 Hardware tickets" tells you little, but "8 of them were laptop batteries" tells you to order more batteries.

The table below is a starter help desk category list for an internal IT desk, the same taxonomy from earlier taken down to the item level, so it doubles as a set of help desk categories and subcategories examples. Lift it, cut the rows that do not apply, and rename the rest to match your setup. It is a reference to copy, not a fixed standard.

Category

Subcategory

Example item

Hardware

Laptop

Battery replacement request

Hardware

Laptop

Laptop will not power on

Hardware

Monitor

External display not detected

Hardware

Peripherals

Keyboard or mouse not working

Hardware

Peripherals

Docking station not charging

Software

Installation

Request to install a licensed app

Software

Licensing

License renewal or extra seat

Software

Errors

Application crash on launch

Software

Errors

Application running slowly

Network

VPN

Cannot connect to the corporate VPN

Network

Wi-Fi

Intermittent connectivity in the office

Network

Wi-Fi

Guest Wi-Fi access request

Network

Internet

Office line down

Accounts and access

Password

Password reset request

Accounts and access

Permissions

Access request for a shared drive

Accounts and access

MFA

Reset a lost MFA device

Accounts and access

Provisioning

New starter account setup

Email and collaboration

Email

Cannot send or receive mail

Email and collaboration

Distribution lists

Add or remove a group member

Email and collaboration

Collaboration tools

Slack or Teams access request

Security

Phishing

Report a suspicious email

Security

Phishing

Suspected malware on a device

Security

Lost device

Report a lost or stolen laptop

Security

Access review

Deactivate a leaver's accounts

Best Practices For Category Design

A few category design best practices keep a taxonomy working once it is live. None of them are complicated, but skipping them is what turns a clean category list into a mess a year later.

• Every ticket should fit exactly one category, and it should always have one to fit. That is the MECE principle in plain terms, mutually exclusive so nothing overlaps, collectively exhaustive so nothing falls through. When a ticket could go in two categories, or in none, there is a hole to fix.
• The "Other" bucket is the one to watch. A small one is normal, you will never categorize everything, but once "Other" passes about 10% of total volume, the taxonomy is missing categories. Review it each quarter and lift the repeating patterns out into their own categories.
• Three tiers is the practical ceiling, category, subcategory, item. Go deeper and agents skip levels or pick something at random, and the resolution categories in your reports stop meaning much.
• Overlap is the quiet killer. "Email Issue" next to "Outlook Issue" just makes agents guess, and the data splits in half for no reason. If two categories could describe the same ticket, merge them or spell out the line between them in the description.
• Review the taxonomy quarterly, not once a year. New products, new services, and team changes all create new support categories, and an annual cycle lets months of bad data build up before anyone notices.
• The agents picking categories all day will spot the gaps before any dashboard does, so give them a quick way to flag one. It is one of those ticket handling best practices that only works when the feedback loop is real.

None of this is exotic, it is the ordinary help desk best practices applied to the category list itself.

Is Your Taxonomy Healthy? A Self-Assessment Checklist

You can tell fairly fast whether a taxonomy is working. Run through the checklist below and count your yes answers. It is built to be printed or thrown up on a screen in a team meeting, a quick audit of your support ticket categories rather than something to score in your head.

Answer yes or no to each:

1. Every ticket from the last 30 days fits exactly one category, no dual-filing, no "it could be either."
2. Your "Other" or "General" bucket is under 10% of total volume.
3. Every top-level category has had at least one ticket in the last 90 days, so no dead categories.
4. An agent can pick a category in under five seconds without opening a reference guide.
5. You have between 5 and 8 top-level categories, not 2, not 25.
6. You reviewed and updated the taxonomy some time in the last quarter.
7. Category names are plain language, the kind a new hire would understand on day one, not internal jargon.
8. You can pull a report of ticket volume by category that actually tells you something to act on.
9. Categories, tags, and custom fields each have their own job, you are not making categories carry what belongs in tags or fields.

Tally the yeses.

• 8 or 9 yes: the taxonomy is in good shape, keep the quarterly review going.
• 5 to 7 yes: it works, but there are gaps, start with whatever you answered no to.
• Under 5 yes: it needs a rebuild, go back to the 5-to-8 rule and the MECE principle and start again.

Operationalizing Your Taxonomy

A taxonomy needs looking after once it is live. A few habits keep it doing its job.

• Categories are not forever. When a product gets shut down, retire its category, do not leave it there as a dead option people pick by mistake. A new service should get its category made before the tickets show up, not once they are already piling into Other.
• The ML side actually works now, most help desks can read the subject and the body and either suggest the category or set it. The thing is it learns off your old tickets, so an Other-heavy history teaches it almost nothing and the guesses stay rough. Clean the data first, then lean on the automation.
• Skill-based routing next, a category should point at a team. Network goes to the network engineers, Billing to finance ops. When a category has no obvious owner, it is either too broad, or the team setup is not sorted yet, and your service categories and resolution categories want to match up with whoever actually fixes the thing.
• Some categories can close themselves out, the password resets, the access requests, an automation rule does it, and no agent gets involved. That only holds up if the taxonomy is clean enough for the rule to trust what it reads. Which ticketing system features can do this changes tool to tool.
• For teams that live in Slack there is something like Suptask for this. A "Network" category can route the ticket and ping the network engineering channel inside Slack itself, no separate portal to log into, and that routing is what the Slack integration comes down to.

Frequently Asked Questions

What is support ticket classification?

Classification just means tagging each ticket with a category, and often a subcategory, when it comes in. That label is what routes it to the right agent, fires the right automation, and lines it up in the right report. So it is less about labelling for its own sake and more about everything the label sets off afterwards.

What are the categories of tickets?

There is no single fixed list, it depends on your business, but they all sort along the same three lines, by issue type, by the department or service affected, and by urgency. On the issue-type side, most IT teams use the ITIL split, incident, request, problem, and change. The industry starter sets earlier in this post are a good place to copy from.

What's the difference between a help desk and a service desk taxonomy?

They overlap a lot, the difference is scope. A help desk is mostly about resolving the user-facing issues, so the categories lean that way. A service desk adds the ITIL workflows on top, the changes, the problem management, the releases, so its taxonomy carries those too. The service desk vs help desk split goes into where the two actually diverge.

Should categories follow ITIL?

For an IT support team, usually yes. The ITIL classification, incident, request, problem, and change, is well understood, and it maps cleanly onto how the work gets done. If you are doing pure customer support for a product though, ITIL can be more than you need, and simpler categories often work better.

What's the right "Other" bucket size?

A small "Other" bucket is fine, you will never categorise everything. The number to watch is roughly 10% of total volume. Once "Other" climbs past that, the taxonomy is missing categories, so review it every quarter and pull the recurring patterns out into proper categories.

Can categories be automated by AI?

Yes, and most modern help desks already do it. They use ML to read the subject line and the body and either suggest a category or set it outright. The catch is it only works as well as your history, an "Other"-heavy back catalogue teaches the model almost nothing, so clean data comes first.

How do you migrate from a bad taxonomy to a good one?

Start by taking a snapshot of where the tickets currently sit by category. Design the new set with the MECE principle, then map the old categories onto the new ones so the history still lines up. Roll it out with a transition period where both old and new are visible, and do not try to migrate the whole back catalogue over a weekend.

Do categories matter if we use AI agents?

They matter more, not less. An AI agent needs a category structure to route against, to know when to escalate, and to report on what it handled. The AI does not replace the taxonomy design, it runs on top of it.