Follow up by email when a visitor leaves the chat

The chat widget can now collect a visitor's email, and your team's replies reach them by email if they've left the chat. When they reply to that email, it lands back in the same conversation.

How it behaves

• Asking for an email: choose "Ask inline" (after Aide's first reply, and visitors can skip it), "Ask before the chat starts" (required to send the first message) or "Don't ask". Even with "Don't ask", a handoff still asks when your Handoff settings say to. While a person is on the conversation, only the handoff ask applies, so a visitor who skipped it isn't asked again.
• Answering in the chat: Aide asks in the conversation and the visitor types their email in the message box, like any other reply. If they write something else instead, it goes through as a normal message and the question stays until they answer, tap "Not now", or give their email in a sentence (below). The question and their answer are saved in the conversation, so your team reads the exchange in the thread. A visitor who mistyped it can send the right address straight after (or tap "Change"); the new address replaces the old one and shows in the thread as their message.
• An email inside a message (added 2026-10-18): when a visitor with no email saved writes it in a sentence ("send this to my email: name@example.com"), it is saved as their email, as if they had answered the question, and Aide still answers the message. The question goes away, and Aide's reply can say the address is saved instead of saying it can't use it; it never offers to email a copy of the chat. Nothing is saved from a message with two different addresses or with attachments, and an email the visitor already gave, or one your site sets with a signature, is never replaced this way. No confirmation is posted: Aide's own reply answers the message.
• Confirming the email: as soon as the visitor answers, Aide confirms in the chat, in the widget's language: at a handoff "Thanks! Our team will reply to (their email), even if you close this chat.", with an invitation to add details so the team can get started; outside hours that you'll reply as soon as you're back; after the follow-up question "Thanks, we'll email you at (their email) if you step away." The confirmation is a fixed message, not an AI reply: it is never billed, and it doesn't answer the conversation for your team, which still needs a person with its waiting time and SLA running. Copilot doesn't write a draft for a message that only gives an email. A corrected address isn't confirmed a second time.
• When a teammate takes over or you're offline: the widget asks for an email so the team can reply after the visitor leaves.
• Replies by email: a teammate's chat reply is emailed to the visitor if they haven't read it within 15 minutes, or about a minute after they close the chat. Replies they've already read in the chat are never emailed.
• Replying from email: the visitor's email reply is added to the same conversation, so the thread stays in one place. They come from your connected mailbox; without one, they come from aide's shared address under your brand name, with replies routed back to you.
• Changing an email: visitors can fix a typo during the same visit. Changing an address saved on an earlier visit needs a code sent to the current address, plus one sent to the new address if the current one was verified. Visitors your site identifies with a signature can't change their email in the widget.

Also in this change

• The question saved in the thread is in the visitor's language, with your wording for that language, as the widget showed it. It used to be saved in English.
• The "Offer transcripts by email" setting in Aide Chat > Behaviour is hidden until chat transcripts exist (2026-10-18): turning it on never sent visitors a copy. Your saved choice is kept.

For developers

• Widget config: emailCapture is inline, before_start or off.
• WireConversation.emailRequest (follow_up, handoff or offline) tells the widget when to ask for an email.
• New widget endpoints: PUT /widget/visitor/email, POST /widget/visitor/email/change, POST /widget/visitor/email/change/confirm, and PUT / DELETE /widget/conversations/{id}/email-request to answer or skip the conversation's ask. POST /widget/conversations accepts email, and returns 422 email_required when the widget asks before the chat starts.
• Answering the ask posts Aide's confirmation as an ai message after the visitor's answer. A POST /widget/conversations/{id}/messages whose text is only an email address, sent while the conversation has an emailRequest, answers it the same way (the email is saved, the response is the visitor's message). Since 2026-10-18 any other message from a visitor with no email that contains exactly one address (and no attachments) saves it the same way, before Aide's reply is queued, and goes out as an ordinary message. An email the visitor can't set from the chat is left as it is; the message is never refused for it.
• behaviour.transcriptsByEmail is still accepted and returned on /v1/widgets, but nothing reads it.
• An unsigned Aide('identify', { email }) sets the email when the visitor has none and keeps the one it set up to date. It no longer replaces an email the visitor typed or confirmed. Send a hash to always apply your email.

All changes