Reroute on No Answer is a per-conversation timer available on every group's routing settings. It counts the time since an agent's last message inside one specific chat. If that timer runs out with no new message sent in that conversation, the agent is automatically removed from it, and your visitor sees a notice that the agent has exited.

It's easy to assume this means the agent lost their connection, went unavailable, or missed the chat entirely. It doesn't measure any of that. An agent can be fully connected, fully available, and actively working the exact chat in question, and still trigger this timer if they haven't typed anything back in that conversation within the set window. The timer only looks at message activity in that one chat, nothing else.

Why it exists

The purpose is straightforward: make sure a visitor never sits indefinitely with an agent who genuinely has stepped away or lost track of the conversation. Without a safeguard like this, a chat could sit open and unattended with no path back to another available agent. Reroute on No Answer gives every chat a maximum wait before it becomes eligible to be picked up again.

Where it's set

Under Workflows, then Routing, on each group, you'll find Reroute on no answer as a dropdown with a short list of timeout options, including "Do not re-route." This is a per-group setting, so different queues on the same account can use different values depending on how they typically operate.

Choosing the right timeout for your team

The most common way this setting causes confusion is when it's set shorter than the time your team actually needs to give a good answer. Some questions can be answered instantly. Others genuinely require checking a reference, confirming a detail with a colleague, or looking something up before replying accurately, and that can easily run past a short window.

When that happens, an agent who is doing exactly the right thing, taking the time to get the answer right instead of guessing, gets automatically pulled off the chat mid-conversation. To your visitor, it reads as the agent having left. The agent then comes back a few seconds after the timeout with a complete answer, which is a strong sign the timeout is too tight for that particular queue, not that anything is actually wrong.

A good approach: think about how long your team typically needs on the harder questions in a given queue, not the easy ones, and set the timeout with some real buffer above that. A queue that fields quick, straightforward questions can usually run a shorter window. A queue that regularly involves checking with someone else, or looking something up, will do better with a longer one.

What it isn't

Reroute on No Answer has nothing to do with an agent's connection quality, which browser or app they're using, or whether they received the incoming alert. Those are separate systems entirely. If you're troubleshooting a "the agent seemed to disappear" report from a customer, it's worth checking both: whether it happened at a consistent number of seconds into the conversation regardless of the customer's question (points to this timeout), or whether it happened at unpredictable times tied to a specific agent's sessions (points to a connection issue instead).

Related

• Smart Routing and Idle Escalation
• Automatic Chat Re-Routing