What gets measured
Adding chat to a website creates a promise: someone is here. Response-time reporting is how you check whether you are keeping it. onmsg reports over 7-, 30- and 90-day windows, and each window covers the same set of figures, first human response times, response coverage including unanswered conversations, average, median and 90th-percentile timing, resolution timing for eligible resolved conversations, and first-responder breakdowns with daily rows.
The definitions matter more than the charts. A first human response is a reply from a person. Bot messages do not count, and neither do private notes, so the number tells you when a human actually engaged rather than when the widget said something.
Common problems this solves
“Our average response time looks great and customers still complain.” Coverage and the 90th percentile usually explain it. A handful of instant replies pulls the average down while a slow tail, or a set of conversations nobody answered at all, does the damage.
“We don’t know if anything got missed.” Response coverage counts the unanswered conversations rather than quietly dropping them from the denominator.
“We can’t tell whether Tuesdays are the problem.” Daily rows show the shape of the window, and first-responder breakdowns show who is carrying it.
“We closed the ticket but the customer waited three days.” First response and resolution timing are separate figures for a reason. A fast acknowledgement and a slow resolution are two different problems.
Reading the numbers honestly
Three boundaries are worth holding in mind. The reports use elapsed time in UTC, not business hours, an enquiry that arrives at 10pm and is answered at 9am reads as eleven hours, not as a same-morning reply. They are not contractual SLA reporting, and nothing here should be presented to a customer as one. And they draw on retained history, so your plan’s retention setting decides how far back a window can genuinely reach.
None of that makes the numbers less useful. It makes them comparable week to week, which is the property you actually need when you are trying to work out whether last month was better.
Where this fits
Reporting only means something once conversations are flowing through the Shared Team Inbox, since that is where a human response happens. If your first-response numbers are worse than you expected, the usual fixes are upstream: better after-hours handling in the chat widget, or a grounded AI agent answering more of the repeat questions so the queue is shorter when a person opens it.
When you need this, and when you don’t
Reporting is most useful once two things are true: enough conversations are reaching people that a pattern exists, and more than one person is answering. Below that, you already know what happened. You were there.
The moments it earns its place:
After adding chat to a busy site. Volume changes behaviour, and the first month is when coverage problems appear.
When you add a second or third person to the inbox. The first-responder breakdown shows how the load is actually distributed, which is rarely how anyone assumed.
Before and after a change. Added an offline path, moved twenty answers into the knowledge base, changed who covers mornings, the 30-day window either moved or it did not.
When someone says replies are slow. An impression is hard to argue with. Coverage and the 90th percentile are not.
Reading it without punishing anyone
One caution worth stating. Because timing is elapsed UTC on retained history, the numbers include your nights, weekends and holidays. A team that answers every enquiry promptly during working hours will still show long response times if enquiries arrive at 2am.
Used as a management metric without that context, the report will make a good team look bad and push people toward answering fast rather than answering well. Used as an operational instrument (where are conversations being missed, which window is uncovered, is the tail getting worse) it is genuinely useful. The difference is entirely in how it is read.
For the detail, read what the response-time reports measure and reading first-response, coverage and resolution timing.
