Zendesk Omnichannel Routing

Classic Zendesk assignment is a trigger that puts a ticket in a group, and then a human decides. Live channels were handled separately: chats routed by their own rules, calls by the phone system, and email sat in views waiting for someone to look.

The result was an agent taking a chat while three emails aged in a queue nobody was watching, or the reverse. Nothing in the system knew that a person handling two live conversations should not also be handed the next email.

Omnichannel routing puts all of it into one model. Work items from email, messaging and voice go into queues, agents have a single status across every channel, and Zendesk pushes work to whoever has room for it.

The instinct is to set email capacity high, because agents used to hold twenty tickets in a view. That instinct defeats the whole feature. If capacity is twenty, everyone is under capacity all day and routing hands out work as though nobody were busy.

Start low and deliberately uncomfortable. Something like three or four concurrent email tickets, one or two messaging conversations, one call. Then watch two numbers: how often work sits in a queue with nobody to give it to, and how often agents are pinned at capacity. The first means your capacity is too tight or you're short-staffed for that hour, and queue depth tells you which.

One thing capacity can't see is how hard a ticket is. Three enterprise escalations is a full day. Three password resets is twenty minutes. If your work varies wildly in size, capacity by count will be crude, and the honest fix is separate queues and groups for the heavy work rather than a cleverer number.

Old triggers still assigning. Existing triggers that set an assignee will fight your queues. Audit them before you switch on, not after somebody notices tickets skipping the queue entirely.

No catch-all queue. The commonest failure. A ticket matches nothing, joins no queue, and waits politely for ever.

Skills too narrow. Requiring a skill held by two agents creates a bottleneck that looks like a routing bug. Prefer a broad skill plus a specialist group over a fine-grained skill matrix.

Agents parked on away. The status is now load-bearing, so it needs to be part of how the team works, with the reporting to back it up.

Duplicates arriving at different agents. Routing distributes by availability, so the two tickets a customer raised about one problem will very often land with two people. Even distribution and duplicate detection are unrelated problems, and turning on the first does nothing for the second.

Worth reading alongside this: routing solves distribution, not assignment fairness, and the round robin question is usually the one people are really asking.