A customer writes in about an unexpected charge. The message lands in a general queue, where an agent reads it, decides it is a billing question and moves it to the billing team. Billing sees that the charge relates to a plan change made by the customer’s account manager and passes it to account management. Account management notices a technical error in how the plan was applied and sends it to technical support. Three assignments later, the ticket reaches someone who can fix it, and the customer has been waiting for two days.
Nobody in that chain did anything wrong. Each person made a reasonable decision with the information they had. The problem is structural: the routing depended on each person reading the ticket and guessing where it belonged next. This guide describes a practical approach to designing triage so that first assignments are right far more often.
Measure how tickets actually move
Before changing any rules, find out how much re-routing is happening and where. Most help desk platforms record assignment history, even if it is not shown in standard reports. Export a sample of recently resolved tickets and count how many assignments each one had before resolution. Then look at the paths: which queues most often pass tickets to which other queues.
This usually reveals a small number of recurring patterns. Perhaps a large share of tickets marked as “technical” are actually account access problems. Perhaps billing receives many tickets that are really about contract terms. These patterns tell you where the routing logic is weakest and which categories need clearer definitions.
- Share of tickets resolved on the first assignment.
- Average number of reassignments per ticket, broken down by initial queue.
- The most common queue-to-queue transfers.
- Time spent waiting in queues before the final assignment.
Define categories by who resolves them
Many ticket categories are defined by topic: billing, technical, account, general. Topics are intuitive for customers, but they do not always map to who can resolve the issue. A question about an invoice might be handled by billing if it is about payment, by account management if it is about pricing, or by technical support if the invoice was generated incorrectly.
A more reliable approach is to define categories by the team or skill needed to resolve them, and then describe the signals that indicate each category. For each resolving team, write down the kinds of issues they own, the information they need to start working, and examples of tickets that look similar but belong elsewhere. This document becomes the foundation for both automated rules and agent training.
Routing works best when categories describe who can fix the problem, not what the customer thinks the problem is about.
Capture the right information at intake
Many routing errors happen because the ticket arrives without the information needed to classify it. A free-text email saying “my account isn’t working” could mean a login problem, a suspended subscription or a bug. The more structured information you gather at the point of contact, the easier routing becomes.
This does not mean forcing customers through long forms. A few well-chosen questions, such as which product area the issue relates to and whether it involves a charge, can be enough. Just as useful is data the customer does not need to provide: if the ticket comes from a known contact, the system can look up their plan, their account manager, their recent orders and any open incidents affecting their region. Linking the help desk to the CRM and billing system for this purpose often improves routing more than any change to the rules themselves.
Combine rules with classification
Once categories and intake data are clear, routing can be automated in layers. The first layer uses explicit rules based on structured data: tickets from enterprise accounts go to their dedicated team, tickets that mention an order number and a refund go to billing, tickets submitted through the in-app bug reporter go to technical support. These rules are transparent, predictable and easy to adjust.
The second layer handles tickets that the rules cannot place with confidence, usually free-text messages without clear signals. Here, a language model or text classifier trained on past tickets can suggest a category and a confidence level. When confidence is high, the ticket is routed automatically. When it is low, the ticket goes to a small triage group whose job is to classify quickly, and whose decisions are recorded so the classifier and rules can be improved.
- Apply deterministic rules first, where structured data makes the answer clear.
- Use classification only for the remaining ambiguous tickets.
- Route low-confidence cases to people rather than guessing.
- Record every correction so the rules and models can learn from it.
It helps to keep the reason for every routing decision visible to agents. If a ticket was sent to billing because it mentioned a refund, the agent can see that immediately and, if it was wrong, understand why. Opaque routing that agents cannot explain tends to erode trust quickly.
Close the loop with reassignment data
Routing is never finished. Products change, new issue types appear and teams reorganize. The most useful ongoing signal is the reassignment itself. Every time an agent moves a ticket to another queue, that is a small piece of evidence that the routing could be better. Asking agents to choose a short reason when they reassign, such as “wrong category” or “needs account access,” turns these moves into data.
Review this data on a regular schedule, perhaps monthly. Look for the transfers that happen most often and ask whether a rule change, an intake question or a clearer category definition would prevent them. Over time, the share of tickets resolved on first assignment should rise, and the triage group’s workload should shrink.
Where to start
Export three months of resolved tickets and calculate the first-assignment resolution rate and the most common transfers. Rewrite your categories around the teams that resolve each type of issue, with examples of what belongs where. Identify two or three data points you could pull automatically from the CRM or billing system at intake. Then introduce a small number of explicit rules for the clearest cases, and send everything else through a triage step until you have enough data to automate further.
Even modest improvements matter. If a team handles 3,000 tickets a month and reduces reassignments by a few hundred, the saving is not only agent time but also days of customer waiting that no longer happen.