How do you automate ticket triage, routing and escalation?

You automate triage by putting a classification layer in front of your helpdesk that makes four decisions on every incoming request — what it is, who owns it, how urgent it is, and whether it can be answered without a person — and writes those decisions into the helpdesk you already run. An LLM does the reading and extraction; deterministic rules do the routing. Anything the classifier is not confident about goes to a human queue with the extracted context attached.

Triage is the highest-return part of support automation because it pays off even when the answer still comes from a person. Below: the architecture, the escalation rules that make it safe to run, and the metrics that tell you whether it works.

What is triage, precisely?

Four decisions, made in the first minute after a request arrives. Today a person makes all four by reading the email:

• What is this? — the request type, from a closed list your team already uses.
• Who owns it? — the queue, team or person, based on type, product, customer and language.
• How urgent is it? — priority and SLA clock, from contract tier, keywords, and how long the customer has already waited.
• Can it be answered now? — whether the reply exists in a source the system can read, or whether it needs a person.

Three of the four are classification problems. Only the fourth is about answering. That is why a triage layer produces value long before anything resembling an autonomous support agent.

What does the pipeline look like?

Six stages, all of which run inside infrastructure you own:

• Ingestion — a workflow engine (we use N8N) receives inbound email or webhook events from the helpdesk and starts a run per ticket.
• Classification and extraction — a model running in your own cloud account reads the message and returns structured fields: type, product, customer reference, order number, language, a clean summary.
• Enrichment — the workflow looks the customer up in the systems of record: contract tier, open orders, past tickets. Routing without this context is guesswork.
• Decision — routing and priority rules run on the extracted fields. Rules live as data, not buried in code, so your team can change them without a deployment.
• Write-back — queue, priority, tags and summary are written into your existing helpdesk through its API. PostgreSQL keeps the run data for measurement.
• Exception queue — below the confidence threshold, the ticket goes to a person with everything extracted so far attached.

The split matters: the model reads, the rules decide. A model asked to both understand the ticket and apply your commercial policy will be inconsistent about the policy. Keeping routing deterministic means a change to an SLA is a change to a rule, and it behaves the same way on every ticket afterwards.

What should always escalate to a human?

Escalation rules are where support automation earns or loses trust internally. Six that belong in every deployment:

• Confidence below the threshold you set — the single most important rule, and the one that keeps a smaller model safe.
• Contract tier or named accounts — some customers should never wait in an automated queue, regardless of what they asked.
• Complaint or churn language — an unhappy customer is a commercial event, not a support ticket.
• Money above a threshold — credits, refunds and claims over a limit you choose stay with a person.
• SLA at risk — if the clock is close to breaching, the ticket jumps to a human queue rather than waiting for a retry.
• Repeat contact on the same issue — the second email about one problem is a signal the first answer failed.

Every one of these lowers the automation rate. That is the point. A system tuned to maximise the percentage will eventually answer a complaint from your largest customer with a template.

What does it produce in practice?

At an industrial components distributor running this architecture in its own cloud account, 85% of tickets are created and classified automatically from inbound email, and the team got back roughly 58 hours a month. Requests that arrive on a Sunday are triaged on Sunday. These are measured numbers from a live system.

How do you know the triage layer is working?

Four metrics, all available from the run data the pipeline stores: the share of tickets classified without human intervention, the misroute rate (tickets a person moved after the system placed them), time to first touch, and the share of escalations that a reviewer agrees were correct.

The fourth is the one most teams skip and the one that catches silent failure. A system that escalates everything looks safe and delivers nothing; a system that escalates nothing looks efficient right up until it is not.

When is triage automation the wrong project?

When the queue taxonomy is incoherent, automation will make the incoherence visible and constant. Fix the categories first; it is cheap and it helps the humans too.

And when volume is low. Triage pays back on repetition. Below a few hundred tickets a month, the honest recommendation is usually to automate something else first — which is exactly the kind of answer an ROI-first look at your flows should give you, including the flows we tell you not to build.

How does your queue get sorted today?

Take the free AI Audit — five minutes, and you get a straight read on how AI-ready your support operation is and what to automate first. Then book a call if you want to walk through the queue with us. See also: Customer Support Automation and what resolution rate is realistic.