A date range is two days, and both are counted
The range picker above each chart sends two dates — a start and an end, both as plain calendar days with no time attached. The obvious worry about a range like that is the last day: if the end is read as midnight, everything that happened on the final day falls outside it, and every report you run is silently missing today.
That does not happen here. Before the query runs, the end date is expanded to the last second of that day. A range of the first to the seventh includes everything that happened on the seventh, right up to the end of the evening.
It is worth knowing that this expansion happens down in the storage layer rather than in the screen, because it means every chart gets it whether or not its own code remembered to. One of the charts does the same expansion again on the way in; the result is identical, and the redundancy is harmless.
The practical version: both endpoint days are included, always. A range of a single day — the same date at both ends — is that whole day, not an empty window.
Every chart is keyed on when the chat began
A conversation occupies a span of time, so any daily chart has to choose a moment to file it under. All of these charts choose the moment the chat started.
So a chat that opens at ten to midnight on Tuesday and runs until quarter past midnight counts entirely as a Tuesday chat, including the part of it that happened on Wednesday. The same logic applies at the edges of your range: a conversation that started the evening before your start date does not appear at all, even if most of it happened inside the range.
This is the right default — demand arrives when the visitor arrives, and staffing decisions follow arrival — but it does mean two things. Late-night volume is understated on the following day, and a range that starts on a Monday genuinely starts at Monday morning rather than sweeping up the tail of Sunday night. If you are looking at coverage across a boundary like that, widen the range by a day rather than trying to reason about the edge.
The chats chart and the ratings chart do not count the same chats
This is the one that surprises people, and it is the reason two numbers on the same dashboard, for the same week, can honestly differ.
The chats chart counts only sessions whose recorded end is later than their start — sessions with some elapsed duration. A session row that was created and closed at the same instant, with nothing in between, is excluded. Those exist: a connection that dropped as it opened, a visitor who closed the tab in the same second, a session created by machinery that never became a conversation.
The ratings chart applies no such filter. It groups every session in the window by the rating it carries, including the ones with no elapsed duration, which land in the unrated column along with the far larger number of genuine conversations nobody rated.
So the total across the ratings chart for a given day can exceed the bar on the chats chart for the same day. Neither is wrong. They are answering different questions — one is how many conversations happened, the other is what happened to every session we recorded — and the difference between them is a small, mostly uninteresting population of empty sessions.
The consequence for you is narrow but real: do not compute a rating rate by dividing a ratings-chart number by a chats-chart number. Their denominators are not the same set. If you need a defensible rate, take both numbers from the same chart, or take them from an export where you can see the rows. Exporting your chat history covers that route.
The per-agent chart follows a field, not a conversation
The per-agent chart asks a different question again: for each agent on your account, how many chats a day. It applies the same elapsed-duration filter as the chats chart, so its bars are drawn from the same population.
What it attributes on is the agent recorded against the session. That is a single field, not a history — so a conversation that was transferred, or that two people worked on, counts once, against whoever the field ends up naming. There is no partial credit and no double counting.
For most teams that is exactly what you want and the distinction never comes up. It starts to matter when transfers are routine: a specialist who receives escalations will look busier in this chart than the generalist who handled the first half of every one of those conversations. If transfers are a meaningful part of how you work, read this chart as who finished rather than who worked, and get the fuller picture from the transcripts themselves.
The chart also lists every agent on the account, including ones with no chats in the window, which is a feature rather than an oversight — a flat line for somebody who was rostered is information.
The hours chart is twelve buckets, not twenty-four
The hours chart covers a single day and shows when chats started. It does not have one column per hour: hours are paired, so midnight and one o'clock share a column, two and three share the next, and so on, giving twelve columns across the day.
That is a deliberate smoothing choice, and it is usually the right one — single-hour buckets on a normal day's volume produce a spiky chart that invites reading noise as pattern. But it does mean you cannot use this chart to answer a question with an hour's precision. If somebody asks whether the rush starts at nine or at ten, this chart cannot tell you; the pair covering nine and ten is a single number.
Like the daily charts, it counts by start hour and applies the elapsed-duration filter, so it is consistent with the chats chart above it. If you need genuine hourly resolution for a staffing decision, that belongs in an export rather than in this chart — and the chat reports and analytics screens are the place to start looking for the shape of the data you would need.
Whose clock the days are drawn in
The presets in the range picker — last seven days, this week, last month — are computed from the server's own clock at the moment the page renders, and the dates you type are read in that same clock rather than in your own.
For most accounts that difference never surfaces, because the chat rows being counted were written by the same clock. The daily boundaries are self-consistent even when they are not your local midnight, which is what matters for comparing one week to another.
Where it does surface is when you put a chart next to something counted differently — an AI usage figure counted in UTC, or a spreadsheet your finance team keeps in local time. Two correct numbers built on different midnights will not reconcile, and the reconciliation is not worth attempting at the day level. Compare weeks or months, where a few hours of boundary drift is lost in the noise.
If the timestamps you see on individual conversations look shifted rather than the totals, that is a different and better-defined problem — why your timestamps need a region, not just an offset covers the setting that fixes it.
One last practical note on typing dates by hand: the field accepts a range of formats, and an all-numeric date is read in the international order, day and month behind the year. If you type an ambiguous form, use the picker instead of guessing which way it will be read.
What to check before you quote a number
Three questions, in this order:
- Which chart is this from? The chats, per-agent and hours charts share one population; the ratings chart uses a wider one. Numbers from different charts are not interchangeable.
- Does the range cross a boundary you care about? Chats are filed on the day they started, so a late-night pattern needs a range chosen with that in mind.
- Is this a rate? If so, both halves must come from the same source. Ratios assembled from two charts are the most common way a dashboard number becomes quietly wrong.
None of this makes the charts unreliable. It makes them specific, which is a different thing — and specific numbers survive being questioned by somebody who was not in the room. Getting live chat data into your own reporting is the next step when the question outgrows what a chart on a screen can settle.