What the Response-Time Reports Measure
Understand onmsg's response-time reporting scope: retained history and elapsed UTC time, with bot messages and notes excluded from first human response.
Definitions before dashboards
A response-time number is only useful if you know what it counted. The Response-Time Reporting in onmsg reports over 7-, 30- and 90-day windows, and this guide is about what sits behind those figures.
First human response means a human
The headline metric is the time from a visitor’s message to the first reply from a person.
Bot messages do not count. An AI answer is valuable, and it is not a human response. If automated greetings counted, every conversation would show a two-second response time and the metric would be worthless.
Private notes do not count. A note is internal. Writing one is not answering the customer.
That leaves a number that means what it says: how long someone waited for a person.
Coverage includes what you missed
Response coverage is the share of conversations that received a human response, counted against all conversations in the window, including the unanswered ones.
This is the honest counterpart to an average. A team that answers ten conversations in ninety seconds and ignores five has an excellent average response time and a coverage problem. Reporting them together is the only way to see both.
Average, median and 90th percentile
All three appear, because each hides something the others show.
The average is pulled around by outliers in both directions. The median describes the typical case. The 90th percentile describes the slowest tenth, which is much closer to how a reputation actually forms. Nobody complains about the median.
If your average looks good and your 90th percentile looks bad, you have a tail problem: most conversations are fine and a few are being left. That is a scheduling issue, not a speed issue, and it needs a different fix.
Resolution timing is separate
Resolution timing is reported for eligible resolved conversations. It answers a different question from first response: not how fast someone replied, but how long the whole thing took to close.
Fast first response with slow resolution is a real pattern, and it usually means acknowledgements are happening but the work behind them is queuing. That is worth knowing separately.
Elapsed UTC time, not business hours
The reports use elapsed time in UTC. There is no business-hours calculation.
The practical consequence: an enquiry that arrives at 10pm and is answered at 8am reads as ten hours, even though your team responded at the first opportunity. Nothing is wrong with the team or the number, the number is measuring wall clock, and it says so.
Compare like with like. Week against week, month against month, and the trend stays meaningful even though the absolute figures include your nights.
Retained history sets the limit
Reports draw on retained conversation history, and retention is set by your plan. A 30-day retention setting means a 90-day window can only reflect what is still retained.
If long-range reporting matters to you, that is a plan decision to make deliberately rather than discover when a quarterly report comes back short.
Not an SLA
Stated plainly because it matters: this is not contractual SLA reporting, and these figures should not be presented to a customer as a service level. They are an operational instrument for your team, measured on wall-clock time against retained history.
Why the exclusions matter
Two exclusions do a lot of quiet work, and both are worth understanding rather than accepting on faith.
Bot messages are excluded because including them would make the metric meaningless. An automated greeting fires in under a second on every conversation. If it counted, every team on earth would report a sub-second first response and nobody would learn anything. The number exists to measure human availability, so it counts humans.
Private notes are excluded for the same reason at a smaller scale. Writing an internal note is work, and it is not a reply to the customer. A team that annotates carefully should not appear faster than one that answers.
Together these two rules are why the figure can be uncomfortable and why it is useful. It measures what a visitor actually waited for.
Using the numbers without misusing them
A response-time report is an operational instrument. Three habits keep it that way.
Compare to yourself. Your own previous month is a meaningful benchmark. An industry figure quoted at a conference is not, because you do not know how it was calculated.
Read coverage alongside speed. Speed on its own can improve simply because you answered fewer conversations.
Do not publish these figures as a service commitment. They are elapsed UTC time on retained history, not a business-hours calculation and not an SLA. Presenting them as one creates a promise the measurement was never designed to support.
Read next: reading first-response, coverage and resolution timing, or how the shared inbox routes and assigns conversations.
Learn more about Response-Time Reporting
Reports over 7/30/90-day windows covering first human response, coverage, percentile timing, resolution timing, and first-responder and daily breakdowns.
Questions people ask about this
Do bot messages count as a first response?
No. Only a human reply counts as a first human response. Bot messages and private notes are excluded, which is what makes the metric mean something, an automated greeting is not the same as someone answering.
Is this SLA reporting?
No. The reports use elapsed time in UTC on retained history, not business hours and not a contractual service level. Do not present these figures to a customer as an SLA, because they were not calculated as one.
What windows are available?
Seven, thirty and ninety days. Each window covers first human response, coverage including unanswered conversations, average, median and 90th-percentile timing, resolution timing for eligible conversations, and first-responder and daily breakdowns.
Want to try this on your own site?
No credit card required.