Support ticket triage with AI: classify, enrich, route — and measure the reassignments

Every support ticket starts with the same unglamorous minute. Someone reads it, decides what it's about, guesses how urgent it is, and sends it to a queue. Multiply that minute by every ticket and it is a meaningful share of a support team's day — and when the guess is wrong, the ticket bounces between teams while the customer waits. Misrouting is the expensive part: not the minute, the reassignments.

That first minute is one of the cleanest things to hand to a model, as long as the model is doing triage and not support.

What the system does

Classify. A language model reads the ticket and produces structured labels: product area, kind of request (bug, how-to, billing, feature ask), urgency signals, and a confidence for each. Not free text — labels your routing rules can act on, drawn from a taxonomy your team already uses.

Enrich. Before the ticket reaches an agent, attach what the agent would otherwise go looking for: similar tickets already resolved, the relevant help article or known issue, the customer's tier and recent history, and — where the request is routine — a draft reply the agent can edit rather than write.

Route. Assignment based on the labels plus what the ticket system already knows: which team owns the area, who has capacity, which accounts get an escalation path. Deterministic rules on top of the model's labels, so the routing is explainable and changeable without retraining anything.

Fall back. Low confidence goes to a human triage queue, not to a best guess. A misroute costs more than a minute of a person's attention.

Where it earns its keep

The gains are real but they live in specific places:

• Reassignments. The metric that matters. If tickets stop bouncing, first-response and resolution times follow; if they don't, the classifier is confident and wrong.
• Enrichment over speed. Shaving the triage minute is fine. Handing the agent the last three similar tickets and the right article is what shortens the conversation with the customer.
• The taxonomy. A model can only sort into categories that exist. If the current categories were designed for reporting rather than routing, fix the taxonomy first — the model will faithfully reproduce whatever mess it is given.
• Drift. A new product release changes what tickets say. Track classification accuracy against a sample of human-labelled tickets every week, or the system will quietly decay while the dashboard stays green.

What it should not do

It should not answer the customer. Drafting a reply for an agent to send is triage; sending it is support, and the failure modes are different — a wrong label costs a bounce, a wrong answer costs a customer. Keep the model on the inside of the desk until the drafts have earned their way out, one category at a time.

Getting started

Export a few thousand resolved tickets with the team they ended up in. That is the training and evaluation set, and it costs nothing. Run the classifier in shadow mode — labelling without routing — for two weeks, compare against what humans did, and fix the taxonomy where they disagree. Then let it route the categories where it agrees with the team, and keep the rest in the human queue. The list of categories it owns should grow; the reassignment rate should not.