# Read First-Response & Resolution Reports | onmsg > How to read onmsg URL: https://onmsg.app/guide/reading-first-response-coverage-and-resolution-timing/ Last-Modified: 2026-09-08 Guide # Reading First-Response, Coverage and Resolution Timing How to read onmsg's report rows: first-response times, coverage and unanswered conversations, average/median/90th-percentile timing, and resolution figures. Published September 8, 2026 · 4 min read ![A report dashboard with first-response and resolution rows](/images/featured/modern-3d-illustration-of-a-report-dashboard-with-.webp) ## Read it in this order A Response-Time Reporting [/features/response-time-reporting/ →](/features/response-time-reporting/) window gives you several numbers, and they are not equally urgent. Read them in the order below and you will find the real problem faster. ![An annotated report row explaining each metric column in plain language](/images/content/annotated-report-row-explaining-each-metric-column.webp) ## 1\. Coverage first Start with coverage, because everything else assumes someone answered. Coverage is the share of conversations that received a human response, counted against all conversations in the window including the unanswered ones. If coverage is low, no amount of good timing elsewhere matters. You are fast for the people you reply to and absent for the rest. Low coverage almost always has one of two causes: conversations arriving outside the hours anyone is watching, or conversations that nobody claimed because ownership was unclear. The first is fixed with after-hours handling; the second with assignment discipline in the inbox. ## 2\. Median, then 90th percentile The median tells you what a typical visitor experienced. Read it before the average, which is easily distorted in both directions. Then the 90th percentile, which describes the slowest tenth. The gap between these two is the most informative single thing in the report: - **Median good, 90th percentile good**: consistent. Move on. - **Median good, 90th percentile bad**: a tail problem. Most things are fine and a few conversations are being abandoned, usually at particular times of day. - **Median bad, 90th percentile bad**: a capacity or coverage problem across the board. A tail problem and a capacity problem need different responses, and the average alone cannot distinguish them. ## 3\. Resolution timing Resolution timing covers eligible resolved conversations, and it answers a different question: how long the whole thing took. Fast first response with slow resolution means your team is acknowledging quickly and the work behind the reply is queuing. That is a workflow problem, not a responsiveness one, and speeding up replies will not touch it. ## 4\. Daily rows and first-responder breakdown ![Daily rows and a first-responder breakdown revealing a slow weekday](/images/content/modern-3d-illustration-of-daily-rows-and-a-first-r.webp) Daily rows show shape. A month that looks mediocre in aggregate is often four bad days and twenty-two good ones, and the four days usually have something in common, a weekday when the person who normally watches the inbox is on site, a stretch during a campaign. The first-responder breakdown shows who is picking things up. Read it as workload distribution rather than a scoreboard. If one person is first on eighty per cent of conversations, that is a risk to plan around, not a performance ranking. ## Keep the caveats in view while reading Three things shape every figure above. Timing is elapsed UTC, not business hours, so overnight gaps inflate response times even when nobody did anything wrong. The reports use retained history, so your plan’s retention setting limits what a long window can show. And this is not contractual SLA reporting. None of that makes the numbers less useful week to week. It just means you should compare them to your own previous weeks rather than to a target someone quoted at a conference. ## A monthly ten-minute routine Open the 30-day window. Check coverage. Compare median against the 90th percentile. Look at resolution timing. Scan the daily rows for the outliers and ask what those days had in common. Then change one thing. Usually it is after-hours handling, assignment discipline, or moving more repeat questions into the Grounded AI Agent’s [/features/grounded-ai-agent/ →](/features/grounded-ai-agent/) knowledge base so fewer conversations need a person at all. ## Three patterns and what they usually mean **Everything good except the 90th percentile.** A small number of conversations are being left much longer than the rest. Look at the daily rows, this almost always clusters at particular times, usually the start or end of the day, or a weekday when the usual person is unavailable. **Coverage falling while speed improves.** A warning sign rather than a win. It generally means the team is answering the easy conversations quickly and letting the harder ones sit. Assignment discipline usually fixes it faster than any change to staffing. **Resolution timing rising while first response is flat.** Acknowledgements are going out promptly and the work behind them is queuing. That is a capacity or process problem downstream of chat, and speeding up replies will not touch it. ## Turning a report into one change The mistake is reading everything and changing nothing. Pick one number per month. If coverage is the problem, work on after-hours handling and assignment. If the tail is the problem, look at when it happens and cover that window. If resolution is the problem, look at what happens after the first reply rather than at the chat itself. If everything looks fine, move more repeat questions into the knowledge base so fewer conversations need a person at all. One change, then read the next month’s report and see whether it moved. That loop beats a quarterly review that produces a document nobody acts on. Read next: what the response-time reports measure [/guide/what-the-response-time-reports-measure/ →](/guide/what-the-response-time-reports-measure/) for the definitions behind these figures. ## 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. Read the feature page [/features/response-time-reporting/ →](/features/response-time-reporting/) FAQ ## Questions people ask about this ### What is coverage? The share of conversations that received a human response, counted against every conversation in the window including the unanswered ones. It is the number that stops a flattering average from hiding a queue nobody worked. ### Why look at the 90th percentile? Because it shows your slower cases rather than your typical one. Most complaints come from the tail, so the 90th percentile is usually closer to the experience people remember than the average is. ### What is resolution timing? How long eligible resolved conversations took to reach resolution, as distinct from how quickly someone first replied. Fast first response with slow resolution is a common and specific problem. ## Related guides ### What the Response-Time Reports Measure (and What They Don't) Understand onmsg's response-time reporting scope: retained history and elapsed UTC time, with bot messages and notes excluded from first human response. Read guide [What the Response-Time Reports Measure (and What They Don't) →](/guide/what-the-response-time-reports-measure/) ## Want to try this on your own site? No credit card required. Start free [https://chat.onmsg.app →](https://chat.onmsg.app)