Workload-aware auto-assignment

Assignment by workload solves a different problem than assignment by skill. It answers who has room right now. The system reads open ticket counts, shift hours remaining, channel commitments, and the weight of what each agent already holds. Then it places the ticket where it will be picked up soonest.

Speed is the outcome, and it comes from removing two specific delays. Tickets no longer sit in a shared queue waiting for someone to claim them. Agents no longer end a shift with eleven open items while a colleague has three. Zendesk Omnichannel Routing is one product in this category.

What it does not do is judge fit. A balanced queue full of misrouted tickets is a fast path to a slow resolution. Workload logic runs after the candidate pool has been narrowed by skill, permission, and language. It picks among people who could all handle the ticket.

Sentiment enters as a load factor, not as a priority. An agent holding four furious customers carries more than an agent holding four routine questions. Priority order is set elsewhere, by a score built from sentiment, customer tier, and language cues. Workload uses the same signal for a different purpose.

Ticket count is a poor measure of load on its own. A password reset and a billing investigation both count as one. Assign a weight per category, keep the scale coarse, and let leads adjust it. Three weight levels are usually enough, and a finer scale invites arguments nobody can settle.

Every agent needs a cap and a floor. The cap is the weighted load past which no new ticket arrives. The floor prevents the optimizer from parking someone at zero because they are new or slow. Caps differ by role: a trainee, a senior agent, and a team lead who takes tickets between meetings are three different numbers.

Shift data has to be real, and it usually is not. A roster that ignores breaks, meetings, and training will hand tickets to empty desks all day. Pull from the workforce system if one exists. Treat unplanned absence as a signal the optimizer reads within minutes, not at the next nightly sync.

When the inputs are missing, fall back to a simple rule. No shift feed and no weights means round-robin inside the eligible pool. That is not sophisticated, and it beats an optimizer solving with numbers nobody maintains.

The optimizer scores the cost of each placement rather than the fit. Cost rises with the agent's current weighted load, falls with hours left in their shift, and rises sharply near the cap. The lowest-cost eligible agent gets the ticket. The whole calculation runs in the time it takes to save the record.

End-of-shift handling deserves its own rule. A ticket assigned twenty minutes before someone logs off will either be rushed or abandoned. Set a cutoff by category, longer for investigations and shorter for quick answers. Below the cutoff, the ticket goes to the next shift or holds in the queue.

Rebalancing existing tickets is the risky half. Moving an untouched ticket is nearly free. Moving one where the agent has already replied costs the customer a new name and the agent an hour of context. Allow automatic rebalancing only before first response, and require a human for anything after that.

Duplicate volume should never be spread evenly. Fifty tickets about the same outage assigned to fifty agents is fifty investigations of one problem. Matching new tickets against active incidents at intake has to run before workload logic. The wave then lands with one owner, and everyone else gets a linked update.

The platform in this walkthrough is imaginary. A ticketing platform sells seats for concerts and sports through venue partners. Support runs eighteen agents on a normal weekday. Volume is flat most of the time and then multiplies when a large tour goes on sale at ten in the morning.

Ops staffs twenty-six agents for the on-sale window. Categories are weighted at three levels. A checkout error counts as one, a duplicate charge counts as two, and a partner-side inventory problem counts as three. Standard caps sit at twelve weighted points per agent.

At ten past ten the queue holds far more tickets than the floor can absorb. The optimizer spreads checkout errors across everyone under cap and keeps the inventory tickets with the six agents cleared for partner systems. Four agents due to break in fifteen minutes stop receiving anything above weight one.

The floor lead makes two calls the system could not. She raises the cap to sixteen for the on-sale hour, accepting that quality will dip. She also pulls one senior agent out of routing entirely to handle escalations from the venue partner, who is calling every ten minutes. That agent's cap drops to zero and the optimizer works around her.

By noon the caps return to twelve automatically, because the change carried an expiry. No lead had to circle back and undo it. The tickets still open at that point stay where they are. First responses have gone out, and moving them would cost more than it saves.

An even spread is not the same as a healthy queue. Every agent can hold nine tickets while the four that matter most sit untouched in all of them. Workload logic distributes. It does not decide what gets worked first. Pair it with forecasts of which tickets will miss their target or the balance will look fine while commitments break.

Agents learn the weights and work with them. If closing tickets lowers load and load determines assignment, the fastest way to stay comfortable is to close things quickly. Some of that is good. Some of it is a ticket closed without a real answer. Watch reopen rates by agent alongside throughput.

Difficult customers concentrate without anyone choosing it. If sentiment adds weight, the agents who close angry tickets fastest come back under cap first and receive the next one. Track how many high-sentiment tickets each agent takes per week and cap that separately. Burnout does not show up in a load number until the resignation arrives.

Caps are a management setting and should be editable in seconds. During an incident, a launch, or a sick day, the right number changes. Every temporary change needs an expiry, because a cap raised during a crisis and never lowered becomes the new normal by accident.

Agents need a way to say they are underwater. A status that pauses new assignments without ending the shift costs nothing. It prevents an agent from quietly drowning while the dashboard says they are within cap. Leads see who has set it and can ask why.

Some tickets should never be balanced. A named account with an assigned owner, a legal matter, or a case already in progress belongs to a person regardless of load. Keep that as a short list of exceptions the optimizer checks first, and let one person maintain it. Context pulled in by account history attached at intake is what makes those exceptions detectable.

The lead's judgment beats the cost function during anything unusual. An optimizer sees an even queue and reports success. A lead sees that the only person who understands the failing subsystem is buried in routine work and moves six tickets off her. That move looks worse on every load metric and is obviously correct.

Load balancing and fit belong in that order, and neither owns the outcome. Narrow the pool with skill and permission, then place inside it on capacity. Predicted likelihood of resolution per agent can refine the first step where it earns its place. A person still watches the queue and moves what looks wrong.