How do I stop routing every ticket by hand when IT and HR share one queue?

The short answer

Stop asking one person, or one rule set, to guess the right team from a free-text ticket. Separate requests from incidents at the front door, give each a small multi-level category list owned by someone, and route on a handful of simple signals, then check and correct the category at closure so the routing gets better every month.

Why the queue ends up on one person's desk

When password resets, HR access requests and production incidents all land in one inbox with the same "urgent" label, someone has to read every one. That person becomes the routing engine. It feels like a tooling problem, but it is usually a design problem: the queue has no clear record types, no agreed categories and no owner for the rules.

John Sansbury makes the point plainly in The Journey to Service Excellence. Categorising at the moment a ticket is raised is hard because there is rarely enough information yet, and he writes that "Initial categorisation can be challenging and is wrong as much as 70% of the time". Read that as a practitioner's experience rather than a measured benchmark, but anyone who has watched tickets bounce between teams will recognise it. The fix is not a cleverer first guess. It is a system that expects the first guess to be wrong and learns from the correction.

Practical steps

1. Split record types first. Incidents (something is broken), service requests (I need something standard, such as access or equipment) and information requests (I have a question) should be different record types, ideally chosen by the form or portal rather than typed into a subject line. This one change removes most of the guesswork, and it lets HR requests follow their own path without touching IT incidents.

2. Build a short, multi-level category list. John recommends multi-level categorisation, where the first choice limits the second, "with perhaps three or four levels in total". Keep the top level to a few plain words people understand, such as IT, HR, Facilities and Finance, then narrow down. Resist a long flat list. He recalls a UK bank support centre with over 900 categories where, on analysis, "nearly 80% were one category: ‘Other’".

3. Route on a few signals, not dozens of rules. Record type, top-level category and the requester's location or department will route most tickets. Add priority from impact and urgency, not from what the requester typed. Anything that still cannot be placed goes to a single named fallback queue, staffed on a rota, rather than to whoever happens to notice it.

4. Validate the category at closure. The person closing the ticket confirms or corrects the category. John's advice is that the close category, not the open one, is "best for problem management to use as the basis of root-cause analysis". Keep separate open and close fields if your tool allows, so you can see how often the first guess changed and which categories keep being wrong.

5. Give the rules an owner. One person owns the category list and the routing rules across IT and HR, reviews the mismatch report monthly and retires rules nobody needs. Without an owner, automations multiply until nobody dares delete any of them.

Where AI triage fits

AI suggestions can help, especially for spotting that a vague "it's broken" message is really an incident. Treat the AI as a suggestion that a person or a simple rule confirms, and measure it against the close category like any other router. John's wider point applies: he notes that "automation is rarely possible or beneficial until Level 4" of process maturity, because consistency and simplification have to come first. If your categories are not stable yet, an AI will learn your inconsistency faster than you can fix it.

A short worked example

Imagine a 300 person organisation where IT and HR share one inbox. The team replaces the inbox with a portal offering three choices: report a problem, request something, ask a question. Requests get a top-level category of IT, HR or Facilities, with two levels beneath. Incidents are prioritised on impact and urgency. Unclear tickets go to a fallback queue covered by the service desk lead on a weekly rota. At closure, analysts confirm the category. After a month, the mismatch report shows that most corrections involve "access" tickets that sit between HR and IT, so the team adds one joint category with a clear owner. The person who used to route everything by hand now spends that time on the fallback queue and on improving the list.

Common mistakes

Asking users to pick from a long category list and then trusting the answer. Letting every ticket default to the highest priority. Building a new automation for every edge case. Never looking at the close category, so the same routing errors repeat. Adding AI before the categories and record types are stable.

Next step

If you are bringing HR or Facilities into the same service desk, talk it through with other practitioners in the ESM community on ESM's Exchange, and see our related piece on prioritising incidents by impact and urgency: https://exchange.esm.institute/knowledge/prioritising-incidents-by-impact-and-urgency

For more on incident categorisation, support centre structures and process maturity, read The Journey to Service Excellence by John Sansbury, available to members of ESM's Exchange.

Tags: esm-questions, ticket-routing, categorisation, service-desk, enterprise-service-management

Sources

• https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1

• https://www.iso.org/standard/70636.html

• https://exchange.esm.institute/knowledge/prioritising-incidents-by-impact-and-urgency