Omnichannel routing: tickets to the right agent, automatically
If you run several channels, you know the old pattern: triggers push tickets into group views, and agents pick out what they like. The easy ones first, the tedious ones left behind. Omnichannel routing turns that around. Zendesk distributes actively instead of putting up a queue to serve yourself from.
What omnichannel routing is
Omnichannel routing actively assigns new and open tickets from email (including web form, side conversations and API), messaging and calls to a specific agent, based on that agent’s availability and capacity. The agent doesn’t pull the ticket, the system pushes it.
The core is a unified agent status: instead of going online separately per channel, the agent has one status covering email, voice and messaging together. Whoever is set to «online» and has room gets work automatically. On Professional you can also define up to five of your own statuses like «in session», on Enterprise up to 100.
Requirements: Agent Workspace switched on, a Suite plan from Team upward, and for messaging an active Chat or native messaging integration; Talk not in the Lite edition. For newly created Zendesk accounts, routing is now active out of the box; the changeover described below mainly concerns existing instances. When you turn it on, all agents are set offline first and have to pick their status again. Tell the team beforehand.
Not everything flows through routing: light agents don’t get tickets assigned, and a messaging conversation handled by a bot only enters routing once it escalates to a human.
public/werkstatt/bauplaene/omnichannel-routing/queues.png
Queues, skills, capacity
Distribution runs through queues. If nobody is free, the ticket waits in the queue until an agent has capacity.
- Standard queue (group-based): the ticket goes to the group set on the ticket. Enough for simple setups.
- Custom queues (from Professional): your own conditions, plus primary and secondary groups. Secondary is the overflow that only kicks in when nobody in the primary groups is free. The ticket’s assigned group field is then ignored. Up to 199 custom queues are possible.
- Subqueues (Enterprise only): split one custom queue into up to five parts, with percentage shares that add up to 100%. Within a subqueue, assignment is random.
A pitfall when mixing them: a ticket that matches a custom queue is distributed through it, not through the standard queue, and that regardless of priority. If you run both in parallel, delimit the custom queues’ conditions cleanly, otherwise the standard queue kicks in less often than you’d think.
Within the queue, the order decides who’s up first. Sorting by time until SLA breach is available from Growth, by priority and timestamp from Professional. Tickets with an SLA target come before those without. The ticket then goes to the available agent with the most free capacity for that channel; on a tie, to the one who has gone longest without a ticket from that channel.
You set capacity per channel: say 3 chats and 5 emails at once. For calls the value is always 0 or 1 — more than one phone call at a time isn’t possible. That way a call doesn’t block email work. Skills (from Professional) additionally match the ticket to the right ability: only an agent who has the skill is eligible.
Set the values low at first and raise them once the team has room. Capacity set too high pushes work to people who are already full. Which agent the system picks when it has a free choice also depends on the evaluation method: by number of free slots or by percentage of capacity still open. When capacities differ from person to person, the percentage variant distributes more evenly.
What happens when nobody accepts
An assigned ticket doesn’t just sit there because the agent happens to be away from their desk. For email and messaging they have a window to accept, 30 seconds by default. If they don’t accept, the ticket is reassigned to the next suitable agent. That’s the operational gain over «ticket sits in a view»: there’s no silent queue where something gets forgotten.
Calls work differently. A call can’t be redistributed after the fact. It rings available agents in turn (round robin) until one picks up or the maximum wait time is reached. That’s also why Talk capacity only knows 0 or 1.
Trigger-based vs. omnichannel: the real difference
Triggers don’t go away. They keep running on every new or changed ticket and still handle setting the group and, for email, assigning the auto-routing tag. That’s the groundwork.
The difference comes after. The classic path stops at the group: the ticket lands in a view, and assigning it to a person is manual work or self-service. Omnichannel routing takes that last step itself: it picks the specific agent from the group who is freest right now. No cherry-picking, no unpopular tickets left lying around, more even load.
For the changeover this means: thin out your trigger set. Assignment reliably needs only two things, the auto-routing tag and a default priority (say «normal»), so that every ticket has an ordering criterion in the queue. Set up a fallback queue with the lowest priority where tickets land that don’t match any other queue; that way nothing slips through. And create a view «waiting tickets» so the team lead can see what’s currently sitting in the queues.
In short: triggers prepare the ticket (group, tag, priority), omnichannel routing brings it to the right person. For operations with several channels and real volume, this is the point where distribution turns from chance into rule.
Predictive routing as the next step
Once you have queues, capacity and triggers cleanly in place, you can add another level. Predictive routing estimates intent, language and sentiment from the message text and routes accordingly, so far for messaging only. It’s worth it as an addition to a stable base, not as a replacement for it. So the order is: first get the basic distribution running, then skills, then predictive.