Zendesk Predictive Routing: built on evidence, not assumptions

1. Your routing logic was written for a team that no longer exists

Modern customer service operations run on routing logic built from human assumptions: which agents handle billing, which handle technical issues, which queues take priority. Admins encode these assumptions as rules — groups, skills, tags, priorities — and then regularly spend ongoing time maintaining them as teams grow, products change, and ticket patterns shift.

The fundamental weakness of this approach is not that the rules are wrong. It is that they are static in a dynamic environment. A rule that reflected reality six months ago may no longer be accurate today. New agents join and develop expertise. Veteran agents change roles. Seasonal ticket patterns emerge. None of these changes are captured automatically.

There is also a second, subtler problem: rules operate on categories, not on evidence. Assigning a ticket to the "billing team" because it contains the word "invoice" says nothing about which individual within that team is most likely to resolve it efficiently. The decision is made on taxonomy, not on measured performance.

Predictive Routing addresses both problems. It allows static rules to be replaced with a model trained on actual historical performance data, and it makes assignment decisions at the level of individual agents rather than groups. The optimisation adapts automatically as new data arrives — operating on top of, not instead of, the routing constraints admins configure in Zendesk.

Where a rule-based system asks an admin to encode their assumptions about which agents handle which tickets, Zendesk's model asks a different question: what does the data actually show? Every prediction is built from real observed performance — not categories, not tags, not guesses. The team that existed when your rules were written and the team that exists today are not the same team. Predictive Routing knows the difference.

Every prediction is built from real observed performance — not categories, not tags, not guesses. 

2. One question, answered for every agent on every ticket

When a ticket arrives, every eligible agent receives a score. The score answers a single question:

"How long would it take for this agent to finish handling this ticket?"

A lower predicted time indicates a better match. The routing policy then uses those scores to select the agent with the best overall match from among those who have available capacity.

This formulation has a few important consequences worth calling out explicitly.

The target is agent engagement time, not total resolution time. Total resolution time includes periods when the customer has not yet replied — time that is entirely outside any agent's control and introduces significant noise into any model. Agent engagement time is defined as the sum of only the intervals during which the agent was actively engaging with the customer in a conversation. User reply gaps are excluded. This makes the metric a genuine signal of agent effort and efficiency.

The model learns from outcomes, not from rules. No admin needs to tag an agent as skilled in a particular area. The model observes which agents consistently resolve which types of tickets faster than average and adjusts its predictions accordingly.

3. What the model predicts

Before describing the model architecture, it is worth being precise about the prediction target, because several intuitive alternatives were evaluated and rejected.

3.1 Agent Engagement Time

The model predicts agent engagement time: the total duration of agent-active intervals within a conversation, from first agent response to conversation close, illustrated in Figure 2.

4. How the model makes a prediction

The model takes three types of input: a representation of the incoming ticket, a representation of each eligible agent, and a representation of the account as a whole.

Zendesk Predictive Routing is underpinned by a cross-account model trained on cross-industry interaction data from millions of real agent-customer interactions. This means it works from day one — even for accounts with no prior history in the system. There is no external data ingestion project, no CRM data quality dependency, and no integration work required. A new customer can enable Predictive Routing on their first ticket. Predictions improve continuously as account-specific data accumulates, but the system is never in a state where it cannot operate. This is a meaningful contrast to approaches that require significant historical data preparation or third-party integration before the model becomes useful.

4.1 Ticket representation: Intents

Tickets are represented using Zendesk Intents — a hierarchical topic classifier built into the Zendesk platform. Intents are structured across three levels of granularity:

• Level 1: billing

• Level 2: billing__refund

• Level 3: billing__refund__credit_card

The model operates on a granular, hierarchical intent taxonomy that has been calibrated to balance specificity with statistical reliability — detailed enough to distinguish meaningfully different ticket types, while ensuring each category accumulates sufficient data for stable agent performance estimates.

Crucially, a single ticket is rarely 100% one intent. A message reading "My credit card was charged twice and I can't log in" might score 0.7 for billing and 0.3 for tech_support. The model works with this full probability distribution — a vector of intent scores — rather than a single hard classification.

4.2 Agent representation: rolling performance statistics

For each intent, the model maintains statistics on each agent's historical performance: mean agent engagement time, ticket volume, and related measures. Both a short-term window and a long-term window are maintained, allowing the model to distinguish between an agent's established baseline and their recent trajectory. This is useful in practice: a newly trained agent, for example, may show rapid recent improvement that the long-term window alone would underweight.

4.3 Account representation

Statistics are aggregated at the account level, giving the model a baseline for the tenant as a whole. This serves two purposes: it provides context for interpreting individual agent statistics (a 4-minute engagement time means something different at a fast-moving e-commerce company than at an enterprise B2B operation), and it enables the model to generalise patterns across agents — including for agents who are new and have limited individual history.

4.4 A Worked Example

Before the full model runs, a linear estimate — combining agent statistics across intents with the ticket's intent mixture — is used to generate a preliminary predicted engagement time per agent. This encodes the following idea: given how fast this agent is at each topic, and given this ticket's topic mix, what is a reasonable estimate of how long they will take?

Suppose a ticket has the following intent scores:

And two agents have the following historical engagement times per intent:

The linear estimate for each agent is calculated by weighting their per-intent performance by how strongly each intent is present in the ticket:

Agent A: (0.7 × 4) + (0.0 × 10) + (0.3 × 6) = 2.8 + 0 + 1.8 = 4.6 min

Agent B: (0.7 × 8) + (0.0 × 5) + (0.3 × 7) = 5.6 + 0 + 2.1 = 7.7 min

Because this ticket is predominantly about billing, and Agent A has a consistently faster historical engagement time for billing-related conversations, Agent A receives a lower predicted engagement time overall. Agent B is faster at shipping — but since this ticket has no shipping component, that strength carries no weight here. The more heavily a ticket skews toward a particular topic, the more that topic's per-agent performance drives the prediction. An agent who excels at the dominant topic of an incoming ticket will consistently score well — regardless of their performance on topics the ticket does not involve.

This preliminary estimate is intuitive and interpretable. It is also deliberately simple — it treats all intent dimensions as independent and assumes performance combines linearly. The full model, described in Section 4.5, learns the corrections that this simplification cannot capture.

This approach to ticket representation is a meaningful architectural choice. Rather than routing on raw text or relying on a black-box embedding, Zendesk maps every ticket to a structured, human-readable intent taxonomy before any prediction is made. This means routing decisions are grounded in topic categories that admins and operations leaders can understand and audit — not in opaque numerical representations. It also means the model is structurally blind to demographic or linguistic features of the customer's message: the input to the routing decision is what the ticket is about, not how it was written or who wrote it.

4.5 The Model

The linear estimate is not the final output. It is one input feature — alongside the raw intent vector, account-level statistics, and both short and long-term performance windows — fed into the model: a gradient-boosted decision tree, a well-established and highly effective approach for tabular machine learning tasks.

This is where the model earns its value beyond simple averages. The model learns corrections that the linear estimate cannot capture, for example:

• Agents who are fast at billing tend to be disproportionately fast at billing + tech_support combined — more so than the linear combination would predict

• During periods of high account-wide ticket volume, slower agents become relatively slower still

The output of the model is a single number: the predicted agent engagement time in seconds for this agent on this ticket.

The model is trained on cross-industry data from millions of real agent-customer interactions, which means it generalises across account types and ticket patterns without requiring custom model training or data preparation for each new deployment. Every resolved ticket makes the next prediction marginally more accurate — continuously, and without any admin intervention.

5. Being the Fastest at One Ticket Is Not Enough. Here Is What Actually Wins the Assignment.

The model produces a score for every eligible agent. A routing policy then determines how those scores are used to select an agent.

Predictive Routing uses a Workpile policy. Rather than simply selecting the agent with the lowest predicted engagement time for the incoming ticket alone, the policy assigns the ticket to the agent whose total current workpile — ongoing tickets plus the new ticket — has the lowest total predicted completion time.

This naturally distributes load: even if Agent A would handle this particular ticket fastest, if Agent A is already working through several open tickets, their total time-to-clear may exceed Agent B's — and Agent B receives the assignment.

This is by design. The Workpile policy makes load distribution a mathematical property of the routing decision itself — not a guardrail applied on top of it. Most routing systems address agent overload through manual capacity caps or by claiming their model "balances" load without explaining the mechanism. Zendesk's Workpile policy does not need a separate fairness layer because fairness is embedded in how the assignment decision is made.

6. The concern everyone raises, answered with data

The most common concern raised by operations teams evaluating Predictive Routing is intuitive: "If the fastest agents always get the tickets, won't they burn out while others sit idle?"

This concern is addressed at multiple levels — and, most importantly, tested empirically rather than assumed away.

Existing capacity constraints apply first. Before the model runs, Zendesk's Omnichannel Routing (OCR) filters the eligible agent pool based on capacity, skills, availability status, and group membership. An agent who has reached their maximum concurrent ticket capacity is never scored. Predictive Routing does not override existing operational guardrails — it operates within them.

The Workpile policy distributes load by design. The routing policy considers each agent's full current workpile when making assignments, not just their predicted performance on the incoming ticket. An agent with a heavy current load will rarely be selected even if they are the fastest at that ticket type.

Empirical validation is the most important protection. Production A/B tests (described in Section 7) explicitly measured workload distribution across agents as a success criterion. Across deployments, workload distribution across the team remained consistent with pre-deployment baselines. Individual agent allocations may shift as the model matches agents to their areas of strength — this is expected and by design — but the data does not show agents being systematically overloaded as a result. The feature is live and we continue to monitor this as adoption grows.

The efficiency gains came from better matching, not from concentration of work. Agents resolved their tickets faster — the same team handled the same volume with less total effort, not by redistributing that effort onto fewer people.

Zendesk's model is also trained on PII-redacted data, and all ticket text is mapped to a fixed intent taxonomy before any routing decision is made. This means the model is structurally blind to customer demographics — routing is based purely on topic and agent performance, not on who the customer is.

7. We did not take our own word for it. Here is how we tested it.

Most AI routing evidence takes the form of case studies: a customer switched to a new system, and performance improved. That is not a rigorous test. Customer volumes change, seasonality shifts, agents develop skills, problem types evolve. A before-and-after comparison cannot separate the routing effect from any of those factors. Zendesk's validation programme is built on randomised A/B tests — the same methodological standard used in clinical research and academic science. Here is exactly how each test was designed and what the results showed.

7.1 Offline simulation

Before committing to a live A/B test, the central question is: "If this model had been used historically, would it have produced better outcomes?"

Since it is not possible to re-run history, a simulation is run by replaying historical ticket data under the new predictive routing policy.

The key methodological principle is to minimise reliance on predictions. The simulation uses real observed engagement times wherever possible:

• If the new policy would have assigned a ticket to the same agent as history did, the real observed engagement time is used

• If the new policy would have selected a different agent, the model's prediction is substituted — acknowledged as an estimate

• User reply times are always kept identical to history

Simulation gains are typically a ceiling estimate, as the simulation cannot account for agent fatigue, shifts in ticket patterns, or capacity changes under the new policy. Offline simulation serves as a directional filter to identify accounts likely to benefit from live testing, rather than a precise forecast of production gains. Under this framework, simulations for several accounts indicated that gains of up to around 20% faster agent engagement time would be possible.

7.2 A/B test design

Six enterprise customers participated in randomised A/B tests, with data collection windows spanning one to six weeks per deployment.

A/A testing was conducted first: the same routing treatment was applied to both groups with no model active. This confirmed that the two groups were statistically comparable before the experiment began — equivalent in ticket volume, topic distribution, and time metrics. All six validation checks passed cleanly, providing a sound baseline for interpreting subsequent treatment results.

Success criteria were defined in advance across four dimensions:

1. Agent engagement time — the primary metric

2. Total conversation time — including customer reply time

3. Workload distribution — to test the agent overburdening concern

4. CSAT — as a quality guardrail, whenever sufficient customer feedback data was available

7.3 A/B test results

Results are reported over a stable window of each deployment, following an initial ramp-up period during which the model adjusts to live traffic. Gains measured before that stabilisation point underrepresent the system's true operating performance and are excluded from the primary figures below.

\In four of six deployments, Predictive Routing produced statistically significant reductions in agent engagement time, ranging from 9.4% to 21%. Total conversation time — which includes periods outside the agent's control — followed in the same direction across all four, confirming that the engagement time gains translated into a materially faster experience for customers as well.

The scale of operational impact varies with team size and ticket volume. Customer A, with 55 agents handling approximately 2,000 tickets per week, recovered an estimated 98 hours of agent time per week — equivalent to more than two full-time agents' weekly capacity — without any change in headcount, process, or agent behaviour. Customers C and D, both handling over 4,000 tickets per week, recovered 65 and 70 hours per week respectively, illustrating how even single-digit percentage gains compound significantly at high ticket volumes. Customer B recovered approximately 12 hours per week — a more modest absolute figure that nonetheless represents a consistent, measurable efficiency improvement.

Two deployments — Customers E and F — showed no statistically significant difference in agent engagement time. These results are reported in full rather than excluded, because honest reporting of variance is essential to understanding where the system adds value and where operating conditions do not yet create the space for optimisation.

The specific reasons matter and are instructive:

• Customer E: Deeper analysis showed high uniformity of ticket topics — more than 70% of tickets had identical intent, with other topics sparsely distributed at low volume. With no meaningful topic diversity for the model to exploit, there was no optimisation space

• Customer F: Analysis showed that 91% of the time there was only a single eligible agent available for matching at the moment of ticket arrival. When routing cannot choose between agents, Predictive Routing has no opportunity to improve on the assignment — leaving no space for optimisation

This tells a clear story about where Predictive Routing is designed to add value: operations with genuine agent diversity, sufficient ticket volume to generate reliable performance signal, and routing complexity that goes beyond single-agent availability. The model does not improve what cannot be improved. Publishing this analysis — including the conditions under which the system does not produce significant gains — reflects a commitment to evidence-based transparency that allows organisations to assess whether their own operational profile is a good fit before deploying.

8. The online system

At runtime, the system operates as follows:

When a ticket arrives:

1. The ticket enters an eligible pool

2. Existing routing constraints — including agent capacity, skills, availability, and group membership — are applied first, producing the eligible agent pool for that ticket

3. The AI model scores each eligible agent against the incoming ticket

4. The Workpile policy evaluates each agent's total current workpile — ongoing tickets plus the new ticket — and assigns to the agent with the lowest total predicted completion time

This process adds no perceptible latency to routing decisions.

After a conversation closes:

1. Real agent engagement time is observed and used to continuously update the model

2. Recent tickets are weighted more heavily than older ones, reflecting the agent's current performance trajectory

3. Updated agent and account statistics are written to cache for future scoring

The scoring step is on the critical path and is designed to be fast: the model is lightweight and agent statistics are pre-cached rather than computed at request time. The statistics update step happens asynchronously after conversation close and does not affect routing latency.

This design means the system is continuously learning — every resolved ticket makes the next prediction marginally more accurate — without that learning process introducing latency into live routing decisions. The model improves automatically as it accumulates data, with no admin configuration, retraining trigger, or integration work required.

9. Conclusion: routing intelligence built on evidence

Predictive Routing represents a fundamental shift in how ticket assignment decisions are made: from human-authored rules based on assumptions, to a model trained on observed outcomes that adapts continuously over time.

The core technical insight is that predicting agent engagement time per ticket — measured precisely as active intervals only, excluding customer reply gaps — is a tractable, measurable, and high-signal objective. It is directly attributable to the routing decision, can be optimised without compromising workload fairness or customer experience, and is validated against a rigorous standard that the industry rarely applies to its own claims.

Across six enterprise deployments, four produced statistically significant reductions in agent engagement time of between 9.4% and 21%, with no statistically significant change in workload distribution and no degradation in customer satisfaction where data was available. Two deployments produced no significant effect — and the reasons are documented, specific, and instructive for any organisation evaluating whether their own operating conditions are a good fit.

At scale, the gains that do materialise translate to tens of hours of agent time recovered per week — capacity that can be redirected to higher-complexity interactions, reduced staffing pressure, or improved service levels. Not from headcount changes, not from process redesign, not from pushing agents harder. From getting the matching decision right more often.

Zendesk is one of very few vendors in this space that publishes its full validation methodology, including the deployments that showed no significant effect and the operating conditions that explain why. That is not a minor documentation choice. It is a fundamentally different standard of accountability — and the only basis on which an enterprise buyer can make an informed decision about which routing system to trust with their operation.

The system is live for Messaging on Enterprise plans. Support ticket routing is planned for later in 2026, with Voice planned for early 2027.