Whether to assign tickets automatically at all is a question about your team, and we have written about that choice separately. This guide assumes you have decided to turn round-robin on, and explains what it will then actually do — including several cases where it hands you an unassigned ticket without saying why.
It fires once, at creation
Round-robin runs at exactly one moment: when a ticket is created without an assignee already set. That is the whole trigger.
Three things follow from it. A ticket created with an assignee — because an agent picked it, because an integration set it, because a rule of yours filled it in — is left alone; round-robin never overrides an explicit choice. A ticket that becomes unassigned later, because somebody cleared the field or the assignee left, is not re-assigned; the rotation does not watch existing tickets. And nothing re-balances overnight. If you need work moved after the fact, that is a reassignment workflow rather than this feature.
The step is also best-effort by design. If anything goes wrong while picking an agent, the ticket is still created — just without an assignee. Creating the ticket is treated as more important than assigning it, which is the right priority and is also why a partial failure here looks like an unassigned ticket rather than an error.
The cursor, and the thing that resets it
The rotation is an ordered list of agents plus a position marker. Each pick takes the agent at the current position and advances the marker by one, wrapping around at the end.
The advance is atomic, which matters more than it sounds on a busy account. Two tickets arriving at the same instant cannot be handed to the same agent, because reading the position and moving it are a single indivisible step rather than two. You do not need to think about race conditions here.
What you do need to know is this: saving the rotation settings resets the position to the start of the list. Any save does it — adding an agent, removing one, reordering, or toggling the feature off and on. The next ticket after any change goes to the first agent in the list.
On a large team that is invisible. On a team of three, where somebody adjusts the list every few days, the first agent in the list can end up receiving a noticeably larger share of the work. If you edit the rotation often and fairness matters, that is the mechanism to know about, and the fix is simply to edit it less often or to check the distribution occasionally rather than assuming it evens out.
What required skills change
When a ticket is created with required skills attached, the rotation narrows to agents who have all of them, not merely one. Two required skills means the intersection of both groups.
Within that narrowed group the rotation order is preserved, so round-robin fairness still holds inside the skill cohort rather than restarting or picking arbitrarily. The agents who qualify are visited in the same relative order they occupy in the full list.
Skills are matched against what each agent has declared, so this is only as good as your skill data. A skill nobody has declared matches nobody, which leads directly to the next section. Our guide on routing by department and skill covers how to structure those in the first place.
It would rather assign than be right
This is the behaviour to understand before you rely on skills for anything consequential.
If no agent has all the required skills, the rotation does not give up and leave the ticket unassigned. It falls back to the ordinary round-robin over the full agent list, and the ticket goes to whoever is next regardless of skills. The same fallback applies in a subtler case: if agents with the right skills exist but none of them are in the rotation list, it again falls back to the full list.
The reasoning is defensible — an assigned ticket gets looked at, and an unassigned one can sit in a queue nobody is watching. A named owner who has to hand it on is usually better than no owner at all.
But it means skill requirements are a preference, not a guarantee, and you should never describe them to anyone as a guarantee. If a ticket must only ever reach a certain qualified group — anything with a regulatory or contractual constraint on who may read it — round-robin with required skills is not the mechanism that enforces that. Restricting access at the account level is.
The practical tell is a ticket assigned to somebody visibly wrong for it. That is not a malfunction; it is this fallback, and it means the skill set you required matched nobody in the rotation. Worth checking whenever it happens, because it usually points at an agent whose skills were never recorded rather than at the routing.
The ways you get no assignee at all
A ticket arrives unassigned under any of these conditions, none of which produce a visible error:
- Round-robin is switched off. The obvious one, and worth checking first.
- The agent list is empty. Enabling the feature without choosing anybody leaves it enabled and inert — the toggle and the list are two separate things to get right.
- No rotation has ever been configured on the account, which behaves as switched off.
- The pick failed for any reason. Best-effort means falling through to no assignee rather than failing the ticket.
- The feature was switched off between the ticket arriving and the agent being picked — a narrow window, but it resolves to unassigned rather than to a stale pick.
Because all five look identical from the ticket list, the Unassigned view is the thing that actually tells you round-robin has stopped working. Keeping that view pinned, and noticing when it stops being empty, is a better monitor than any setting screen. Our guide on saved ticket filters covers keeping it in front of people.
Round-robin is not workload balancing
Round-robin distributes tickets by position in a list. It does not know anything else — not who is online, not who is on holiday, not who has forty open tickets and who has two, not whether the last three tickets were thirty-second questions or week-long investigations.
Over a large number of similar tickets that averages out acceptably, which is why the approach survives. Over a small number of dissimilar ones it does not, and the failure mode is specific: an agent who is away still receives their share, and those tickets sit assigned-but-untouched, which is worse than unassigned because they look handled.
So the maintenance task that comes with turning this on is keeping the list current. Take people out when they go on leave and put them back afterwards. That is the whole discipline, and skipping it is the single most common way an automatic assignment setup quietly degrades. Watching open tickets per agent is how you find out it has happened.
For live conversations the equivalent decisions are made by the agent console and its own distribution settings, which are aware of who is actually online. Tickets and chats are separate systems here, and configuring one does not configure the other — a genuinely common mix-up.
Making it work in practice
Round-robin works best when the list is small, current, and boring. A rotation of the four people who are definitely working this week beats a rotation of everyone who has ever had an account.
Pair it with a default owner for anything that lands unassigned. Automatic assignment reduces the number of ownerless tickets; it does not reach zero, and the residue needs somewhere to go.
Give it a fortnight before judging it. The first few days after turning it on will show an uneven distribution, partly because of the reset behaviour above and partly because ticket sizes vary. What you are looking for is whether tickets are being picked up faster than before, not whether the counts are even.
Put it into practice
- Check the toggle and the list separately. Enabled with nobody selected is a working configuration that assigns nothing.
- Expect a restart from the top after every save. Edit the rotation less often on small teams.
- Treat required skills as a preference. They fall back to the full rotation rather than holding the ticket.
- Investigate an obviously wrong assignee as missing skill data, not as a routing fault.
- Keep the unassigned view pinned. It is the only visible signal that the rotation has stopped picking.
- Remove people who are away the same day, because assigned-and-untouched looks handled.
- Do not expect it to rebalance anything after creation. It fires once and never revisits.
The feature is deliberately simple, and most of the surprises in it come from that simplicity rather than from complexity — a list, a position, and a strong preference for assigning somebody over assigning nobody. Once you know it restarts at the top whenever you save and that skills are a preference rather than a rule, it behaves exactly as it looks.