Chat Routing: Departments, Skills, and the Right Agent

Routing exists to save two people time

Good routing saves the visitor a re-explanation and saves the agent a transfer. Bad routing adds a dropdown, a queue, and a handoff to reach the same outcome. Before you build any routing rule, name the moment it prevents: the billing question that lands on a salesperson, the enterprise lead that waits behind password resets. If you cannot name it, you do not need the rule yet.

Departments: only if they route to different people

A department picker is worth it when "Sales" and "Support" genuinely reach different queues staffed by different people with different goals. It is theater when every option lands in the same place — you have added friction to the visitor and learned nothing. Keep the list short (two or three), label it in the visitor's words, and make sure each choice changes who answers.

Skills-based routing: match the question to the expert

As a team grows, not every agent is equal on every topic. Tagging agents with skills — and tagging conversations or tickets with the skill they need — lets the hard API question find the person who can actually answer it, instead of bouncing through two transfers first. Start with the three or four topics that most often need a specialist; over-tagging just recreates the same queue with more labels.

Let intent do the routing before the visitor does

The best routing often needs no dropdown at all. The page a visitor is on, a proactive invitation they accepted, or what they type first is a stronger signal than a menu they click impatiently. A chat opened on the pricing page is probably sales; the AI layer reading the first message can hand off with context already attached.

Design the transfer, not just the assignment

• Carry the context. A transfer that makes the visitor repeat themselves undoes the point of routing. Pass the transcript and any tags along.
• Name the wait. "Connecting you with our billing specialist — one moment" turns a silent pause into a promise.
• Have a fallback. If the target queue is empty, the chat should land somewhere staffed, not vanish.

Measure whether it worked

Track transfers per chat and time-to-right-agent. If routing is healthy, most conversations resolve where they land and transfers are rare. Rising transfers mean your rules are guessing wrong — simplify them. In MyLiveChat, departments and agent assignment are configurable, so tightening a rule is a settings change you can test against the next week of traffic.

Routing rules age badly

Routing is configured once, when the team and product are a particular shape, and then quietly outlives both. The rule written for a department that no longer exists, the skill tag nobody has, the queue that a single person is silently responsible for: these accumulate, and each one sends real conversations somewhere unhelpful.

The failure is hard to notice because it is invisible from the dashboard. Chats are being routed successfully; they are simply arriving in the wrong place, and the cost shows up as transfers and slow replies rather than as an error.

Review the rules on a schedule, and check them against the actual roster rather than the intent. For every route, ask who receives this today, whether they are still the right person, and what happens if they are away. Rules that survive that questioning are worth keeping; most of the rest can be deleted, and deletion is usually an improvement.

The fallback every routing setup needs

Every routing configuration eventually receives a conversation that matches nothing, or matches a queue with nobody in it. What happens next is the single most important part of the design, and it is the part most often left to chance.

Define an explicit default: a queue that is always staffed during your covered hours, which receives anything unmatched. Without it, unmatched conversations sit unnoticed, and the visitor experiences a widget that accepted their message and never replied — which is worse than being told nobody is available.

Add a time-based safety net as well. If a conversation has been in a specialist queue for longer than a set period without a reply, it should widen to a broader group rather than continue waiting for the ideal person. A good answer from a generalist in two minutes beats a perfect one in forty, and this single rule prevents most of the worst individual experiences a routed setup produces.

When to stop adding rules

Routing complexity grows one reasonable decision at a time, and there is a point past which each new rule costs more than it saves. The signals are recognisable: agents no longer able to predict where a chat will land, a rule nobody can explain the origin of, and more time spent maintaining the configuration than it saves in handling.

A useful discipline is to require that every rule name the problem it solves and the person who wanted it. Rules that cannot be described that way are usually the residue of a one-off situation.

Prefer fewer, broader queues with good transfer habits over many narrow ones. Narrow queues look efficient and fail badly at the edges, particularly when someone is away, and the flexibility of a smaller number of well-staffed groups is worth more than the theoretical precision of many.

The simplest version of intent routing is to ask. Letting visitors pick a topic before the chat starts turns a short list of subjects into the department assignment, with no rules engine involved.