Round-robin chat assignment is the most over-recommended pattern in support tooling, and on a 5-15 agent team it actively hurts you. It distributes chats to whoever's next in a list, ignoring whether that person is in a meeting, drowning in a P1 ticket, or already mid-conversation with three other visitors. Agent presence based chat routing flips the default: real-time status drives assignment, and round-robin only breaks ties among agents who can actually respond.
Key takeaways
- Round-robin distributes by fairness; presence-based routing distributes by capability — and capability is what reduces visitor wait time.
- On teams of 5-15 agents, presence status (Online / Away / Busy / Offline) is a more predictive signal of who can answer in 30 seconds than any skill tag or queue position.
- Treating presence as a routing input — not just a UI badge — typically cuts first-response time by double-digit percentages on chat (estimate, varies by team).
- Four routing rules cover 95% of SMB chat scenarios: presence gate first, then concurrent-load cap, then topic match, then round-robin among the survivors.
- Without a presence-aware fallback (escalate to group, queue with ETA, or AI bot triage), presence routing fails the same way round-robin does — silently.
Round-robin optimizes for fairness, not for visitor outcomes
Round-robin made sense in the call-center era when agents sat at desks with one phone line and binary availability — either you picked up or you didn't. Modern support agents work across email tickets, internal escalations, documentation, and chat simultaneously. Their availability isn't binary; it's a continuous signal that changes every few minutes.
When round-robin hands a chat to an agent who's heads-down on a complex ticket, three bad things happen: the visitor waits 90+ seconds for a hello, the agent context-switches out of work they were close to finishing, and the chat eventually gets reassigned anyway — burning the original wait. You've optimized for a fairness metric (chats per agent per day) that no customer has ever asked about.
The metric that matters is time-to-first-human-response, and presence is the cheapest, most accurate predictor of it your system already has.
What "presence-aware routing" actually means
Presence-aware routing means the assignment engine reads each agent's current status — Online, Away, Busy, Offline — and filters the eligible pool before it picks. It's a precondition, not a tiebreaker.
A practical implementation reads four signals:
- Explicit status the agent set (Busy because they're in a customer call)
- Inferred status from activity (heartbeat missed for 5 minutes → Away)
- Concurrent load — how many open chats they're already handling
- Schedule — are they in their configured business hours
The routing engine treats Online + under-capacity as the only eligible pool. Round-robin then breaks ties among those agents, which is the only place round-robin belongs.
The four routing rules that cover 95% of SMB chat
For a 5-15 agent SaaS support team, you don't need a 20-rule routing builder. You need four rules applied in order. Each one filters the pool the next rule operates on.
| Rule | What it checks | Why it matters |
|---|---|---|
| 1. Presence gate | Status = Online, in business hours | Eliminates the "assigned to someone who can't respond" failure mode |
| 2. Concurrent-load cap | Open chats < per-agent max (typically 3) | Prevents your fastest typist from absorbing every chat |
| 3. Topic / skill match | Tag or topic matches agent's group | Routes billing to billing, technical to engineering escalation |
| 4. Round-robin tiebreak | Least-recently-assigned among survivors | Keeps load even within the eligible pool |
Apply them in that order. Rule 1 alone — without 2, 3, or 4 — already outperforms pure round-robin for most teams. Adding rule 2 prevents your most senior agents from getting silently overloaded because they're always online and always fast. Rule 3 is optional below ~8 agents; it adds value as you specialize. Rule 4 only kicks in at the bottom of the funnel, where it belongs.
Why senior agents get burned by round-robin
This is the part support leads don't see until they look at chat-per-agent distributions: round-robin's "fairness" is an illusion on small teams.
Your senior agents are online more, faster to mark themselves available, and quicker to resolve. So they finish chats sooner and re-enter the queue sooner. Round-robin happily hands them the next one. Over a week, the most senior 20% of your team handles 40-50% of chats (estimate; varies by team composition) — exactly the people you can't afford to burn out.
A concurrent-load cap fixes this. Set max-3 simultaneous chats per agent. When your senior agent hits 3, the engine skips them until one resolves. The chat goes to a junior agent who's at 1-of-3 instead of waiting in queue. The senior agent stays available for escalation pings and complex tickets — which is what you actually want them doing.
What to do when nobody's eligible
The failure mode of presence-aware routing is when no agent passes rule 1. Pure round-robin doesn't have this problem because it doesn't filter — it'll happily assign to someone who's been Away for two hours. Presence routing exposes the gap, which is the point.
You need an explicit fallback chain:
- Expand the pool — drop the topic-match requirement, route to any Online agent regardless of group
- Queue with honest ETA — show the visitor a wait estimate based on current open chats, don't pretend someone's coming
- AI bot triage — let the bot handle the first message and collect context while a human becomes available
- Capture and convert — if nobody's online at all (after-hours, weekend), fall back to a ticket form with a guaranteed response window
The worst pattern is silent assignment to an unavailable agent. That's round-robin's default behavior and the single biggest source of "I waited 5 minutes and got nothing" complaints in chat audits.
How Helptal fits in
Helptal's live chat tracks four-state presence (Online / Away / Busy / Offline) per agent with a 60-second heartbeat, and surfaces it both to the routing engine and to other agents. Group routing supports round-robin distribution among eligible members, so you can stack the four rules above: route chats to a group, let the group auto-distribute, and the engine respects presence and current load before picking. Combined with proactive chat rules for live-visitor tracking and an AI bot for the after-hours fallback, you get the full pattern — presence-gated assignment, load-aware tiebreaking, and a real answer when nobody's eligible.
Frequently asked questions
What is agent presence based chat routing?
It's a chat assignment model that reads each agent's real-time status — Online, Away, Busy, or Offline — and only routes incoming chats to agents who are currently available. It treats presence as a filter applied before any other rule (round-robin, skill match, load balancing), rather than as a UI badge that has no effect on assignment.
Is round-robin chat assignment ever the right choice?
Yes — as the tiebreaker among agents who already passed a presence filter and a concurrent-load check. Pure round-robin without those filters is rarely the right default on a 5-15 agent team, because it ignores whether the assigned agent can actually respond. Round-robin's role is to keep load even within the eligible pool, not to define the pool.
How many concurrent chats should one agent handle?
Two to three is the practical cap for most SaaS support teams. Above three, response quality drops measurably and average chat duration extends because agents context-switch between conversations. Set the cap per-agent rather than per-team, since senior agents can typically handle three comfortably while agents in their first month should be capped at one or two.
What happens when no agent is available with presence routing?
You need an explicit fallback chain: expand the pool by dropping topic requirements, queue the visitor with an honest wait estimate, hand off to an AI bot for triage and context-gathering, or fall back to a ticket form with a guaranteed response window. The failure mode to avoid is silent assignment to an unavailable agent — which is exactly what round-robin does by default.
Does presence routing work for after-hours chat?
Not on its own. Presence routing filters to zero eligible agents after hours, which is correct behavior. Pair it with an AI bot that can answer common questions from your knowledge base, or with a ticket-form fallback that sets expectations on response time. The combination — presence routing during business hours, automated handling outside them — covers the full day without overloading agents or misleading visitors.
This week, audit your last 50 chats and tag each one with the assigned agent's status at the moment of assignment. If more than 10% went to Away or Busy agents, round-robin is costing you visitor wait time you can recover with a one-rule change. If you're evaluating tooling that treats presence as a routing input rather than just a badge, Helptal's free plan includes the chat widget, presence tracking, and group routing — enough to test the four rules above before you commit.