What a missed chat actually is
A missed chat is not a chat. It is a record that somebody tried to start one and nobody was there. The visitor filled in whatever your pre-chat form asks for, pressed the button, waited, and left without reaching a person.
That distinction matters because the record is written from the visitor's side of the event. It captures what they told you before the silence, not what was said in a conversation, because there was no conversation. Treat the list as a queue of unanswered requests rather than as a report, and it becomes the most actionable screen you own.
Each row also fires an email to the address configured for your site, and, where you have the chat API switched on, raises an event your own systems can act on. So the list is a durable copy of something you were probably already notified about, which is exactly what you want three days later when the notification is buried.
What the record keeps, and where it stops
A missed chat row holds the time it began, the department and the agent it was aimed at, the visitor's display name and email, their IP address, browser, platform and locale, the question they typed, the page title and URL they were on, the referring page, and any custom field values your form collects.
Every one of those fields is stored to a fixed length and quietly cut at it. The question keeps its first thousand characters. Names and email addresses keep two hundred. The page URL, the page title and the referrer keep two hundred and fifty-five each, which is short enough that a long campaign URL with tracking parameters will lose its tail.
Nothing warns you that a value was shortened. If you are reading a row and a URL looks truncated, it is truncated, and the missing part is not recoverable from this screen. Where the full landing page matters to you, capture it into a custom field of your own rather than relying on the recorded URL.
Custom field values are kept twice, in an older short column and a newer long one, and the screen reads the long one. This is why an older export and a current view of the same row can disagree about how much custom data survived.
Why the same visitor does not appear five times
A visitor whose connection wobbles, or whose page loads your widget more than once, can generate the same unanswered request repeatedly. Left alone that produces a row, an email and an event for each attempt, which is how a single frustrated person becomes an apparent flurry of demand.
So repeats are collapsed. Within a ten minute window, a request that matches an earlier one on the visitor's identity, their contact details, their question and their department is treated as the same event and recorded once.
Read the shape of that key carefully, because it is what makes the rule safe. The question and the department are part of it. A visitor who comes back four minutes later and asks something genuinely different keys differently and is recorded again. Only a byte-identical repeat is folded away.
The window used to be two minutes and that was too short: real visitors retry on a slower rhythm than that, and a paid account was seeing duplicate notices three minutes apart. Ten minutes matches how people actually behave.
One practical consequence. The collapsing happens in memory on the server, so it resets when the application restarts. After a deployment or a recycle, the very first repeat of an in-flight request can slip through. If you see an isolated duplicate pair rather than a pattern, that is almost always what you are looking at.
Searching the list without misreading it
The screen opens on the last seven days. That default is a convenience, not a statement about your data, and it is the single most common reason somebody concludes they have no missed chats: they are looking at a week.
You can filter by date range, by department, by agent, by visitor name and by email address. The name and email filters match on any part of the value, so a partial address finds the row. The end of your date range is inclusive of the whole day, so an end date of today includes today.
The agent list is worth understanding. It is built from your current agents and it deliberately leaves out anyone who has been deleted. A missed chat that was aimed at somebody who has since left your team is still in the data, but you cannot select that person to find it. Widen the date range and drop the agent filter instead.
Results are newest first, twenty to a page.
The export gives you your filters, not your data
You can export as CSV or as XML. Both run the search that is currently set, not the whole table. The export button re-applies whatever is in the filter boxes at that moment and then writes the result.
That is easy to forget, and it produces the most common support question about this screen: an export that seems to be missing months of records is almost always an export of the default seven-day window. Clear the filters, widen the dates, run the search, look at the count, and then export.
For anything you intend to repeat on a schedule, an export you drive by hand is the wrong tool. Pull the same information through the integration routes built for reporting and let the screen stay what it is good at, which is working today's list.
There is a bulk delete, and it deletes every row your current filters match. Not the page you are looking at, and not the rows you have selected. The whole result set.
It refuses to run without a start date, which is a real guard against wiping the table with an empty form, and it cannot be undone. The safe sequence is always the same: set your filters, run the search, read the number of results, satisfy yourself that the number is the one you meant, and only then delete.
Most teams never need this. Missed chats are small rows and keeping them costs nothing, while the record of what you failed to answer in a bad week is worth having when you are arguing for more coverage.
Following up so it does not read like an apology
The follow-up that works opens with the visitor's own question, answered. Not an apology for missing them, not an explanation of your staffing, and not an invitation to start the conversation again from the beginning. They already told you what they wanted; the record in front of you is proof of that.
Use the page they were on. A missed chat from a pricing page and a missed chat from a delivery policy page deserve different replies, and the URL is right there in the row. This is the whole reason the page is captured.
Speed matters more than polish. A short, direct answer within the hour recovers a meaningful share of these; a beautifully written reply the next afternoon recovers very few. If your missed chats cluster in a predictable window, the answer is not a better template, it is a decision about that window. And if the misses are not clustered in time at all but spread evenly across weeks, suspect the alerting rather than the staffing: when your chat notification emails stop arriving describes the failure that produces exactly that pattern.
What to measure
Count missed chats against attempted chats, not against completed ones. The ratio you want is how often somebody who tried to reach you failed to, and completed conversations tell you nothing about the people who gave up.
Plot them by hour of day and by day of week before you plot anything else. Missed chats are almost never spread evenly, and the shape usually points straight at one uncovered hour rather than at a general shortage.
Then track what happens after the follow-up. A missed chat that turns into an answered email is a recovered conversation and should be counted as one. If you never measure the recovery, the list looks like a record of failure instead of a queue of second chances.