Zendesk Round Robin Ticket Assignment: Native Setup, Apps, and What Resets the Rotation
August 2026 · Assigner
Zendesk does have round robin, it is built into omnichannel routing, and it is available on every Suite plan and on Support Team and above. It is not a rotation through a list. Zendesk offers the next ticket to the agent with the longest time elapsed since they were last assigned work for that channel, which behaves like a rotation only while everyone is equally busy. Three separate events reset an agent's place in that line, and when every agent is at capacity the method stops applying at all. Here is the exact setup path, the resets nobody mentions, and an honest answer to whether you need a marketplace app.
Zendesk round robin is longest-idle selection, not a fixed rotation
Turn on omnichannel routing and you pick one of two assignment methods. Either Zendesk routes by highest spare capacity, or it routes by time elapsed since agents last received work for that channel, which Zendesk's own documentation says is "commonly referred to as round robin".
That second phrasing is doing a lot of work. A classic round robin holds an ordered list and walks it: Ana, Ben, Carla, Ana, Ben, Carla. Zendesk holds no list. Every time a ticket needs an owner it looks at the eligible agents, checks when each one was last assigned work on that channel, and picks whoever has waited longest. The tracking is per channel, so an agent's email clock and messaging clock run independently.
In a steady state with a homogeneous team the two models produce the same sequence, which is why the difference goes unnoticed for months. It stops matching intuition the moment your agents stop being interchangeable. Idle time measures the gap since the last assignment. It says nothing about what that assignment was. An agent who picked up one brutal multi-day escalation ninety minutes ago looks less available to the engine than a colleague who closed five password resets in the same window, and the engine picks the colleague.
Where you turn it on, and the two things that break first
The path is Admin Center > Objects and rules > Omnichannel routing > Routing configuration. Before you flip it, two prerequisites and two side effects.
Agent Workspace has to be active on the account, and if you run Chat then native messaging or Sunshine Conversations has to be active too. Omnichannel routing also cannot be turned on if live chat is the only channel you operate.
Then the side effects, in the order they will bite you.
- Turning omnichannel routing on immediately sets every agent to offline. Email routing needs an agent who is online or away; messaging and calls need online. Until your team changes status, nothing routes anywhere and the queues look broken. Do this at a quiet hour and tell people in advance.
- Email tickets do not route on group assignment alone. You define an auto-routing tag during setup, and a ticket trigger has to do two things to every email ticket you want routed: assign a group and add that tag. Miss the tag and the ticket sits with a group and never enters a queue, which looks identical to a queue misconfiguration and is diagnosed nowhere near the queue.
- Triggers only run on new or updated tickets. Everything already open when you flipped the switch keeps sitting where it was. If you want the backlog routed, it has to be touched so the triggers fire, which usually means a bulk update.
The wider configuration picture, including custom queues, skills, and how capacity rules are defined, is covered on our Zendesk omnichannel routing page. This article stays on the rotation itself.
The three events that move an agent to the back of the line
This is the part that explains almost every "our round robin is uneven" thread, and it is stated plainly in Zendesk's documentation. Three separate events count as an assignment for round robin purposes:
- Any ticket assignment to an agent, whether it was manual or done by omnichannel routing. A team lead who reassigns a ticket by hand has just pushed that agent to the back of the rotation.
- A call or messaging ticket being offered to an agent. Offered, not accepted. The clock resets when the work is presented.
- A ticket assigned to an agent being reopened. A customer replying to a three-week-old resolved ticket counts as a fresh assignment for that agent.
Read those together and a common pattern falls out. The agent who handles the fiddly accounts, the ones whose customers reply again and again, gets reopened tickets constantly. Every reopen sets their clock back to zero. They are never the longest-waiting agent, so they receive very few new tickets, and their teammates conclude the rotation is favoring them. It is doing the opposite, and no amount of staring at the queue configuration will show it.
The same logic explains why manual reassignment is not free. Pulling one ticket off an overloaded agent and handing it to somebody else does not just move a ticket, it changes who is next for the following three.
What happens when everybody is at capacity
Agents only receive work when they have an eligible status and spare capacity for the channel. So what happens when nobody has spare capacity? Zendesk's answer is the same regardless of which assignment method you chose: the ticket goes to the first agent who drops below their maximum capacity.
That is worth sitting with, because it means your carefully chosen routing method quietly stops applying exactly when routing matters most. On a normal Tuesday you have round robin. During an incident, when every agent is at their cap, you have first-free-wins. The fastest closer gets a disproportionate share of the surge, which is the reverse of what most teams want during a surge.
There is also focus mode, which prevents omnichannel routing from assigning messaging tickets to an agent while they are on a call. Email tickets are excluded from focus mode, so an agent on a call can still be handed email work.
And the capacity limits themselves are softer than they look. Zendesk's documentation is explicit that agents can assign themselves work in excess of their capacity limits if they want to. The cap constrains what the engine pushes, not what an agent ends up holding, so the most willing people route around their own ceiling. That is the exact distribution problem capacity rules were introduced to solve.
Do you need a marketplace round robin app?
Sometimes, and less often than the app listings suggest. Before omnichannel routing existed, a marketplace app was the only way to rotate tickets in Zendesk, and that history is why so many teams still assume rotation is a paid add-on. It is not. Round robin ships with every Suite plan and with Support Team, Growth, Professional, Enterprise, and Enterprise Plus.
What the apps add is the layer above the rotation. The long-established Round Robin app has been distributing tickets since 2016. Playlist's routing app assigns in batches roughly every minute while respecting agent capacity, daily ticket limits and work schedules, and adds a pull model where agents request their next ticket instead of having it pushed, plus sticky routing back to the same agent and percentage splits between groups. Knots takes the opposite approach and builds its rotation on top of Zendesk's own triggers and tags rather than running a parallel system. Both offer 14-day trials through the marketplace.
These are per-agent monthly subscriptions on top of your Zendesk bill, and the listings are where the current rates live, so price them there rather than from any blog post including this one. The honest evaluation question is narrow: does the app do something omnichannel routing genuinely cannot? Daily per-agent caps, schedule-aware assignment, pull-based claiming, and percentage splits between groups are real gaps. Basic rotation is not a gap anymore.
| Requirement | Native omnichannel routing | Marketplace rotation app | Assigner beside Zendesk |
|---|---|---|---|
| Rotate tickets between agents | Included on all Suite plans | Included, per agent per month | Included from $12/user/mo |
| How the agent is picked | Longest idle on that channel | Varies, often a true sequence | True rotation, weighted, or by open load |
| Reopened tickets reset the clock | Yes, by design | Depends on the app | No, rotation state is explicit |
| Capacity limits are enforced | Advisory, agents can exceed | Some apps enforce daily caps | Enforced unless you override |
| Behavior when all agents are full | First to free up wins | Varies | Queued against your rules |
| Skills-based matching | Suite Professional and above | Rarely included | Included |
| Weighted split for part-time agents | No | Some offer percentage splits | Yes |
| Also routes sales leads and ops tasks | No | No | Yes, one engine |
| Records why each assignment happened | Limited | Varies | Yes, rule plus candidates |
Verified in August 2026 against Zendesk help documentation and public app listings. Zendesk and app vendors repackage between releases, so confirm your own entitlements in Admin Center and current app pricing on the marketplace listing.
What no round robin can see
Rotation, native or bought, distributes ticket counts. It has no opinion about what is inside them. Whether that is a problem depends entirely on whether your tickets are actually interchangeable, and most teams have never checked. Pulling ticket volume together with product usage and customer feedback is the fastest way to find out which queues are carrying the heavy work, and tying support tickets back to what customers are actually doing in the product tends to make the answer obvious within a week.
If the answer is that a third of your tickets take ten times as long as the rest, count-based fairness is not fairness. Three levers help, and Zendesk gives you one and a half of them. Capacity rules approximate concurrent load, but they are advisory. Skills matching routes hard tickets to the people who can handle them, but it starts at Suite Professional, or Enterprise on standalone Support plans. Weighting a rotation so a half-time agent carries half the load is not available natively at all.
That is the boundary where a routing layer beside Zendesk starts to pay for itself rather than duplicating what you already have. Assigner runs round-robin assignment with explicit rotation state that a reopened ticket does not disturb, weighted rotation for part-time and ramping agents, workload balancing on open effort rather than assignment counts, skills-based routing without a plan upgrade, and availability routing that takes people out of the rotation when they are off. It handles support ticket routing, sales lead routing and ops tasks with one rule set, at $12 per user per month, and every assignment records the rule that made it and the candidates it passed over. It is a companion to Zendesk rather than a replacement or a live two-way sync. If you are weighing that against a Zendesk plan upgrade, our Zendesk routing alternative comparison puts the numbers side by side, and round robin ticket assignment shows how the other major help desks gate the same features.
Frequently asked questions
Does Zendesk have round robin ticket assignment?
Yes. Round robin is one of two assignment methods in omnichannel routing, the other being highest spare capacity. It is available on all Suite plans and on Support Team, Growth, Professional, Enterprise, and Enterprise Plus. You enable it in Admin Center under Objects and rules, then Omnichannel routing, then Routing configuration. A marketplace app is no longer required for basic rotation.
How does Zendesk round robin decide which agent gets the ticket?
It assigns to the agent with the longest time elapsed since they were last assigned a ticket for that channel, among agents who have an eligible status and spare capacity. It is longest-idle selection rather than a walk through an ordered list, and the tracking is per channel, so an agent's email and messaging clocks run separately from each other.
Why is my Zendesk round robin uneven?
Usually because of what counts as an assignment. Three events reset an agent's position: any ticket assignment including manual ones, a call or messaging ticket being offered to them, and a previously assigned ticket being reopened. An agent whose tickets get reopened often is constantly pushed to the back of the line and receives fewer new tickets, which reads as favoritism but is the rotation working as documented.
Does a reopened ticket count as a new assignment in Zendesk round robin?
Yes. Zendesk documentation lists a reopened ticket assigned to an agent as one of the three events counted as an assignment, alongside any manual or routed assignment and any call or messaging ticket offered to an agent. That means a customer replying to an old resolved ticket moves its assignee to the back of the rotation for new work.
What happens when all Zendesk agents are at maximum capacity?
The routing method stops applying. Zendesk assigns the ticket to the first agent who drops below their maximum capacity, regardless of whether you configured round robin or highest spare capacity. During a surge, when everyone is capped, distribution effectively becomes first-free-wins, so the fastest closer absorbs a disproportionate share of the spike.
Do I need a Zendesk round robin app from the marketplace?
Only for capabilities native routing lacks. Rotation itself is included on every Suite plan and on Support Team and above. Apps are worth paying for when you need daily per-agent ticket caps, schedule-aware assignment, a pull model where agents claim their next ticket, sticky routing back to a previous agent, or percentage splits between groups. Price them on the current marketplace listing rather than from any article.
Which Zendesk plan do I need for round robin ticket assignment?
Round robin routing is available on all Suite plans and on Support Team, Growth, Professional, Enterprise and Enterprise Plus. What is gated higher is everything around it: custom queues and Zendesk skills based routing require Suite Professional or above, or Enterprise on standalone Support plans. Teams often assume rotation itself is the gated feature when the gate is actually on queues and skills.
Can Zendesk round robin account for agent workload?
Only indirectly, through capacity rules that cap concurrent work per channel. Those limits are advisory: Zendesk documentation states agents can assign themselves work in excess of them. Round robin itself measures time since the last assignment, not how much work an agent currently holds, so a single long escalation counts the same as one quick reply.
Why are no tickets routing after I turned on omnichannel routing?
Check two things in order. Turning omnichannel routing on sets every agent to offline, and email needs an agent who is online or away while messaging and calls need online. Then check your triggers: an email ticket only enters a queue if a trigger both assigns a group and adds the auto-routing tag defined during setup. A missing tag looks exactly like a broken queue.
Does Zendesk round robin work with skills-based routing?
Yes, they stack. Skills narrow the pool of eligible agents to those holding the required skills, and round robin then picks the longest-idle agent from that narrowed pool. Skills-based routing requires Suite Professional or above, or the Enterprise tier on standalone Support plans, and Zendesk supports up to 10 skill types with 30 skills each.
Stop hand-sorting your incoming work
Route every ticket, lead, and request to the right available person by skill, workload, and availability, using rules you control, and every assignment shows why. Rules you control, no black box.