Connect visitors to your team

Enable a real follow-up route#

Human escalation is available with Business and Scale. An owner or admin opens Escalations and configures Human review email. Enter the Destination email, enable Enable automatic human escalation, and select Save settings.

The destination is one configured business mailbox for the workspace. Make sure the team monitors it. If escalation is disabled, the plan does not include it, or no destination is configured, the widget cannot submit a handoff through this route.

Set a truthful response expectation#

Custom handling guidance can explain when the assistant should invite human review. Use Response expectation (optional) only for a timeframe your business can meet, such as “Usually within one business day”. This is your business's stated expectation, not a Reesponder response-time guarantee.

The portal saves the supported human-request, refund, payment, legal, sensitive and other categories together. It does not provide individual category checkboxes. “Automatic escalation” can prompt the visitor to complete the form; it does not bypass their contact details or confirmation.

What the visitor confirms#

1. The visitor sends a message in the conversation.
2. They open Talk to the team, or the assistant offers that form when human review is appropriate.
3. They provide both Email address and Phone number.
4. They select Confirm & send request, agreeing to share the conversation and those contact details with the website's team.

Both contact fields are required. They are supplied by the visitor; this handoff flow does not verify email ownership with an OTP or validate the phone through a call or SMS. Sensitive business decisions still need your own checks.

Saved is not the same as delivered#

A submitted request is saved once for the conversation. The worker prepares a concise summary and emails it with the available conversation copy and contact details. Repeated checks or submissions reuse the existing request for that conversation.

Review and follow up#

Recent escalations shows the website, category, summary, time and delivery status. The visitor can use Check delivery status when a request has not yet been delivered. There is no live agent takeover or visitor reply composer in Conversations; the team follows up through the supplied contact channel.

If the form cannot submit, check that a visitor message exists, both contact fields are valid, the workspace configuration is enabled and the conversation is still available. For persistent email delivery problems, check the destination and contact Reesponder with the domain and request time, without sending credentials.

Handle the request copy responsibly#

The email includes visitor-supplied contact details and an available, bounded conversation copy. Treat it as context for follow-up, not proof of identity, record ownership or approval for a sensitive business decision.

Internal transcript-associated handoff contact and content payloads are scrubbed by conversation-expiry handling. Appropriate delivery metadata can remain. A copy already delivered to your business mailbox follows your own access and retention process; Reesponder does not remove messages inside that mailbox. Keep the website's ordinary contact route available for requests that cannot use the form.

Worked example: a delivery-change request#

A visitor asks to change an order's delivery address before dispatch. The assistant explains that the team must review it and offers the contact form. The visitor sends their request, provides both required contact fields and confirms sharing. The request email gives the team context without making the change itself.

The team checks who owns the order, whether dispatch has already occurred and which changes its fulfilment process allows. It then follows up through the supplied route. If the visitor's details do not establish ownership, the team asks for the appropriate verification through its normal process. A handoff avoids repeating the whole conversation, but it does not authorise or execute the delivery change.

When to repeat your handoff acceptance test#

Repeat the controlled test after changing the destination mailbox, response expectation or handling guidance, and after a relevant website installation change. Test the customer-visible form, saved request and external mailbox, not just the settings save. Confirm that the business's normal contact option remains usable too.

Keep an accurate record of the observed stage. “Request saved” is appropriate before delivery; “mail received by our team mailbox” is stronger evidence than a conversational promise. Only the business's actual response establishes that someone followed up. If the request cannot be sent, give the visitor a truthful alternative instead of promising an immediate agent takeover.

Design the offer around a team that can actually respond#

Choose which requests your business wants a person to review and write handling guidance with that purpose in mind. A payment dispute, a request involving judgment or a customer explicitly asking for a person are different from an ordinary opening-hours question. Guidance should help the assistant recognise those situations and explain the route clearly, while allowing routine supported questions to receive a useful answer.

Agree who monitors the workspace's destination mailbox, what information they need and what response expectation they can meet. One configured mailbox receives the workspace requests; the portal does not provide a per-category team routing editor. If several people cover the inbox, manage their responsibility in the business's own support workflow rather than assuming the conversation screen assigns a case.

Keep a normal contact route visible on your website as well. A visitor may be unable or unwilling to provide both required fields, the service may be unavailable or the request may need another channel. Tell them the real alternative and its hours where known. The chat handoff is a convenient request path, not proof that a human is present in the conversation at that moment.

Run one controlled end-to-end handoff#

Use a controlled conversation on the installed website and send a realistic test message first. Include enough non-sensitive context for the team to understand the issue. Open Talk to the team, provide your own test email and phone number, then confirm the sharing request. Test this on the website where customers will use it, not solely by reading the saved settings.

Check Recent escalations and the destination mailbox. Compare the received context with the test conversation: can someone understand the issue, find the supplied contact route and see what the visitor is asking them to do? The email contains a bounded available conversation copy and summary; it should not be treated as an unlimited complete archive. Use a long-test case only when the team needs to understand that boundary, and avoid populating it with personal customer information.

Have the responsible person follow the normal business workflow for answering the test. This verifies more than provider acceptance: the mailbox is monitored and its recipient knows what to do. Remove the external test email under your own mailbox policy when appropriate. Record the date, website and outcome of the test so a later destination or guidance change can be checked against the same workflow.

Diagnose the failing stage instead of resubmitting#

If the form rejects the request, check the conversation first. It needs a visitor message, an active eligible website installation and a conversation that is still retained. Confirm that the workspace's plan supports escalation, that it is enabled and that the destination email is configured. Then check both contact fields and the visitor's explicit confirmation. A plausible customer ID in a chat message cannot replace those form requirements.

If a saved request remains Pending or Failed, investigate delivery rather than asking the customer to send the same request repeatedly. The delivery worker retries eligible failures, but it cannot send an expired or invalidated conversation payload indefinitely. Repeated submission in the same conversation reuses the existing request instead of creating a new case. Use the current delivery state and safe request timing when contacting support.

If the email shows Delivered but the team did not see it, verify the configured mailbox, its spam or filtering rules and the people responsible for monitoring it. Provider acceptance does not prove a human read the message. If the contact details do not belong to the visitor, use your normal identity and record-ownership checks before disclosing information or acting on a sensitive request. The form collects details; it does not verify ownership by email code or phone challenge.