Every time your AI chat stops answering and passes a visitor to a person, a row is written. Over a few weeks that log becomes the most honest description you have of where your AI ends and your team begins.
It repays careful reading, because two of the numbers on the summary panel are counted over different periods, and one of the three headline reasons is not what its name suggests.
What the log records
Each handoff row carries the session it belongs to, the visitor name and email if they were captured, the reason for the handoff, a short summary of the conversation, a status, the agent who picked it up, any error text, and the time it was created.
The summary is the useful part and the part people skip. It is a condensed account of what the visitor was trying to do at the moment the AI gave way, which makes the log readable as a list of problems rather than a list of events. You can open the underlying transcript from a row when the summary is not enough.
Rows are listed newest first and paged, twenty at a time. There is a CSV export, and it is worth knowing exactly what it hands you: it honours whatever reason filter and search text are set at that moment, and it stops after a few thousand rows. An export is therefore a snapshot of your current view rather than a complete extract, so clearing the filters first is usually what you actually meant to do. For a standing feed rather than a one-off pull, the reporting routes built for it are the better path.
The three reasons, and what each one means
The summary panel counts three categories, and they are genuinely different kinds of event.
Visitor requested means somebody asked for a human. This is the healthiest reason on the list and the one teams most often misread as a failure. A visitor who knows they can reach a person, asks, and gets one has had a good experience. Counting it as an AI failure pushes you towards making the escape hatch harder to find, which is the wrong direction.
AI recommended means the assistant itself judged that the conversation should go to a person. This is the number that tells you whether your scope is set sensibly. A high and steady figure usually means the AI is being asked questions you never intended it to answer, which is a content and scope decision rather than a model one.
AI error is the one to read carefully, and it gets its own section below.
The reason filter on the list is built from the reasons actually present in your own data, most frequent first, so it will only ever offer you categories you really have.
Two different clocks on one screen
The panel shows a total, a last-seven-days figure and a last-thirty-days figure. It also shows counts for the three reasons above, and for the top reason overall.
The reason counts are all-time. The seven and thirty day figures are windows. They sit next to each other and they do not describe the same period.
This matters the moment you try to do arithmetic across them. Your visitor-requested count includes every such handoff since you switched AI on; your thirty-day count includes every handoff of any kind in the last month. Dividing one by the other produces a ratio that means nothing, and it will look plausible enough that nobody questions it.
If you want a reason mix for a period, read it off the filtered list for that period rather than off the summary cards.
Nobody was available is not an AI error
The AI error counter is not purely a count of AI errors. It combines genuine error conditions with handoffs where no agent was available to receive the visitor.
Those are different problems with different owners. A real error is something to investigate in the AI configuration. No agent available is a staffing fact: the AI did its job, decided a human was needed, and there was no human. Nothing was broken except the roster.
The distinction changes what you do next. If the counter is climbing, look at the individual rows and separate the two before drawing any conclusion, because the fixes point in opposite directions. One sends you to your prompt and your content; the other sends you to your schedule, or to a smaller set of hours you can genuinely cover.
A steady stream of no-agent handoffs outside your hours is also a sign that the AI is being asked to hand off at times when handing off is impossible. That is worth designing around rather than counting.
The timestamps are UTC
Handoff times are recorded and displayed in UTC, to the minute. They are not converted to your local time and there is no timezone selector on the screen.
For a team sitting far from UTC this is a real trap when you are correlating a handoff with something else. A spike that looks like it happened in the early hours may be your busiest afternoon; a quiet overnight stretch may be your morning. Work out your offset once, write it on the wall, and apply it every time.
It also means that when you compare this log against a report that does show local time, the two will disagree about which day a late-evening handoff belongs to. That is one more reason to read the log for individual conversations and use purpose-built reports for trends.
What the search box actually searches
Search matches on the visitor name, the visitor email, the handoff summary, the session id, the agent name, and any error text. It is a substring match, so partial words work.
It does not search the conversation transcript. This is the single most useful thing to know about the box, because a phrase you clearly remember the visitor typing will return nothing if it never made it into the summary. If you are hunting for a conversation by something that was said in it, search built for that is the right tool.
The search and the reason filter combine rather than replace each other, so an empty result is often a filter you forgot was set rather than an absence of data.
The readiness panel, and what it is really checking
Alongside the log is a readiness panel that answers a narrow question: is handing off to a human possible at all? It checks that AI chat is switched on, that handoff is not explicitly disabled, that a provider key is configured where your setup needs one, and that billing is in a state that allows the assistant to run.
Note the shape of the handoff check: it is on unless it has been explicitly turned off. Consistent with the rest of the AI chat settings, an unset value means nobody has configured it rather than off.
The panel also offers a preview that generates a handoff summary from a sample conversation, so you can see the shape of what an agent will receive. Be aware that this makes a real call to the AI service using your configuration, so it consumes usage exactly as a live conversation would. Paste in a transcript of your own to see something representative, or leave it empty and it will use a built-in example.
What to measure
Track the three reasons separately and never as a single handoff rate. A rising visitor-requested count with a flat AI-recommended count is a different story from the reverse, and one aggregate number hides both.
Read the summaries in batches rather than one at a time. Twenty summaries read in one sitting will show you two or three recurring themes that no counter surfaces, and those themes are the actual work: content to write, scope to adjust, or a question your AI should stop attempting.
Then watch what happens after the handoff, because a handoff is only the halfway point. The measure that matters is whether the visitor was helped once they reached a person, and that lives in your conversation history rather than in this log.