Averages hide response times: medians, percentiles, and what to publish

Reference article · 6 min read

An average response time is the easiest number to produce and the easiest to misread. If a permit office reports a mean review time of two weeks, the applicant whose file sat for two months is not confused about the arithmetic. Both things are true at the same time. The mean gets pulled toward the middle by a large volume of quick, simple cases, while the complaints come from the tail that the mean never shows.

This is not a reporting nicety. Staffing plans, service level targets, vendor credits, and council briefings all rest on these numbers. When the published statistic does not match what people experience, the agency loses the argument twice: once on the service itself, and once on its own credibility. The remedy is neither complicated nor expensive. It is a decision about which statistic to compute, how to compute it the same way every month, and what to put in front of staff and the public.

Why the mean drifts away from the typical case

Response, wait, and processing times almost always share a shape. They have a hard floor, since nothing takes less than zero time, no ceiling at all, and a long right tail. A handful of very slow cases can move the mean noticeably while the experience of most people is unchanged. The mean is the only common statistic that a single extreme value can drag anywhere it likes.

Two other patterns make averages worse in government work:

• Mixed populations. A queue that handles both a routine address change and a complex commercial plan review is really two or more distributions stacked together. Their average describes nobody's case.
• Clock effects. Requests that arrive after hours, on weekends, or just before a holiday inherit long waits from the calendar rather than from the work. If those hours are inside the measured clock, they widen the tail regardless of staffing.

What each statistic actually answers

• Mean. Total time divided by number of cases. Useful for capacity and cost math, because it multiplies cleanly by volume. Poor as a description of experience.
• Median, the 50th percentile. Half of cases finished faster, half slower. This is the honest answer to "what is typical."
• 90th or 95th percentile. The time that all but the slowest tenth or twentieth of cases beat. This is the number that tracks complaints, escalations, and reputational risk.
• Percent within a threshold. The share of cases finished inside a stated time. Easiest for a general audience to understand, and the form most service targets should take.
• Maximum. Worth watching internally as a check for stuck records, but too volatile to publish as a performance measure.
• Count. Always publish the denominator beside any of the above. A percentile computed from a handful of cases is noise.

Computing percentiles so two people get the same answer

Percentiles are simple to define and easy to disagree about. The most defensible approach for public reporting is the nearest rank method: sort the completed times from fastest to slowest, multiply the percentile by the number of cases, round up to the next whole number, and take the value at that position. The result is always an observed value from a real case, which makes it easy to audit.

Spreadsheet and database functions may interpolate between observations instead, and inclusive and exclusive variants can return different answers from the same data. Pick one method, write it into your reporting documentation, and use it everywhere. Two further rules matter more than the method itself:

• Never average percentiles. The 90th percentiles of twelve months, or of five districts, cannot be averaged into an annual or agencywide 90th percentile. Recompute from the underlying records.
• Watch for censored cases. If your calculation only includes closed records, every case still open and aging is excluded, which flatters the result exactly when service is worst. Report open backlog and its age alongside the percentiles.

Define the clock before you argue about the target

Most disputes about response time are really disputes about when the clock starts and stops. Settle these in writing, and revisit them whenever a system or workflow changes:

• Start event: when the call connects, when the record is created, when the payment clears, or when the application is deemed complete.
• Stop event: first meaningful response, final resolution, or inspection passed. First response and resolution are different measures and belong in separate lines.
• Pauses: whether time waiting on the applicant, on another department, or on an outside agency stops the clock, and how those pauses are recorded.
• Reopened or requeued cases: whether they continue the original clock or start a new one.
• Calendar: elapsed hours versus business hours, and the time zone applied.

Publish these definitions with the numbers. Public safety agencies should also confirm the current text of any consensus standard or state requirement they cite, since editions and thresholds change and several fire and emergency response standards express goals as a fraction of incidents meeting a time rather than as an average.

What to publish

Replace the single monthly average with a small, stable set:

1. Median, 90th percentile, and case count, by service type.
2. Percent completed within your stated target time.
3. A distribution chart, such as a histogram with a labeled long tail, so readers can see the shape rather than infer it.
4. Open backlog and the age of the oldest open case.
5. A footnote listing exclusions, definition changes, and the percentile method.

State targets in the same form you report: a share of cases within a time, not an average. An average target can be met while service for the slowest group gets worse.

How to start, and what to ask a vendor

Start with the data you already have. Export event level records with timestamps rather than a precomputed summary, recompute last year's figures using the median and 90th percentile, and compare that to what was reported at the time. That comparison is usually the most persuasive briefing material you will produce.

When procuring or renewing a system, ask for and require in writing:

• Event level export of every timestamp used in performance measurement, on demand and in a documented format, with the agency retaining the raw data.
• Written definitions of every clock, including pause conditions and reopen handling, plus notice before any definition changes.
• The exact percentile method the product uses in its dashboards, and the ability to reproduce the figure from raw records.
• Service levels expressed as percentiles or percent within threshold, not averages, with any exclusions listed in the contract rather than applied silently by the system.
• Backlog and aging reporting for open cases, not only closed case metrics.

HQT works with state and local agencies on data analytics and reporting systems, including how operational performance is measured and presented.

Frequently asked questions