Manual request routing breaks as the flow grows
While the flow is small, manual ticket distribution rests on a single dispatcher: they read emails in a shared inbox and route them to recipients.
There are no formalized routing rules of the kind mature support services arrive at under ITIL — there is a person and their attention, and attention bandwidth does not scale: at two or three hundred requests per day, the queue grows faster than it can be cleared, and time to first response is already measured in hours rather than minutes.
Then a second effect kicks in: the higher the processing speed, the more often a ticket goes to the wrong department.
The recipient forwards it to a colleague, it gets lost in the email thread or comes back with a clarifying question — and the client receives a response twice or does not receive one at all.
Lost requests are also almost invisible: a shared inbox has no status, owner, or due date, so there is no way to calculate the share of misses and present it in a review.
Peak support load breaks the structure completely. When the flow triples — a mass mailing, an outage, a seasonal spike — the dispatcher starts clearing the inbox in order of arrival rather than by priority: an urgent outage queues behind a question about an invoice.
Below, we look at how request routing is built on rules and a classification model, what is measured in it, and how to validate the solution on historical requests before implementation.
Classification, priorities, and response deadlines in one system
A request stops depending on who first opened the ticket tab.
Request classification determines the topic, client type, and urgency signals from text, attachments, and communication history; for ambiguous cases, the model returns a confidence score, and a rule decides whether to assign the label automatically or send the request for manual confirmation.
Ticket prioritization follows a single matrix: urgency × client type × contract status × past deadline breaches. The rules are described in configuration and can be edited without rebuilding the system — the dispatcher no longer keeps exceptions in their head.
Automatic request distribution takes into account department, specialization, and current workload, so a ticket does not get stuck with someone who is on vacation or sick leave.
Time to first response becomes a measurable value rather than a promise. Each priority has its own threshold; as it approaches, escalation triggers, and the report shows the share of requests closed on time and the queues where overdue items accumulate.
Deadlines are calculated by the department's working-hours calendar, not astronomical time — a nighttime ticket does not skew the statistics.
The system integrates into the current infrastructure: tickets are synchronized via API to Zendesk, Jira Service Management, or an internal database, and labels and priority are written to the same fields operators already use.
When confidence is low, the model's answer is rejected — the request goes to a human, and the decision enters the training set, so labeling quality grows along with the flow.
Request routing methods: rules, model, hybrid
The three schemes differ not in "intelligence" but in where the boundary between predictability and adaptation lies.
Routing rules produce a deterministic result: email subject, form field, selected product in the customer portal — and the request goes to a specific queue.
A classification model works differently: it learns from labeled historical requests and generalizes wording that never appeared in the rules.
How to choose a scheme for your request flow
| Option | When it fits | Limitations |
|---|---|---|
| Strict routing rules | Stable channels with signal fields: website form, template-subject emails, requests from the customer portal | Unfamiliar wording and non-template attachments are not labeled — manual review is needed; with frequent process changes, rules proliferate and begin to conflict |
| Trained classification model | Lots of free text: email threads, chats, unstructured emails; topics change and new wording appears | Requires labeled historical requests and a validation sample; makes mistakes on rare and mixed topics, needs retraining after process changes |
| Hybrid distribution scheme | Requests come from different channels, and some already carry explicit signals | Harder to maintain: requires rules to take precedence over the model and a transparent log explaining the final decision for each request |
In practice, the choice is rarely binary. We start with rules for everything already labeled by fields and connect the model where the text is unstructured — the share of automatically distributed requests grows without losing explainability. Below, we describe how such a hybrid scheme is assembled and how its accuracy is validated.
How we build a request distribution system: project stages
We start not with choosing a model but with auditing the request flow: we count channels, request types, points where tickets get stuck, and cases where operators make different decisions given the same inputs.
The output is a list of request classes and rules for separating them, fixed before the first line of code.
- Flow audit and task boundaries. We analyze sources, ticket history, and current sorting rules, and separately mark what does not need automation.
- Data labeling. We assemble a corpus with examples for each class and, separately, edge and rare cases where the classifier most often errs.
- Prototype and metrics. We measure quality on a holdout sample and set a confidence threshold below which a request goes to a human.
- Integration. We connect routing to intake channels and the system of record, and configure escalation and a decision log for each request.
- Shadow validation mode. The system labels the live flow in parallel with operators; we analyze discrepancies and refine the rules — clients do not notice this.
- System acceptance. We verify the result against agreed scenarios and metrics, check behavior when external services are unavailable, and review the rollback procedure.
- Handover of regulations. We provide rule documentation, retraining instructions, and the procedure for handling disputed cases.
After that, your team adds new request classes and edits the labeling itself — no need to rewrite the system for this.
System configuration, flow diagrams, and regulations
The checklist below is what physically remains with you after handover, not a presentation: configuration files, diagrams, reference data, and documents by which the system lives and changes without our involvement.
Everything is in editable formats, with a description of each block's purpose — your team's engineer can edit routing rules without looking into the source code.
- Request flow diagram — diagrams for each intake channel: branching points, data enrichment order, rules for merging requests from the same client, places where manual intervention is possible.
- Routing rules reference — a mapping table of topics, subtopics, and target departments plus confidence thresholds: at what level the model sends a request to a department, and at what level it hands it to an operator.
- Escalation regulation — timeouts by priority, handover procedure when an assignee is silent, on-call roles, criteria for marking a request as urgent.
- System decision log — for each request, the rule set version, recognized topic, selected department, and confidence are saved; export to a table for any period for reviewing disputed cases.
- Operator instructions — how to record incorrect routing, what to do with edge-case requests, where a disputed topic goes until the reference is updated.
- Access rules and roles — who sees request content, who edits the reference and thresholds, who exports the log; rule changes are written to a separate audit trail with author and date.
- Update procedure — how to add a new topic, re-read accumulated log data, and validate the result against past requests without breaking current routing.
A separate item is the rollback plan: a configuration checkpoint before every change and return to the previous rule set in one operation. This is what lets you change the routing scheme independently and avoid coordinating every reference edit with us.
Case study: how lost requests were eliminated in the support queue
The client is a service company with distributed support: requests from email, chat, and telephony landed in a shared queue in Zendesk and waited for a dispatcher, who routed them across eleven departments.
During peak hours, triage took up to forty minutes, and every fifth request went to the wrong department — it was returned and queued again, with time already lost.
Before development, we labeled the history of closed requests and linked the text to the executing department: email subject, customer wording, attachments, source, contract type.
The route is built by a combination — rules for unambiguous cases and a model for the rest; when confidence is below the threshold, the request goes to a manual review group with a flag, not "nowhere".
Metrics before and after
| What we measure | Before | After |
|---|---|---|
| Requests sent to the wrong department | 21% | 4% |
| Share of automatic routes without a dispatcher | 0% | 86% |
| Time to reach the right department | up to 40 minutes | 20–40 seconds |
| Returns for redistribution per shift | 34 | 6 |
The key here is not the model's accuracy by itself but the observability of the route. Every decision gets an explanation: which signals determined it and which rule branch fired.
The dispatcher overrides the department in one click, the correction goes into the training set — the share of automatic decisions grows without rewriting the logic.
Disputed cases are visible immediately, manual review accounts for a few percent of the flow, and dispatcher turnover is no longer a bottleneck: the freed-up time went into response quality rather than shuffling tickets between departments.
What to do if the rules are configured but do not work
Rules look at signals that are easy to extract but weakly related to meaning: email subject, sender address, keyword-list matches. For template tickets this is enough; for live text it is not: the essence is often stated in the third paragraph or in an attachment.
Then the set of conditions grows, and each new exception covers one case while breaking two neighboring ones — rules fail to fire or fire in a different order than the author expected.
The first step is not to add more rules but to capture the decision log: for each request, you can see which conditions matched, in what order, and where a later one won.
The error metric is the share of requests that went to a department and came back via forwarding or were handled manually contrary to the route. If this share stays above a few percent, the problem is not individual rules but the distribution scheme itself.
Next, compare rules and the model on the same historical sample: run both options and look at accuracy for each class separately. Rules predictably win on rigidly formalized flows — standard partner tickets, documents with a fixed structure.
The model is stronger on free text, email threads, and mixed requests where a human has not fully determined the topic themselves.
Model retraining does not start from scratch but uses confirmed decisions: we label history the way operators actually distributed requests and train on these pairs.
Where confidence is below the threshold, the request goes to manual review, and the operator's decision becomes a new example for the next cycle. This way the model covers rare topics but does not invent a route where there is little data.
The work is completed by rebuilding routes: instead of spot fixes, the scheme is reassembled from a registry — department, topic, condition, priority, conflict action.
The set of conditions shrinks severalfold because part of the logic moves into the model, while rules remain a safeguard for critical flows. Before rollout, the new route is run on a labeled sample, and the difference from current behavior is visible in numbers, not feelings.
Technical concerns before launching the system
Concerns before launch are usually the same: whether labeling quality will be sufficient, who is responsible for an error, what to do with non-standard attachments, and how to notice degradation.
We run the pilot in shadow mode on an export of closed requests — the router does not affect the flow, and its decisions are compared with actual transfers to departments.
How do you ensure labeling accuracy?
We build the training corpus from closed requests where the executing department is known from history: the label is confirmed by fact, not by a labeler's opinion. Requests with transfers between departments and disputed closures go to manual review or are filtered out.
Will a human remain in the decision loop?
The model makes a decision only above the confidence threshold. Below the threshold, the request goes to an operator along with the three likely departments and the signals the model relied on. The operator's correction is written to the log and enters the next retraining cycle.
What to do with non-standard attachments and voice messages?
We extract text from documents directly, recognize scans, transcribe voice messages while preserving the original file. If text cannot be extracted, the request is not discarded or routed at random — it is queued for manual review.
How is model quality monitored after launch?
A reference set of requests is run on a schedule; accuracy and the share of manual corrections are included in the report.
If a metric falls below the agreed threshold, it triggers an alert and a rollback to the previous router version — without investigating the incident from scratch.
Let's discuss your task and come back with a plan
To come back with a project estimate rather than general thoughts, a minimal set of inputs is enough for us. These are exactly what determine how routing will be structured — by formal rules, by request meaning, or a combination of both — and where manual review will be needed.
- an export of requests for several months: channel, text, subject, actual recipient department, time to first response;
- a list of departments and distribution rules, including informal agreements such as "such requests always go to support";
- disputed cases: everything that reaches the wrong department or is forwarded manually;
- data constraints — where it is stored, who has access, what must not leave your environment;
- your success criteria: share of correct routing, response time, share of manual transfers;
- an employee who will confirm the rules and accept the pilot result.
This is enough to analyze your request flow and come back with an implementation plan: stages, what we validate in the routing pilot, which metrics we calculate, and what is required from your side at each step.
We launch the pilot on historical data — accuracy and bottlenecks are visible before the system goes into the production environment. Describe your task — we will come back with an estimate and a plan.
