Predictive best-agent routing

The model answers a narrow question. Given this ticket and this agent, how likely is a clean resolution without a transfer or a reopen. It produces a number per candidate agent. That number is about the pair, not about the person.

The same agent can score high on a margin question and low on a tax form question in the same minute. Read the ranking that way and it stays useful. Read it as a leaderboard and the team will be arguing about it by the second week.

This sits one step past rule-based routing. Rules encode what a manager already believes: security tickets go to the security queue, enterprise accounts go to the senior pod. A predictive model finds pairings nobody wrote a rule for. It also fails in ways a rule never does, because it has no idea why it works.

Two neighboring approaches solve part of the same problem. A graph of topics an agent has closed before is explicit and auditable. A prediction model is broader and harder to explain. Running both, and comparing where they disagree, is more informative than picking one.

The label is the whole project. A model trained on ticket closed learns to predict closing, which every agent does. Pick an outcome that means the customer's problem went away. Solved by the first assignee, no transfer, no reopen inside a chosen window, is a defensible starting definition.

Features fall into three groups. Ticket features come from triage: category, priority, product area, sentiment, customer tier. Agent features come from history: past outcomes on similar tickets, tenure, certifications. Context features come from the moment: current open count, hours left in the shift, time since last assignment.

Some features must be excluded on purpose. Anything that stands in for a protected characteristic has no place here, and neither does anything an agent cannot influence. Write the exclusion list down and have the same person who owns hiring policy sign it. This is a routing model, so it decides who does which work, and that makes it an employment system in practice.

Ticket features need to be trustworthy before the model reads them. A category applied by a classifier whose labels drive routing is a strong feature. A category applied by bulk edit two years ago is noise. Train on the period where triage worked the way it works now.

When the model cannot score a pairing, it should say so and stand aside. A new agent, a new product line, or a category with almost no history all produce meaningless scores. Fall back to the existing rules in those cases. Silence beats a confident number built on four tickets.

Scoring every agent in the org wastes compute and invites bad assignments. Build the candidate list first. Who is on shift, who holds the required permissions, who is under their ticket cap, who speaks the language. Only then score. Cap enforcement itself belongs to queue depth and shift coverage checks.

Hard constraints are absolute and belong outside the model. A ticket that requires a licensed representative cannot go to an unlicensed agent at any score. Encoding that as a feature makes it negotiable, and one day a high score will negotiate it away.

The top score should not always win. A gap of two points between first and third is not a real difference, and always taking the top name concentrates work. Assign randomly among candidates within a narrow band of the best score. That single choice keeps the training data from collapsing onto a few people.

Show the top three drivers next to the assignment. A short line saying the agent has handled similar transfer disputes recently is enough. Leads will not trust a bare number, and they should not have to.

The brokerage below does not exist, and neither do its numbers. An online brokerage supports retail investors and runs a support floor of forty agents. Tickets about incoming account transfers are the hardest category. They involve another firm, a paper trail, and a customer watching a frozen balance.

A customer writes on day nineteen of a transfer that was quoted at five to seven business days. Triage marks the category as account transfer, priority high, sentiment negative. Twelve agents are on shift and cleared for transfer work. The model scores all twelve.

Three names come back close together. The drivers shown are recent closes on multi-week transfer cases and a low reopen rate on angry tickets. All three have at least four hours left in the shift. The router picks Marcus from that band at random. His open count is six, two under his cap.

The floor lead moves the ticket within the hour. This customer has an open complaint from March with the regulator's mediation service, which sits in a field the model does not read. The lead sends it to Dana, who handled the March case. Dana's predicted score was seventh of twelve.

That override is recorded with a reason code for continuity. Continuity overrides pile up on this category over a quarter. Support ops responds by adding prior contact with the same agent as a hard constraint. The model did not learn it. A person read the override log and wrote a rule.

A routing model trains on its own decisions. If it sends every options ticket to the same four agents, only those four generate options outcomes. Everyone else's score on that category stops moving, because there is nothing new to learn from. The prediction becomes true because the router made it true.

Exploration is the countermeasure and it has to be deliberate. Route a fixed share of tickets in each category to agents the model ranks lower but who clear the hard constraints. Pair those with a review or a senior watcher. The cost is a few slower resolutions. The return is a model that knows more than four people.

Scores also punish agents who take the hard work. An agent who volunteers for escalations carries more transfers and more reopens by definition. If the label ignores ticket difficulty, that agent looks worse every quarter. Control for complexity, or exclude escalated tickets from the training set entirely.

Watch the spread of assignments per category alongside accuracy. A model can improve on its own metric while shrinking the number of people who can do the work. Track how many distinct agents handled each category last month. A falling number is a staffing risk, whatever the score says.

Sentiment features drift with the product. A model trained through a calm quarter meets an outage month and finds every ticket angry. Scores compress and the ranking loses meaning. Retrain on a rolling window, and keep priority built from sentiment, tier, and language cues as a separate signal a human can read.

Three decisions never belong to the score. Who is allowed to handle a category at all. What a new agent's queue looks like in their first month. Which customer gets continuity with a specific person.

Overrides are the most valuable data the system produces. Each one names something the model could not see. Collect a reason code, keep the list short, and read the codes monthly. Most will resolve into a missing feature or a missing constraint.

Agents should never see each other's scores. A private view of their own drivers is fair and useful. A ranked list of the floor is a management weapon that arrived without anyone deciding to issue it. Keep the score out of compensation and out of reviews.

The last check belongs downstream. Good routing shows up as fewer reassignments and fewer tickets coming back. Watch flags on closed tickets that are likely to reopen by assignment path. If the model's favored pairings reopen as often as the others, the score is measuring something other than resolution.