There is a setting that emails you a copy of the conversation every time a chat finishes. It is one of the quieter features in the product and one of the most frequently misused, because it looks like a backup and behaves like a notification.
Turned on deliberately, it is genuinely useful. Turned on reflexively, it produces a mailbox nobody reads and a second copy of every customer conversation in a place your retention policy does not reach.
Why teams turn this on
Three reasons come up repeatedly, and only two of them are good.
Oversight on a small team. A manager who is not in the console all day wants to see how conversations are going without logging in to look. For a team of two or three agents handling a handful of chats a day, an inbox copy is a reasonable way to stay close to the work.
Feeding another system. The email is a convenient way to get transcripts into a shared mailbox, a ticketing system that ingests mail, or a CRM that files correspondence against a contact. This is the strongest use, because something downstream is actually consuming it.
As a backup. This is the bad reason, and the rest of this guide explains why: the email is conditional in several ways, and a conditional copy is not a backup. Your conversations are already stored and searchable in the product. The email adds a second copy in a less controlled place, not a safety net.
Four conditions for it to arrive
Four things all have to be true. Any one of them missing produces silence rather than an error, which is why the most common support question about this feature is why nothing arrived.
- The setting is on. The end-of-chat report is a distinct toggle, separate from the transcript an agent can send to a visitor by hand.
- There is at least one recipient address. The toggle and the address list are two separate fields, and turning the toggle on without filling in an address sends nothing. There is no fallback to your account email.
- The account is on a paid plan. On a free account the email does not send regardless of the settings.
- The conversation contains messages. An empty session — a visitor who opened the widget and closed it without typing — never produces an email.
If you are debugging a missing transcript, check them in that order. The address field is empty far more often than anything else is wrong, because the toggle looks like the whole setting.
When it fires, and what is in it
The email goes out when the conversation is finalised at the end of the session, not when the visitor closes the window. Those are usually seconds apart and occasionally are not, so a transcript arriving a little after you expected it is normal.
The message contains the conversation in chronological order, oldest message first, along with the session's visitor details. It uses its own template, separate from the transcript an agent sends to a customer — which is worth knowing, because editing the customer-facing transcript wording does not change what lands in your inbox. Both are editable, but they are two different pieces of copy. The guide on customizing chat emails covers which is which.
Why you do not get duplicates
A chat session can be finalised more than once in edge cases — a reconnect, a browser crash, an agent closing a conversation that was already closing. Without a guard, each of those could produce another copy of the same conversation.
The guard is a message count. The system remembers how many messages were in the session the last time it emailed a transcript, and it only sends again if the conversation has grown since then. A re-finalisation with no new messages sends nothing.
This has a pleasant secondary effect. If a conversation genuinely resumes and more is said, you get an updated transcript containing the whole thread rather than a fragment of the new part. What you will not get is the same conversation twice.
The ceiling, and what happens at it
There is a safety ceiling on outbound chat mail per account, counted in a rolling one-hour window and covering transcripts and related notifications together. It is high — well into the thousands per hour on a paid account — so a normal support operation will never approach it.
Two things are worth knowing about it anyway. The limit exists to bound a runaway loop rather than to ration ordinary use, so hitting it is a signal that something is wrong rather than that you are busy. And because the window resets as it rolls, exceeding it suppresses mail for a period rather than switching the feature off permanently.
If you are running an unusually high volume of short conversations — a launch, an incident, a campaign that drives thousands of sessions in an afternoon — that is the situation where a per-chat email is the wrong tool anyway. See the next section.
It is a notification, not an archive
Everything above adds up to one conclusion. This feature is conditional on plan, on configuration, on the conversation being non-empty, and on a volume ceiling. Those are all reasonable behaviours for a notification and disqualifying ones for an archive. Your stored chat transcripts remain the authoritative record.
The practical test is volume. Below roughly a few dozen chats a day, an inbox copy is readable and somebody will actually read it. Above that it becomes a folder with a filter pointed at it, which is a strictly worse version of the search that already exists in the product — slower, harder to filter by agent or outcome, and impossible to report on.
If your goal is review rather than awareness, sampling beats streaming. Pulling five conversations a week deliberately teaches you more than receiving four hundred and reading none, and the guide on transcript review is built around exactly that.
Every copy inherits your retention problem
This is the consequence teams notice last and regret most.
Your chat transcripts have a retention period. Whatever that period is, an emailed copy does not obey it. Those messages sit in a mailbox, get forwarded, get backed up with the rest of the mail system, and outlive the originals by years. If you have committed to a deletion window in a privacy notice or a contract, a per-chat email quietly undermines it.
Two habits keep it manageable. Send to a shared, purpose-built mailbox rather than to individual people, so there is one place to apply a rule instead of a dozen inboxes to chase. And give that mailbox a deletion rule matching your transcript retention period, set at the same time you enable the feature rather than as a task for later. The guide on transcript retention goes into the wider version of this problem. Before either habit helps, the mail has to arrive at all, and when your chat notification emails stop arriving covers the case where a suppressed address has been swallowing them silently for weeks.
If you cannot apply a retention rule to the destination, that is a reason not to turn the feature on.
Put it into practice
- Fill in the recipient list, not just the toggle. An empty address list sends nothing and reports nothing.
- Send to one shared mailbox rather than to several people, so retention can be applied in a single place.
- Set the mailbox deletion rule the same day you enable it, matching your transcript retention period.
- Decide who reads it and when. A copy nobody opens is pure liability with no oversight benefit.
- Switch to sampling above a few dozen chats a day. Streaming everything stops being review at that point.
- Do not treat it as a backup. It is conditional in four ways; the product's own records are the source of truth.
Used as a notification into a mailbox that something downstream consumes, this is a small, well-behaved feature. Used as an accidental second archive of every customer conversation you have ever had, it is the kind of thing that turns up in a privacy review years later. The setting takes a minute; the decision about where it sends deserves longer.