Support Ticket Routing: Getting Requests to the Right Team

Support ticket routing is deciding which team owns a request the moment it's created, so it lands in the right queue without a human sorting it. The reliable approach for internal desks is layered: let the requester pick the team in plain language, apply simple rules for the obvious cases, and use AI only to suggest a category when it's confident. Then measure reassignments — every ticket that changes team is a routing failure you can learn from.

Why routing matters more than speed

A misrouted request waits twice. It waits in the wrong queue until someone notices it isn't theirs, then waits again in the right queue from the back of the line. Meanwhile its SLA clock has been running since creation. You can have fast agents and still breach, because the time was spent in transit.

Routing also decides who sees what. In a multi-team desk, each team works its own queue; a request routed to the wrong team is invisible to the people who could fix it.

Three ways to route (and when each fits)

1. The requester chooses

The simplest and, for internal desks, often the most accurate. Employees usually know whether their problem is "IT", "HR" or "Finance" — if the options are named in their words, not the org chart's.

• Write team options as problems: "Laptop, account or software → IT"; "Pay, leave or contracts → HR".
• Keep it to one required choice. Two-level menus (team, then sub-category) cause people to pick "Other".
• Allow "Not sure" that goes to a triage queue.

This is LetRelay's default: the requester picks the team, and that choice is never overridden automatically.

2. Rules

Keyword and form-field rules handle the obvious cases deterministically: a request from the "New starter" form goes to IT and HR; anything mentioning "invoice" goes to Finance. Rules are predictable, auditable and free. Their weakness is language — people describe the same problem in many ways, and rule lists grow brittle.

Use rules for channels where the intent is structural (a specific form, a specific inbound email address, a webhook from another system) rather than for free text.

3. AI suggestions

A language model reads the free text and suggests a category, priority and possibly a team. It handles varied wording far better than keyword rules, and with structured output it returns a clean, validated JSON object. How to do this safely is in AI request classification with structured output.

The safety rules:

• Suggest, don't override. When the requester chose a team, AI refines the category within that team; it doesn't move the request elsewhere.
• Confidence threshold. Apply the suggestion automatically only above a high confidence (LetRelay defaults to 0.8, adjustable per organization); below it, show it as a hint for triage.
• Fail open to humans. If the model is unavailable, out of quota or returns something invalid, the request goes to human triage untouched. See AI that degrades gracefully.
• Auto-route only what has no owner. Intake with no team chosen — an inbound webhook or email — is where automatic team routing earns its keep.

Designing the team list

The team picker is the routing algorithm for most internal requests, so it deserves design attention. A worked example for a 60-person company:

Option the requester sees	Routes to	Notes
Laptop, account, password or software	IT	The most common; put it first
Access to a system or shared folder	IT (Access category)	Split out because it often needs approval
Pay, leave, contracts or benefits	HR	Visible only to HR — see below
Expenses, invoices or purchases	Finance
Office, desks, keys or supplies	Facilities
Not sure	Triage queue	Someone routes it within an hour

Keep it to around six options. Order by frequency, not alphabetically. Re-check the list every quarter against where requests actually ended up — the reassignment report tells you which labels confuse people.

Sensitive teams need private queues. HR and finance requests often contain salary, health or personal details. Their queues should be visible only to their own team, enforced by the database rather than by hiding a menu item. A misroute into a sensitive team is harmless; a misroute out of one leaks information, so reassigning from HR to another team should strip or confirm the conversation first.

Routing requests from other channels

Requests don't only come from the form. Chat messages, emails and webhooks from other tools can create requests too; the routing question is the same, but there's no requester choosing a team. For those:

• Map each channel to a default team where the intent is clear (the #it-help channel goes to IT).
• Use AI routing only here, where no human has chosen, and still send low-confidence results to triage.
• Verify the sender. A webhook that creates requests must check a signature so outsiders can't flood your queue; see turning Slack and Discord messages into tickets with webhooks.

Measuring routing quality

You can't improve routing you don't measure. Record every team change as an event with the old team, the new team and who changed it. Then track:

Metric	What it tells you
Reassignment rate per category	Which request types are hard to route
Top from→to pairs	Which teams' boundaries confuse people
Time before reassignment	How long misroutes sit before anyone notices
AI suggestion acceptance	Whether the model is helping or being overruled

A high reassignment count between two specific teams usually means the options on the form are confusing, not that requesters are careless. Fix the wording first. More measurement ideas are in help desk metrics that matter.

Fixing a misroute quickly

Misroutes will happen. Make recovery cheap:

• One-click reassign with a required note — the note tells the next team what's been tried.
• Keep the history. The request carries its conversation and events with it.
• Decide on the clock. Either let the SLA keep running (honest to the requester) or record the handoff for an OLA between teams — see SLA vs OLA vs KPI. Don't silently reset it.
• Notify the receiving team's triage owner, not the whole team.

Routing by skill and load inside a team

Once a request reaches the right team, someone still has to own it. Common strategies:

• Self-assignment from a sorted queue — agents take the top item. Simple and fair for small teams.
• Round-robin — even distribution, blind to complexity.
• Skill-based — certain categories go to certain people. Useful for specialist work, risky if one person becomes a single point of failure.
• Load-aware — assign to whoever has the fewest open items. Needs honest status data (people marked away shouldn't receive work).

For most internal teams under about ten people, a deadline-sorted queue with self-assignment and a daily triage owner outperforms anything clever. Priorities within that queue are covered in managing request priorities without chaos.

Routing checklist

• Team options written as problems, in the requester's words
• One required choice plus "Not sure"
• Rules only for structured channels
• AI suggests within the chosen team, with a confidence threshold
• Unrouted and low-confidence requests go to a human triage queue
• Every team change recorded as an event with a note
• Reassignment report reviewed monthly

FAQ

What is ticket routing in a help desk?

It's the assignment of each incoming request to the team (and eventually the person) responsible for it, ideally at the moment of creation, so it reaches the right queue without manual sorting.

Should AI route support tickets automatically?

Only where no one has chosen a team and the model is highly confident. Otherwise AI should suggest a category and priority for a human to confirm. Always keep a human triage path for when the AI is uncertain or unavailable.

How do I reduce misrouted tickets?

Rewrite the team options in plain problem language, measure which team pairs swap requests most, and fix the wording or the ownership boundary between those teams.

What's the difference between routing and assignment?

Routing picks the team; assignment picks the person within the team. Get routing right first — a perfectly assigned request in the wrong team still waits.

Sources

• Google — Gemini structured output
• Groq — Structured outputs
• Atlassian — What is ITSM?
• Wikipedia — Help desk