AI ticket routing: where manual sorting breaks
In support, manual sorting of requests rarely looks like one person at one screen.
In practice, the flow comes from several places at once — email, a website form, chat, a messenger — and the shift lead sorts them manually: reads, identifies the product and team, and sets priority by eye. While the flow is small, the scheme holds and seems manageable.
It breaks under volume and at different times of day.
Two requests about the same thing from different channels are not linked to each other, the client receives two different answers, and some tickets get stuck in personal folders and correspondence — these are the lost tickets that surface during escalation.
Time to first response grows nonlinearly: under peak load, a ticket waits not for an engineer but for a dispatcher's attention.
Keyword rules cover only part of the flow and quickly lose accuracy: wording varies, the subject drowns behind polite framing, and urgency and product live in the same sentence.
At night and on weekends, sorting slows down even more, and the on-duty operator receives an already mixed flow with no priority cues.
AI ticket routing solves not the task of "answering instead of the operator" but the task of sorting the flow before a human touches it: identify the subject, product, language, and urgency, link duplicates into a single request queue, and assign to a group or a specific engineer based on skills and current workload.
Below we break down how this is handled — from labeling historical requests and configuring rules to quality control of the routing itself.
What the shift to automatic request processing delivers
The classifier reads the subject, request body, and customer history, matches them against labels from past tickets, and determines the problem type, product, language, and region.
Based on these attributes, a rule routes the request to the right queue and sets priority instead of dumping everything into a shared inbox. If the model's confidence is below a set threshold, the ticket goes to a human with a note indicating which attribute was disputed.
The auto-distribution rate is the first metric we measure before and after. At the start it is usually 40–60%: what is unambiguously clear from the subject is routed automatically.
After additional training on accumulated labels, the figure reaches 75–85%, and it is limited not by the model but by the quality of the taxonomy — the queues into which requests actually diverge.
The reduction in manual operations comes not from faster reading but from eliminating sorting: the dispatcher handles only disputed tickets.
Stable response time stops depending on shift workload — a request enters the queue as soon as it arrives, including at night and on weekends.
Misrouting disappears as a category: previously a ticket could sit in the wrong queue until the intended assignee noticed it. We feed every queue correction back into the labels, so the next similar case is routed correctly.
In conjunction with Jira Service Management, the basis for the decision is also visible: which attribute caused the ticket to reach the assignee and where the rule worked incorrectly.
Routing methods: rules, model, hybrid scheme
Routing is the layer that decides who receives a request and with what priority.
The approaches differ in predictability and in how much manual work remains for the team: hard rules are transparent and easy to verify, a request classification model handles wording that is not in a ready-made list of subjects, and a hybrid scheme combines both mechanisms.
We design the fallback manual mode separately: when model confidence is low or a request is nonstandard, the ticket enters the dispatcher's queue instead of going out at random.
We define auto-distribution limits in advance — the maximum load per assignee, stop conditions, and mandatory review of disputed cases.
| Option | When it fits | Limitations |
|---|---|---|
| Ticket distribution rules | Stable request types with explicit attributes: subject, direction, channel, customer status | New wording does not fall into the rules, and the list of conditions quickly grows |
| Request classification model | Wording is live and varied, and there is accumulated history of labeled requests | Requires labeling and quality control; when the subject matter changes, retraining is needed |
| Hybrid routing | Rules cover typical cases, and the model covers the rest, including priority and request language | Setup and troubleshooting are more complex: it is important to see which mechanism fired first |
| Manual dispatch | Fallback mode: nonstandard situations, key customers, disputed requests | Depends on operator availability and does not withstand peak load |
We do not choose the scheme by eye: we run it on historical requests and look at the share of correct queue assignments, the share of transfers between assignees, and the number of tickets that had to be handled manually.
Implementation order: from flow analysis to handover to support
The order of stages is not random: each next one relies on the result of the previous. If you skip labeling past requests or testing on them, the system confidently sends tickets to the wrong assignee, and customers are the ones who notice the error. Therefore we move from facts to configuration, not the other way around.
- Request flow audit — we analyze where tickets come from, how many there are by type, and how they are distributed now; we record where the queue accumulates and which requests go to the wrong place.
- Routing scheme design — we describe categories, escalation rules, and the confidence threshold below which a human must review the ticket.
- Historical data labeling — on a sample of past requests, we assign reference categories and priorities. This is the basis on which the scheme can be measured rather than demonstrated on demo examples.
- Configuration and historical testing — we run routing over the labeled set and review the error matrix: where adjacent categories get confused, we adjust attributes and thresholds to acceptable accuracy.
- Pilot operation — we enable a mode where the system suggests a route and the operator makes the decision; we review discrepancies daily and feed them back into additional training.
- Handover to support — we provide the category regulations, the procedure for reviewing disputed tickets, train the team, and remain available for support after launch.
At each step the customer retains an artifact: a flow map, a scheme with thresholds, a labeled set, an error report. They show that the stage is truly complete and make it clear what to return to when ticket types change.
What the customer retains: rules, models, regulations
The ticket distribution scheme should not remain a "black box" on the contractor's side.
Everything that determines its behavior — rules, configurations, documentation — is transferred to the customer's environment so that six months later an engineer can add a new request category or change the classifier's sensitivity without reconstructing the logic from correspondence.
- Routing map — which request categories are defined, which queues and assignees they are assigned to, and where a ticket goes if the model is not confident in its analysis.
- Request priority rules — attributes that move a ticket to the front of the queue: repeat contact, contractual deadline, customer status; the procedure when several rules fire at once is described separately.
- Roles and access rights — who only views reports, who changes rules, who approves new categories; separation by department and by scope of visible data.
- Escalation regulations — under what conditions a ticket goes to an operator, how long it waits for a response, and who picks it up if the first line is unavailable.
- Operator instructions — what to do with a request assigned to a low-confidence category, how to mark a routing error so that it enters additional training.
- Model retraining procedure — how labels are accumulated and approved, on which example set a new version is tested, and how to return to the previous one if quality drops.
- Decision log and exports — by which attributes a ticket entered the queue, with what confidence, and exactly what was passed to the operator.
Such a kit removes dependence on one person: changes are made according to a document, not from memory, and handing support over to another team takes days rather than weeks of digging.
Case study: ticket distribution without manual sorting
Before the project, support worked across four inbound channels: email, a website form, chat, and a messenger. Everything flowed into a shared Zendesk inbox, and the first line handled sorting — manually reading, applying tags, and forwarding to the right department.
During peak hours the queue reached several hundred requests, and some of them went to the wrong assignee: the bounce back added another waiting cycle to each such case.
The bottleneck turned out to be not response speed but sorting. Operators spent more time labeling than on the actual handling, and time to first response depended on how quickly the on-duty operator could review the entire queue. Repeat requests grew: the customer did not wait for a response and wrote again in another channel.
What was changed
The model classifies the request text, determines the subject, language, and priority, then routes the ticket to the target queue and inserts a draft response for common scenarios.
Below the confidence threshold, the request does not go automatically but enters a short queue for manual review — this is a safeguard against misrouting.
Metrics before and after
- Auto-distribution rate: from zero to 87% of requests, manual labeling remained only for disputed cases.
- Time to first response: from several hours at peak to 30-40 minutes, including night shifts.
- Repeat requests: down by a third — the customer wrote again in another channel less often.
- Load on first-line operators: sorting ceased to be the main task, and the freed-up time went to complex requests.
Every model decision is logged together with attributes, and an operator's reassignment of a ticket goes into the labels for additional training — routing quality improves without rewriting rules manually.
How does rule-based sorting differ from a trained model?
Rule-based sorting is a set of conditions on ticket attributes: request channel, customer type, keywords in the subject, presence of an attachment.
Such a scheme gives complete predictability of distribution: you can always see which condition fired and why the ticket went to that particular queue.
The problem is that rules work only as long as the request language matches the template, and every new scenario requires manually editing the set of conditions.
A trained model looks at the entire text and the history of similar requests, not at word matches.
It distinguishes meaning where rules are powerless: "confirmation is not arriving" and "I can't log into my account" look similar to conditions, but the model separates them into different groups.
However, the model outputs a probability, not an unambiguous decision, so its answer always comes together with a confidence threshold.
It is the confidence threshold that makes the scheme work in practice. If the model is confident above the threshold, the ticket goes to the queue automatically; if below, it remains in the general flow for manual review.
Rules remain the framework for cases where the decision should not depend on an assessment at all: security-related requests, regulatory requirements, mandatory notifications. They cannot be handed over to probabilistic logic, even if it is almost always right.
This creates a division of responsibility zones: rules are responsible for predictability and compliance, the model for the quality of meaning-based distribution, and the operator for where confidence was insufficient.
In practice, both mechanisms are almost always combined into one scheme, because pure rules handle live language poorly, and a pure model provides no guarantees where ironclad scenarios are needed.
We verify this with metrics: the share of tickets handled without a human, the accuracy of assignment to the right queue, and the share of requests that went to manual review.
Technical concerns before starting work
Concerns before starting AI ticket routing are almost always the same: what the model does when it is unsure, who monitors quality after launch, and how to restore previous behavior. Below is how these areas are structured in the project, with no gray zones.
What if the model is unsure about the route?
A ticket below the confidence threshold does not go out at random — it is marked and enters manual review. The threshold is configured by request type, and firings are visible in the log.
Can rules be changed on the fly?
Yes. Hard conditions — customer, channel, subject, language — live in configuration, not inside the model, and are always enforced. An edit is released as a separate version and does not require retraining.
How much historical data is needed?
A few thousand labeled requests are enough to start; without labels, routes are reconstructed from correspondence logs. At small volume, rules matter more, and the model is additionally trained on the live flow.
How is routing quality checked?
We compare the model's output with a control sample labeled by your operators: the share of correct routes, the share of manual intercepts, and time to first response. A discrepancy above the threshold is a signal to retrain or roll back.
How are changes rolled back?
Rule and model versions are stored with date and author, so a rollback is a return to the previous version, not an emergency code fix. Previous behavior is restored in minutes, and the ticket flow does not stop.
Let's discuss the task and come back with a work plan
The first conversation is not a presentation but an analysis of your situation: where requests come from, how many there are and which types repeat, and who currently handles the inbound flow manually.
We need source data so that the scope estimate is based on facts, not guesswork: an export of requests for a period, a list of channels, current distribution rules, and what you consider a routing error.
As an output, we come back not with general words but with an implementation plan: stages, timelines for each, and the responsibility areas of your team and ours.
- We analyze channels: email, forms, chat, calls — where tickets are lost and which flow is handled manually.
- We review a sample of requests: which types repeat and by what attributes they can be separated automatically.
- We clarify the rules: who receives a ticket and by what attribute, what to do with ambiguous cases, and who makes the final decision.
- We record metrics: time to first response, the share of requests closed without an operator, and the number of transfers.
- We agree on access and restrictions: which systems we connect and which data cannot leave the environment.
- We estimate the scope of work: whether historical labeling is needed, how many scenarios we cover in the first stage, and what moves to the next.
- We define stage timelines, result checkpoints, and the procedure for rolling back to manual processing.
Describe the task as it looks on your side — we will come back with an estimate and work plan.
