Peak load: where the AI ticket dispatcher breaks
While the request flow is steady, manual dispatching looks workable: the shift supervisor reviews the queue and assigns tickets to executors — by service type, region, and current workload.
The scheme relies on the attention of a specific person, and this is its main limitation: attention does not scale with the flow.
Peak load breaks distribution first. The request queue grows nonlinearly: each new request waits longer for triage, and triage is based on an outdated workload picture — by the time sorting is done, available executors are already busy with other tasks. A mode emerges in which the dispatcher chases the flow instead of managing it.
The second bottleneck is lost tickets. A request forwarded to a chat or an executor's personal email loses its owner: after a few hours, no one can say whether it has been taken into work.
Duplicates and repeat requests from the same client worsen the picture — they are not linked to the original ticket and live as parallel branches.
Response times stretch in a cascade. The regulatory deadline is counted from when the ticket is queued, not from the actual start of work, so the ticket is formally "on track" while the client is already waiting for a response.
We examine exactly where control is lost at peak and how this is closed on the AI dispatcher side — from queue prioritization to response-time control for each ticket.
What automatic dispatching delivers: the effect in metrics
Automatic routing removes manual triage of the incoming flow: a request receives attributes — topic, channel, client history, priority — and goes to a specialized executor according to rules.
Response time for a request no longer depends on who is free and attentive at that minute. Events from channels, including Zendesk and messengers, are collected into a single field of decisions, rather than spreading across other people's windows.
Response time to a request
Distribution rules work around the clock and do not "hang" at peaks: a request reaches an executor with the right qualifications immediately, without intermediate sorting.
In projects, response time is reduced severalfold — typical requests are closed in the first minutes, escalation triggers by timer, not by the duty officer's memory. The share of missed tickets drops to a level explained only by external communication channel failures.
Operator workload
The dispatcher sees whose queue is growing and who has spare capacity, and redistributes the flow before a jam appears.
Operator workload levels out: peak hours no longer require keeping a shift "just in case." This eliminates the class of failures "ticket got lost between shifts" — not because people became more attentive, but because the place where it could get lost has disappeared.
The effect is verifiable before implementation: we run the request history through the routing rules and see how deadlines and workload distribution change.
"When we removed manual sorting, the queue stopped being a bottleneck: operators work on substantive requests rather than shuffling tickets." — engineer, led the dispatching project.
Routing options: rules, queues, trainable model
The dispatcher solves two tasks: whom to address a request to and in what order to take it into work. There are three mechanisms — hard routing rules, request queues with ticket priorities, and a trainable model based on history.
The choice among them depends on the stability of request categories and the volume of accumulated data.
| Approach | When it fits | Limitations |
|---|---|---|
| Rules and priorities | A stable set of typical tickets, explainability of each decision is needed | A new request type requires manual rule changes |
| Request queues | Uneven flow, response times differ by client segment | Top priorities blur lower ones, some tickets wait longer |
| Trainable model | There is a history of "request — executor — result" pairs | Errors on rare classes, deviation analysis is needed |
| Hybrid scheme | Rules set the framework, the model ranks within them | Requires observability: decision logs and model retraining |
Hard rules and priorities
Rules describe unambiguous conditions: request type, channel, contractual service level. Ticket priority is set by a weight table, and the request queue is built by weight and waiting time.
The decision is reproducible: it is visible why a request went to a specific executor, and this can be presented when reviewing disputed cases.
Trainable model and hybrid
The model learns from history: who closed similar requests, in what time, and with what result, and selects an executor based on actual performance.
The hybrid scheme leaves prohibitions and mandatory routes to the rules, while handing disputed cases to the model — predictability is preserved, and distribution becomes more accurate.
Implementing the AI dispatcher: stages of engineering work
Implementing the dispatcher is primarily a rebuild of request distribution rules, and only then code. We start with the current flow, agree on the rules, and only then connect systems. Below are six stages of this work.
Routing scheme
Routing is described by an explicit set of rules: request type, priority, required executor qualification, response deadline at each service level. We agree on the rules with you before development — afterward they are changed in settings, without code modifications.
- Process audit — we collect channels, ticket types, shares of urgent ones; we note where requests wait and where they get lost.
- Routing scheme — we fix distribution rules, escalation, and service levels in an agreed document.
- Integration setup — we connect the record system, email, messengers, and telephony through standard exchange interfaces.
- Model calibration — we run the dispatcher's decisions on historical requests and compare them with how your specialists made them.
- Acceptance checks — we test on a live flow according to pre-agreed scenarios and criteria.
- Handover to operation — we train your shift, provide documentation on the rules and the regulation for changing them.
Acceptance checks on a real flow
We check not on a test sample but on live requests: we compare the dispatcher's routes with your specialists' decisions, calculate the match rate and response time for each level. The work is accepted when the metrics remain stable and it is clear how to roll back any rule.
What the customer keeps: configurations, schemes, regulations
We hand over the system not as a black box: together with the working dispatcher, the customer receives a set of artifacts that the team can use to operate the solution, change rules, and connect new channels without us.
- Integration scheme — which systems are connected, where the exchange takes place, failure points, and behavior when an external service is unavailable.
- Dispatcher configurations — routing rules, priorities, trigger thresholds, and request scenarios as version-controlled files.
- Access policies — roles, permission matrix, procedure for granting and revoking access, action log.
- Escalation regulation — levels, timers, conditions for handing a ticket to a human, rules for notifying the manager.
- Operator instructions — what a specialist sees on screen, how they handle disputed tickets, and how they correct the model's decision.
- Documentation — architecture, data dictionary, procedure for updating models, and rollback to the previous version.
- Metrics and reporting — which indicators are captured and where to view the target response speed and the share of tickets closed without an operator.
Escalation regulation and operator roles
Here we fix not only timers but also responsibility: who takes the ticket when automation fails, who confirms a non-standard decision, who is notified when the target response time is violated.
The operator sees the model's confidence and the reason it made a decision — a disputed case is resolved in seconds rather than turning into another query to the client.
Case study: how the share of missed requests was reduced
A service company with a distributed team of engineers received requests by email, phone, and via Zendesk.
A dispatcher manually triaged the queue and assigned an executor: during quiet hours the scheme worked, but at peaks — Monday morning, days after launching new services — the queue grew faster than it could be triaged.
Starting point
For two weeks in a row, we captured metrics: the share of missed requests held at 17%, average first response time was about four hours, and during peak hours it reached nine.
Every ninth ticket was escalated manually and with a delay, regulatory deadlines were violated two to three times a week — and almost always for high-priority tickets that got lost in the general queue.
What was changed and what resulted
The dispatcher distributes tickets by competencies, current workload, and priority; the queue is recalculated every few minutes rather than at the start of a shift.
Topic and urgency are determined from the request text, disputed cases go to an operator for confirmation, and escalation starts before the deadline, not after.
Missed requests — 2.8%, first response time — 22 minutes, during peak hours — up to 50 minutes, 94% of tickets are closed on time. "Previously, Monday morning began with triaging the queue and explanations of why we didn't manage.
Now I see the workload and the forecast for the day, and escalations trigger before the client writes a second time," — head of the service department.
What to do if some requests are already distributed manually?
Embedding the dispatcher on top of an existing request system is a standard scenario; there is no need to replace it entirely.
The dispatcher connects to the queue as another participant: it reads new tickets, determines type, priority, and executor, and returns the decision to the same place where operators are already used to working.
This works both on top of ServiceNow and on top of a custom-built queue — the only difference is the connection method.
The method is determined by what the current system provides: an event stream or only read access to the database.
| Option | When it fits | Limitations |
|---|---|---|
| Subscription to queue events | The system can notify about new tickets and status changes | Subscription permissions and a stable channel are needed |
| Periodic ticket polling | Closed environment, no events | Delay until the next cycle, extra load on the database |
| Buffer between the system and the dispatcher | Multiple sources: email, chat, phone | A component appears that needs to be maintained |
| Hybrid mode with suggestions | Autonomous routing is prohibited by regulation | Speed remains with the human |
We make the transition in stages. The first contour is shadow mode: the dispatcher proposes a route, the operator makes the decision, and we analyze discrepancies and refine the rules. The share of automatic decisions grows to an agreed threshold — usually within a few weeks.
Then comes support: we monitor the share of routes without human involvement, the time to ticket acceptance, and the analysis of disputed cases.
"Manual sorting relied on one specialist. Now night tickets go to the duty officer on their own, and in the morning it is visible where the rules did not work." — head of client support service.
Common technical doubts before launch
Before launch, the dispatcher runs into the same doubts: whether there is enough data, what to do with a non-standard request, and how to maintain quality after going live. Below are short answers without promises that "everything will work by itself."
We don't have clean data — where to start?
Data quality matters more than volume. We collect the request history from email, ticket logs, and call recordings, and bring it to a unified schema: type, priority, department, actual resolution time. Free text is labeled and normalized — the result is a sample on which routing rules are tested.
How will the system handle an atypical request?
We do not force non-standard cases into a template. Below the confidence threshold, the request goes to a human along with context: history, attachments, preliminary classification.
The dispatcher relieves the flow but does not replace a specialist where a decision with authority is needed.
What about false positives?
They are constrained by priority rules: critical actions — only with operator confirmation, automatic closure — after verification against independent signs. We analyze each case with its cause, so thresholds are tuned to your flow, not to averaged data.
Who monitors quality after launch?
Quality control is ongoing: we analyze a sample of decisions, compare against the SLA, and look at the share of automatic closures, escalations, and returns. Discrepancies become tasks for fine-tuning rules — updates happen without stopping the service.
Won't training on history reinforce old mistakes?
Retraining is done on confirmed closed requests, not on the entire array indiscriminately. Disputed and erroneous decisions do not enter the sample.
History is stored separately, so any version of the rules can be compared with the previous one and a change can be rolled back selectively.
Let's discuss the task and come back with an estimate and plan
To come back with an estimate and work plan, we don't need a hundred-page document — a working statement of the task is enough. Below are five blocks of input data that remove almost all questions about the AI dispatcher; we clarify the rest in a conversation.
- Process description. Which tickets arrive, through which channels — email, messengers, phone, website form — and by what rules an executor is currently selected.
- Data for setup. An export of tickets for several months, assignment history, SLA overdue cases, typical operator responses. These are used to build routing rules and verify decision quality.
- SLA rules and priorities. Response deadline for each request type, what we consider a violation, to whom and at which step escalation goes.
- Access. A test environment of the ticketing system, a separate account with limited rights, connections to intake channels and the executor directory.
- Responsible people on your side. Who approves the routing logic, who accepts the result at acceptance, and who analyzes disputed cases after launch.
- Constraints and timelines. Personal data processing rules, correspondence retention periods, requirements for logging dispatcher actions, desired launch date on the real flow.
Gather what you have at hand — even a partial set already allows us to name the stages, timelines, and control points. Describe the task, and we will come back with a work plan and estimate.