AI ticket routing, worked end to end.
A worked example: ten weeks of the process we actually run, applied to one realistic problem — including the parts that go wrong. The names and numbers are illustrative; the sequence, the decisions and the trade-offs are the ones we use on every project.
Updated 24 September 2026
Say a 40-person support team gets 4,000 tickets a week, and two people spend their whole day just routing each one to the right specialist.
Bring us your version of it- The engagement
- What the work turns up
- The decision that closes it
We price the workflow, not the request
Read the full step: Week 0A worked example, not a client story — the scenario and its numbers are hypothetical. The process is the part that is real. Routing like this needs a trained small model, so it runs longer than a two-week assistant.
How small private models work Bring us your version of it- 01 / 06 Week 0 Scratch
We price the workflow, not the request
The first days are spent beside the two people who actually route. We sample a week of tickets, time each step, and put a cost on the workflow as it runs today rather than as the org chart describes it. The more you can tell us at this point — the exceptions, the edge cases, the tickets nobody wants — the more of that week goes into weighing options rather than into asking questions. Every candidate use case is then scored on four things: volume, the cost of getting it wrong, how ready the data is, and how much of the job a model can honestly carry.
Risk — Wrong problemThe brief says “automate routing”. The sample often says something else — if a third of tickets bounce because the first reply had to go back and ask for a serial number, routing was never the expensive part of the week.
Decision — Score bothWe price both jobs side by side on one scorecard and build whichever has the shorter path to payback, out of the smallest components that will hold. A large model is not automatically the right answer to a small problem, and a build that cannot pay for itself is not one we will recommend. If the first framing does not clear the bar, we reshape it with you — a narrower slice, a different part of the workflow — until there is an option worth building, and the fixed quote you get is for the one we would stand behind ourselves.
- Timed workflow cost baseline
- Use-case scorecard
- Fixed build quote
- 02 / 06 Week 1–2 Scratch
Agree what “right” means before building anything
A model is only as useful as the yardstick you hold it to, so the yardstick comes first. We pull twelve months of tickets, build a held-out evaluation set out of decisions your own team already made, and write down the pass mark: what accuracy, on which slices of traffic, at what cost per ticket, judged by whom. Week zero established what the problem is; this is where we establish how it is actually solved, rather than accepting an answer that merely looks plausible.
Risk — Dirty labelsHistorical assignments are not ground truth. Tickets get reassigned once, twice, sometimes three times before they land, so training on the first assignment teaches the model your team’s existing mistakes and then scores it against them. The result reads as success, which is the most expensive way there is to be wrong.
Decision — Resolver truthWe label from the queue that actually resolved the ticket, keep the reassignment chain as a signal in its own right, and quarantine the most recent month so the final evaluation runs on tickets nothing in the build has ever seen. Verification then runs in stages: what the model does, what it refuses to do, and each part of the knowledge base behind it in turn. The larger that knowledge base, the longer the stage takes — we quote that time rather than trim it.
- Held-out evaluation set
- Written pass mark and owner
- Per-queue baselines
- 03 / 06 Week 3 Prototype
A working system in week three, off to the side
To be clear, this is a demo — real system, real data, but not production-ready. Nothing it decides reaches a customer yet.
A small classifier and a routing agent, deployed against your real backlog and put in front of the people who route today. It is a real deployment — same data path, same authentication, same queues — with the ability to act switched off: it decides nothing and changes nothing. Someone on your side who knows what a good outcome looks like needs to read those decisions, and by the end of the week there are enough of them for a first honest report on where it is right and where it is not.
Risk — The long tailEight queues cover most of the week. The other forty hold a dozen examples each, and that is where confidence becomes expensive: a message that reads like a billing complaint for three paragraphs before mentioning the customer could see somebody else’s order is a security ticket. There are nine of those in a year, and sending one to billing costs far more than leaving it for a human to open.
Decision — Let it abstainThe agent is allowed to say it does not know, and on a ticket like that one “I am not sure, someone should look at this” is the better answer: a confident guess built on a wrong assumption creates work for months. We tune the confidence threshold against the evaluation set and hand you the coverage-versus-accuracy curve, so the trade — route more, or route more safely — is your decision, made on numbers. When it abstains it passes the ticket to a person, which is the design working rather than a gap in it.
- Deployed prototype on real tickets
- Coverage / accuracy curve
- Sessions with the routing team
- 04 / 06 Week 4–5 Build
Into the stack, then two weeks in shadow
The prototype becomes part of the systems it has to live in: your helpdesk, your identity provider, your on-call rotation. Then it runs in shadow — predicting every ticket, acting on none — so you can read a fortnight of real decisions before a single customer is affected by one.
Risk — Blast radiusAn agent holding a helpdesk API key can usually read every queue in the company, including the ones belonging to HR and legal. It is the integration risk that never comes up during a demo.
Decision — Scope and logA separate service account per queue, a written allowlist of the actions it may take, and an audit line for every read and write. With shadow mode on top, the first decision that touches a customer is the thousandth decision it has made.
- Scoped access and full audit trail
- Two weeks of shadow decisions
- One-switch rollback
- 05 / 06 Week 6–8 Build
The difference between a demo and a system
Retries, fallbacks, cost ceilings and a load test at three times your peak week. Alerts go to a person on a rota rather than to a dashboard nobody opens. This is everything that has to be true before a team can stop watching a system and simply use it.
Risk — Unit cost driftCost per ticket looks settled until a forty-message thread arrives with three PDFs attached. A handful of those a day can quietly cost more than the entire rest of the queue put together.
Decision — Cascade + capThe small model classifies first and a large model is called only when confidence is low; threads are trimmed to the parts that carry routing signal; and a hard per-ticket ceiling stops the bill before it becomes a conversation with your CFO.
- Cost ceiling per ticket
- Load test at 3× peak volume
- Human fallback on low confidence
- 06 / 06 Week 9–10 Run
Live, monitored, and still improving
The system goes live on hosting we manage, or in your own cloud if your data rules require it. We run it, monitor it and roll out improvements from the core as they land. What we ask in return is notice: when the data changes, when the way you process it changes, or when you agree a new standard for what a good answer looks like, tell us before it lands rather than after, so the system is ready for it instead of quietly drifting away from it.
Risk — Silent driftSix months on, a new product line launches, the ticket mix shifts and accuracy decays without anyone noticing — the system keeps answering just as confidently while it slowly stops being right.
Decision — Evals on every changeThe evaluation suite runs on every change and monthly against a fresh sample of your tickets. Abstention rate is the early warning: when it drifts past the line you agreed in week two, we hear about it first and so do you.
- Managed hosting and monitoring
- Evals on every change plus a monthly re-run
- Core updates and model upgrades
A worked example, not a client story — the scenario and its numbers are hypothetical. The process is the part that is real. Routing like this needs a trained small model, so it runs longer than a two-week assistant.
How small private models work Bring us your version of itBring us one workflow. We’ll tell you what it needs.
A 30-minute call. Bring one real process or one sample document. We’ll tell you whether it needs an LLM, a small model, or just a script, and what it would take. No deck.