Live chat and handoff
Unanswered-chat fallback
If a live-assigned visitor receives no rep reply for 60 seconds, Stand pauses that rep’s new-chat availability and attempts a controlled recovery. It can continue with the rep’s Stand-in, transfer once to an eligible teammate, or collect an email address for follow-up.
- Availability
- All plans
- Configured in
- Automatic in an unanswered human conversation; status and alerts appear in Dashboard → Chats
- Category
- Live chat and handoff
- Reference status
- Current
When recovery starts
The timer applies after a visitor message is waiting on the assigned human rep. If the rep replies or otherwise resolves the pending state before 60 seconds, recovery does not replace the conversation owner.
When the timeout wins, Stand pauses the rep for new assignments. This protects later visitors from being routed to a person who is currently not answering while preserving the original conversation for recovery.
Fallback outcomes
| Available recovery | Visitor result |
|---|---|
| The assigned rep has an eligible enabled Stand-in | The Stand-in enters the same transcript, explains the connection trouble, and can answer or arrange follow-up. |
| An eligible teammate can accept the chat | Stand transfers the same session once, changes the visible human assignment, and alerts the teammate. |
| No live or AI recovery remains | Stand offers a visitor follow-up form so the visitor can leave an email address. |
Effect on the original rep
- New-chat availability is paused, but the rep’s saved concurrent-chat limit and explicit availability intent are retained for recovery logic.
- The dashboard can alert the rep that Stand paused them because a visitor did not receive a reply.
- Returning to a healthy Chats connection may restore availability when the pause was caused by reachability rather than an explicit manual off state.
- The existing unanswered conversation remains visible; recovery changes handling inside it rather than deleting it.
Visitor follow-up collection
The fallback form becomes active only when the recovery state is still pending. Stand claims one submission so retries or concurrent actions do not create duplicate follow-up handling.
The visitor’s email and request remain associated with the conversation and the responsible team can receive the follow-up notification. This fallback is separate from a Stand-in’s proactive Human follow-up skill, although both preserve a request for later human response.
Limits and race handling
- A late rep reply, teammate transfer, Stand-in recovery, and follow-up submission compete against the same recovery state so only a valid current outcome wins.
- The timeout does not end the conversation or consume a second chat.
- Team transfer is attempted once; Stand does not bounce the visitor repeatedly through teammates.
- Email follow-up does not promise an immediate response or verify the visitor’s identity.