Double-replies, ignored tickets, and a queue that piles up on one person all come from the same gap: no shared signal about who owns what and who's around to work it. Three small mechanics close that gap — round-robin spreads new tickets fairly, collision detection shows who's already on a ticket, and presence tracks who's actually online. Together they keep a busy shared inbox clean without anyone policing it by hand.
Round-robin: fair distribution
Round-robin assignment spreads new tickets evenly across available agents, so nobody is overloaded and nothing sits unowned. It's the simplest automation with an outsized effect on a busy queue: instead of the fastest clicker grabbing the easy tickets and the rest going stale, every conversation gets an owner the moment it arrives.
The word "available" is doing real work in that sentence. Round-robin that ignores availability just parks tickets on whoever is next in the list — including people who logged off an hour ago. Done properly, the rotation honors:
- Presence. Skip agents who are offline or away so work lands on someone who can act on it.
- Team and skill boundaries. Route billing to the billing group, not the whole company.
- Role scope. An assigned-only agent only sees what's routed to them, so assignment is what makes their queue exist at all.
Round-robin is the most common strategy because it's predictable and easy to reason about, but it's one rule in a broader automation engine — you can layer conditions on top, like priority or business hours, when even distribution isn't enough on its own.
Collision detection: no double-replies
Collision detection shows who else is viewing or typing on a ticket, so two agents never send conflicting replies to the same customer. Nothing erodes trust faster than a customer getting two different answers to one question within a minute of each other — collision detection is the cheap insurance against it.
It works by surfacing real-time signals on the ticket itself:
- Who's viewing. An indicator shows when a teammate has the same ticket open.
- Who's typing. A live "typing" cue warns you that a reply is already in flight before you start your own.
The deliberate design choice here is that detection is advisory, not a hard lock. It tells people what's happening and lets them coordinate — back off, or drop an internal note — rather than blocking the ticket outright. Hard locks sound safer but create their own mess: a lock left dangling when someone closes their laptop, a ticket frozen because the "owner" stepped away. For most teams, a clear signal beats a gate.
Presence: who’s actually here
Presence — online/offline derived from an active session — lets routing skip people who are away and gives admins an honest view of capacity. It's the connective tissue under the other two: round-robin needs it to know who can take work, and collision detection uses the same live connection to show who's looking at a ticket.
The key property is that presence is observed, not declared. It reflects whether someone actually has the app open and is interacting, rather than a manual "available / busy" status that people set once and forget. That makes it trustworthy for routing decisions and for the capacity view managers rely on when a queue spikes.
How the three work together
Individually each is useful; together they form a loop. Presence establishes who's genuinely available. Round-robin uses that to hand new tickets only to those people, fairly. Collision detection catches the edge cases the rotation can't — two agents both deciding to help on the same conversation, or a manager jumping into a ticket that's already assigned. The result is a queue where work is owned, owners are present, and overlaps are visible. None of it requires a coordinator manually calling out "I've got this one" in a chat channel — the system carries that signal for you.
Tuning assignment for real teams
Out of the box, even distribution is the right default. But real teams have texture, and the assignment rules should reflect it:
| Situation | Adjustment |
|---|---|
| Mixed seniority | Route complex or high-priority tickets to senior agents; round-robin the rest |
| Time zones | Combine presence with business hours so overnight work waits for the next region |
| Specialist queues | Scope the rotation to a team so billing, abuse, or technical tickets reach the right group |
| Contractors | Pair round-robin with an assigned-only role so each contractor only sees their share |
A practical rule: start simple, then add conditions only when you can name the problem they solve. Over-engineered routing is as much a liability as none at all, because nobody can predict where a ticket will land. If you're also setting response targets, assignment and SLAs reinforce each other — a ticket with a clear owner is far more likely to hit its first-response target.
What to measure
You'll know the mechanics are working by watching a few numbers move in the reporting view:
- Unassigned time. How long tickets sit without an owner. Good round-robin drives this toward zero.
- Load balance. Ticket counts per agent should be roughly even, accounting for hours worked.
- Duplicate replies. A qualitative signal — if collision detection is doing its job, customers stop getting two answers.
- First-response time. The end metric assignment exists to protect.
Frequently asked questions
Does round-robin assign tickets to agents who are offline?
It shouldn't. Good round-robin skips agents whose presence is offline or away, so work isn't parked on someone who has left for the day. Cherryrise uses live presence to keep the rotation pointed at people who can actually pick up the ticket.
What is the difference between collision detection and locking a ticket?
Collision detection is advisory: it shows who else is viewing or typing so people self-coordinate, without blocking anyone. A hard lock prevents a second agent from replying at all. Most teams prefer detection because locks create their own problems when someone forgets to release one.
How accurate is presence, and what drives it?
Presence reflects an active session — whether an agent has the app open and is interacting. It is a real-time signal, not a manual status people forget to change, so routing and capacity views stay honest without anyone curating them.
Do these features work the same in a self-hosted deployment?
Yes. Round-robin, collision detection, and presence are part of the core product and run identically whether Cherryrise is hosted by us or on your own infrastructure. Presence relies on a live connection between the browser and your server, which a standard deployment provides.
Round-robin, collision detection and presence are built in. See the workflow engine.