What auto routing actually changes
With automatic distribution switched off, a new chat request lands in a shared queue and waits for somebody to claim it. Every agent can see it, and any agent can take it. That works well in a small team sitting in one room, because the social protocol does the routing: somebody says they have got it, and everybody else moves on.
It stops working the moment the team is bigger than a room. A shared queue with no owner produces two failure modes at once, and they look opposite. Either several agents open the same conversation and the visitor gets greeted twice, or everybody assumes somebody else has it and the request sits untouched while three people are technically available.
Automatic distribution replaces the social protocol with an assignment. New chats are handed to an available agent rather than offered to everyone, so a conversation has an owner from the first second. The setting lives on the Auto Routing page in your dashboard, alongside the agent and department lists it depends on, and it applies to new chats from the moment you save it.
That is the whole benefit, and it is worth being precise about it, because assignment is not the same thing as capacity. Routing decides who a chat belongs to. It cannot invent an agent who is not signed in. If your queue is long because two people are covering a launch, routing will distribute the same shortage more evenly and slightly faster. It will not fix it. The team-shaped problem stays a team-shaped problem, which is why the queue guide is the better read when the backlog is the symptom.
Auto accept is a commitment, not a convenience
The second setting decides what happens after a chat is assigned. By default the assigned agent still has to accept it, which means the conversation is reserved for them but not yet started. Auto accept removes that step: once the chat is assigned, it is accepted on the agent's behalf and the conversation opens.
Teams turn this on to save a click, and the click is not the point. The point is that accepting is the moment an agent takes responsibility for a specific visitor. When accepting is manual, an agent who is mid-sentence with somebody else can leave a new chat unaccepted and let it move on. When it is automatic, that judgement is gone. The chat opens whether or not the agent has a free hand.
So auto accept is a good fit for teams who work one conversation at a time and want the fastest possible first reply, and a poor fit for teams who routinely juggle several. If your agents already run parallel conversations, read handling multiple chats at once before switching it on, because auto accept raises the ceiling on how many a person can be holding without ever having agreed to any of them.
There is a simple tell that it was the wrong choice. If first response time improves but abandonment does not, chats are being accepted quickly and answered slowly. That is auto accept flattering the metric rather than helping the visitor.
The reassign timeout is the setting most teams get wrong
The third setting is a timeout in seconds, and it is the one that decides whether automatic distribution degrades gracefully. When a chat is assigned to an agent and nothing happens for that many seconds, the chat is reassigned so somebody else can pick it up.
Without it, assignment becomes a trap. The router picks an agent who is signed in but not actually at the desk, hands them the conversation, and the visitor now waits behind a person who is not reading. A shared queue would at least have let a colleague notice. An assignment with no timeout is a private queue of one, and nobody else can see into it.
Pick the number from the promise you make in the widget, not from a sense of fairness to agents. If your greeting implies somebody is there now, a reassign timeout measured in a small number of seconds is right, because the visitor's patience is the constraint. If your team handles considered, technical questions where a pause is normal, a longer timeout avoids bouncing a conversation away from the person who was about to answer it.
Two values are worth avoiding. Leaving it empty or at zero means no reassignment at all, which is the trap above. Setting it very short means chats hop between agents faster than anybody can respond, and the visitor sees the join and leave churn rather than an answer. If chats are moving more than once before anyone speaks, the timeout is fighting your staffing, and reducing chat transfers covers the downstream cost of that churn.
Sequencing the change so you can tell what it did
Auto routing changes who answers, which means it changes almost every number you might use to judge it. Turning it on at the same time as a staffing change, a new widget position, or a fresh set of invitations makes the result unreadable.
Change one thing. Enable distribution, leave auto accept alone, set a reassign timeout you believe you can staff, and watch a full week including your quietest day. The quiet day matters more than the busy one, because that is when a single distracted agent can absorb a chat and stall it, and it is exactly the case the timeout exists to catch.
Watch the pair of numbers together rather than either alone: how fast the first human reply arrives, and how many visitors leave before it does. Routing that improves the first and worsens the second has moved the delay rather than removed it. The metrics worth trusting for this are covered in the metrics guide.
It also pays to check the department and agent lists on the way in. Automatic distribution can only assign to agents it can see as available, so an agent in no department, or a department with nobody signed in during a shift, quietly narrows the pool. The Auto Routing page links straight to both lists for that reason.
When manual pickup is still the right answer
Automatic distribution is not strictly better. There are teams for whom the shared queue is the correct design, and it is worth recognising yourself in the list before changing anything.
- Very small teams who share a room. If two people can see each other, assignment solves a problem they do not have and removes flexibility they use constantly.
- Highly specialised queues. When the right answer depends on who is asking, a human glancing at the question routes better than a rule. Set up departments first and revisit routing after.
- Teams whose chats are long. If a typical conversation runs half an hour, being handed a second one is disruptive in a way that a queue is not.
For everybody else the honest summary is that automatic distribution removes an ambiguity, and ambiguity is what makes a queue feel slow even when it is short. If you want the whole picture of how chats reach the console before you change any of it, the agent console page covers what an agent sees when a conversation arrives.