Skills-Based Routing: Getting the Right Conversation to the Right Agent
How Chat's routing rules and agent shifts work together to get a conversation to someone who can actually handle it.
"Route by skill" sounds like one feature. In Chat it's actually two separate mechanisms that happen to work together: routing rules, which decide where a new conversation should go, and agent shifts, which decide who's actually available to take it.
Routing rules: condition, then action
A routing rule is a condition paired with an action, evaluated when a conversation is created. The conditions are deliberately narrow today — a rule can match on the URL the visitor was on (url_contains) or on their geographic country (geo_country). That's it. There's no free-text intent matching or keyword scanning at this layer; if a visitor is on your /billing page, a rule matching url_contains: /billing can route them straight to whichever team handles billing questions, without anyone reading the message first.
Rules are tied to a teamId, so the action isn't "assign to a specific person" — it's "hand this to a team." That matters for a support inbox specifically: teams change shape (people go on leave, get added, get reassigned) far more often than the routing logic that points conversations at them should need to change.
Shifts: a preference, not a hard gate
Once a conversation lands with a team, who actually gets it depends on agent shifts — recurring weekly schedules that mark when each agent is expected to be online. Two things determine assignment from there: getOnShiftAgentIds, which agents are currently on shift, and getLeastBusyAgent, which of those has the lightest open-conversation load right now.
It's worth being precise about what shifts are: a preference layered on top of routing, not a hard gate that blocks assignment outright. A conversation doesn't get stuck in limbo because nobody happens to be scheduled at 2am — the system still assigns it, it just prefers agents who are supposed to be working right now over agents who aren't.
Why the two layers are worth understanding separately
If a conversation lands with the wrong team, the fix is a routing rule — check the URL or country condition. If a conversation lands with the right team but the wrong (or overloaded) person, the fix is a shift or the least-busy-agent logic — routing rules aren't the place to debug that. Conflating the two is the most common way teams end up either editing the wrong thing or assuming a capability ("route based on what the visitor typed") that doesn't exist yet, since today's conditions are limited to URL and country.
Setting it up
Start with the account-level questions routing decides best: which pages belong to which team (billing, sales, general support), and which countries — if any — should route to a specific team, typically for language or timezone reasons. Then layer shifts on top so the assignment within a team reflects who's actually working, not just who's technically a member of it. The two layers compose cleanly: get the team right first, then let shift-aware assignment pick the person.