How to Route Support Tickets Automatically Using AI Decisions

You route support tickets automatically by sending each new ticket to a language model that classifies it on two axes, topic and urgency, then using those labels to pick a queue and a priority. A webhook catches the ticket, the model returns structured labels, a switch routes on them, and anything the model is unsure about goes to a human triage queue instead of a wrong guess. The single most common mistake is routing on topic alone. Topic decides who handles it. Urgency decides when. Route on one and you will deliver the right ticket to the right team two days too late.

The two axes that matter

A ticket has at least two independent properties, and conflating them is the root of most bad routing. The topic is what the ticket is about: billing, a bug, onboarding, a feature request. The urgency is how fast it needs a human: a churn threat and a typo report can share the topic "account" and could not be more different in priority. Build the classifier to return both, and route on both.

The classification step

Ask the model for structured JSON, define each category by intent, and include an "unsure" option so it has an honest way out. Here is the prompt shape that has held up for me across several support pipelines.

Then the routing step reads the labels and picks a destination. In n8n this is a Code node feeding a Switch, or in Make a router with filters on the parsed JSON. The important part is the urgency override: a critical ticket jumps the queue no matter its topic.

The ticket that sat for two days

May 2025, a Tuesday, a 12-person SaaS routed about 300 tickets a day with an AI classifier that worked on topic only. Aisha, who ran support, was happy with it until a customer wrote in threatening to leave over a billing dispute. The classifier read it correctly as "billing" and dropped it in the billing queue, which ran on a normal 48-hour SLA. The churn signal was right there in the text, and the system had no axis to act on it. The ticket sat for two days. The customer cancelled. We added the urgency axis that afternoon: the same classifier now returned a priority, and any critical ticket jumped straight to an escalations queue with a 30-minute target regardless of topic. The next near-miss churn ticket was answered in eleven minutes. One extra field in the JSON was the whole fix.

The cost of classifying is trivial. A ticket is a few hundred tokens, and GPT-4o-mini runs at 0.15 dollars per million input tokens and 0.60 dollars per million output (OpenAI 2024 pricing page), so routing 300 tickets a day costs cents. Compare that to a managed resolution product like Intercom Fin at 0.99 dollars per resolution (Intercom 2026 pricing) and you can see why building the routing layer yourself is often the cheaper call, as long as you keep a human in the loop for the hard cases.

Classify, do not auto-resolve, until you have earned it

My opinion, and it costs people nothing to ignore until it bites them: an AI routing system should classify and route, not auto-reply, for the first few months. Routing a ticket to the wrong queue is an annoyance someone fixes. Auto-sending a wrong answer to a customer is a trust event you cannot take back. Start with routing only, watch the misroute rate fall as you tune the categories, and add auto-replies later, and only on the safe, narrow intents like password resets. Where I will hedge: if you have a genuinely high-volume, low-stakes inbox, auto-resolving the easy 30% earlier can be worth it, as long as a low-confidence score always routes to a person. For the confidence side of this, see adding fallback logic for low-confidence agents, and for the branching foundations, AI conditional logic for automation workflows.

Frequently asked questions