Configure dead-connection detection

When a visitor’s connection drops — they closed the laptop, walked away from Wi-Fi, the browser crashed — Atender notices that their widget stopped sending heartbeats and sends them a confirmation link, so the thread doesn’t die.

The link is the whole mechanism. Atender does not move the conversation on its own: it stays on web chat until the visitor opens the link from their own inbox (or their SMS app), and only then does it become an email or SMS conversation. A visitor who never opens it stays on web chat.

Important: this triggers on a dropped connection, not on inactivity. A visitor who’s reading the chat without typing is not idle from the widget’s perspective — they’re still connected, and their widget is still beating every 15 seconds.

This is also separate from what happens when a visitor collapses the chat panel. Dead-connection detection still handles actual lost connections after the configured timeout. But collapsing the panel affects live reply delivery right away: if the visitor has all chat tabs collapsed, human replies may fall back to email when Atender knows the visitor’s email address and your email domain is Active.

Before you start

• The widget exists. If not, create one first.
• Enable Channel Switching is on for this widget. It is the master switch — with it off, the lost-connection settings are hidden and the server ignores them even if they were saved earlier.
• The destination channel is configured for your workspace and can actually send: an Active email domain for email, or an SMS sender for SMS.
• Atender needs the visitor’s address on the conversation’s contact — usually collected by the pre-chat survey. Email needs a primary email address, SMS needs a primary phone number.

Steps

1. Open Settings → Web Chat and click your widget.
2. Open the Channel Switching tab.
3. Turn on Enable Channel Switching if it isn’t already.
4. In the Auto-Switch on Lost Connection block, turn the toggle on.
5. Set Switch Timeout (seconds) — how long the widget has to stay silent before Atender acts. The field accepts 300 to 3600 seconds, and 300 seconds (5 minutes) is also a hard floor on the server: anything lower is ignored. Short timeouts produce false positives, because browsers throttle background tabs to roughly one heartbeat a minute and may freeze them entirely.
6. Pick Switch To Channel — Email or SMS. Those are the only two options: WhatsApp has no confirmation-link sender, so it cannot be a switch target.
7. Customize the Warning Message — the banner the visitor’s own widget shows when its heartbeats start failing. Two placeholders are supported:
   {channel} — the target channel identifier (email or sms).
   {seconds} — a live countdown, starting at the timeout you set and ticking down once a second inside the banner.

The default is: Your connection appears unstable. We're switching this conversation to {channel} in {seconds} seconds to make sure you don't miss anything. Click "Stay in web chat" to cancel. 8. Save.

Verify it worked

Open the widget, start a conversation that has an email address on it, then take the device offline (airplane mode, or turning off Wi-Fi) while leaving the browser open.

• In the widget: after two failed heartbeats — about 30 seconds — a yellow banner appears above the messages with your warning message and a Stay in web chat button. Note what that button does and doesn’t do: it hides the banner and resets the widget’s failure count, but it does not cancel anything on the server. When the countdown reaches zero the banner turns blue and claims the conversation has been switched — that text is written by the widget locally, not by the server, and the conversation has not moved.
• In the inbox: once the widget has been silent for the timeout, the conversation shows a Customer disconnected — connection lost banner, and then a Waiting to confirm Email (or SMS) badge once the link goes out. The warning message never appears in the conversation history — it only ever exists as a banner in the visitor’s browser.
• In the visitor’s inbox: an email with the subject Confirm your email address containing the link. It expires in 24 hours. The conversation moves to email only when they open it.

How it differs from manual channel switching

• Who triggers it — The visitor clicks a button and gives an address — Atender detects the missing heartbeats
• When it fires — Whenever the visitor wants — After the configured timeout
• Where configured — Channel Switching tab, Availability section — Channel Switching tab, Auto-Switch on Lost Connection section
• Address used — The one the visitor types — The primary address already on the contact
• What happens next — A confirmation link is sent; the conversation moves when it’s opened — The same

Both live under the same Enable Channel Switching master toggle, both are limited to email and SMS, and both wait on the link. Only one link is live per conversation at a time: a new one retires the previous one, and while a link is still live a repeat disconnect does not send another.

Collapsed chat panels are a third case. If a visitor is connected and reading with the panel open, dead-connection detection does not fire just because they are not typing. If the visitor collapses every chat tab, Atender may deliver human replies by email immediately when an email address is known, instead of waiting for the dead-connection timeout.

Choosing the target channel

• Email is the recommended default and the more forgiving one — the visitor doesn’t need to be reachable instantly, they can open the link hours later, and it doesn’t cost a message send.
• SMS is worth it when the conversation was urgent and the visitor probably wants to keep going. The link is texted to the primary phone number on the contact, so the widget needs to have collected one.

WhatsApp is not selectable here, and a widget still holding a saved WhatsApp target from an older configuration is skipped entirely — the disconnect is recorded and the conversation stays on web chat.

Limits

• Atender only sends a link to an address it already has. If the conversation’s contact has no primary email address, an email target sends nothing; the same applies to SMS and a phone number.
• The visitor must have completed the pre-chat survey or otherwise supplied the relevant contact information.
• Only conversations that are still active and still on web chat are considered.
• While an Agent Stack is actively assigned to the conversation, the sweep skips it and leaves the stack’s own inactivity rules in charge.
• The conversation never moves without the visitor. There is no setting that makes the switch happen automatically.

Troubleshooting

• Symptom: Nothing happens on test disconnects. Fix: Check Enable Channel Switching first — the lost-connection toggle does nothing without it. Then confirm the timeout: the floor is 300 seconds, and anything lower is ignored. Then confirm the contact has a primary address for the target channel.

• Symptom: The Customer disconnected banner appears, but the conversation doesn’t move to email. Fix: That is the designed behaviour — the conversation waits for the visitor to open the confirmation link. Check the inbox for the Waiting to confirm Email badge: if it isn’t there, no link was sent, and the cause is a missing address on the contact or a target channel your workspace can’t send on.

• Symptom: The confirmation link never arrives. Fix: Confirm the Email channel is set up and a domain is Active (or, for SMS, that an SMS sender is configured). A workspace with no working sender on the target channel sends no link at all.

See also

• Configure channel switching
• Add a pre-chat survey
• Verify the address before a channel switch