Median and P90 Response Time Explained

Use the Social Media Response Time Analyzer to summarize supplied first-human-reply records. This guide explains its descriptive statistics, not a universal response-time benchmark.

Choose the question before choosing the statistic

Average response time is an incomplete label unless you say which average, which cases, and which endpoint you mean. The mean answers how large the total observed response duration is per completed reply. The median describes the middle of the sorted observed durations. P90 gives a high-percentile summary using a named quantile method. All three can be useful, but they are not interchangeable ways to announce one definitive service score. A queue with many short replies and a few very long waits may have a low median and a much higher mean or P90. That difference is information to investigate, not a calculation failure.

For this tool, response time ends at the first human reply that you have verified. It does not end at an automatic acknowledgement, an internal assignment, or final resolution. The receiving unit is a user-defined case, not a unique person or every message in a thread. Decide those rules before collecting timestamps, because no statistical summary can repair inconsistent units afterward. A project that counts follow-up messages separately on one account and whole requests on another creates an uneven comparison before the percentile is calculated. Keep the case definition and human-reply convention in the source ledger beside the actual timestamp evidence.

Avoid selecting whichever number makes the review sound strongest. Report the median with the replied count, a tail measure such as P90, and the relevant coverage and pending information. A maximum can also identify an observed extreme that a percentile smooths over. None of these quantities establishes satisfaction, loyalty, revenue effects, or required staffing by itself. If the decision concerns answer quality or unresolved problems, collect separate evidence about those outcomes. The calculator is designed to make a supplied timing snapshot inspectable, so an honest unavailable result or a visible tracking gap can be more useful than a precise but poorly defined headline.

Establish the eligible replies and the elapsed clock

The cutoff determines which source events have happened within the snapshot. A case received after it is future received and excluded from in-scope statistics. A recorded first human reply at or before it contributes one completed response duration. A recorded reply after it leaves the case historically pending, with that later timestamp preserved. Pending cases have waiting ages measured from receipt to cutoff; unknown cases have incomplete tracking rather than a confirmed absence of reply. Not-required cases are excluded from the needed denominator. Keep these categories distinct before sorting any durations, because their meanings cannot be recovered once they have been replaced with fabricated zeros.

The duration is elapsed milliseconds divided by sixty thousand, expressed in minutes. Time continues through evenings, weekends, and holidays. The tool does not pause for a working-hours calendar and does not measure a separate resolution interval. A full timestamp with an explicit numeric offset identifies an instant directly; without an offset, the selected project time zone determines the instant. Changing a display zone does not change the elapsed duration between two correctly identified instants. Incorrectly treating an offset-bearing entry as local time, however, would change the evidence. Verify the source offsets and dates rather than trying to correct a suspicious percentile after calculation.

An arrival cohort also needs a stated boundary. The cutoff is an endpoint, not an automatic selection of the preceding day, week, or month. The tool’s account and channel filters select existing rows but do not choose a receipt-date range or equalize how long requests have been observed. Prepare the desired cohort in the source records. Requests arriving just before a cutoff have had less chance to receive replies than older requests, which can change reply rate and the completed subset. When comparing snapshots, describe that observation time instead of assuming that identical cutoff clock times make the underlying cases equally mature or directly comparable.

Calculate mean, median, and R7 P90 step by step

Consider six fictional completed first replies with elapsed durations of zero, four, twelve, eighteen, forty, and 160 minutes. These are already sorted from shortest to longest. Their sum is 234 minutes, so the mean is 234 divided by six, or thirty-nine minutes. With an even number of values, the median averages the two middle positions. The third value is twelve and the fourth eighteen, giving a median of fifteen minutes. Minimum is zero and maximum is 160. The zero is a known same-instant reply in this example, not a blank cell or a pending case disguised as an immediate response.

For R7 P90, let n be the number of observed durations and use the one-based position h = 1 + 0.9 times (n minus 1). With six values, h is 5.5. The fifth duration is forty and the sixth is 160, so interpolate halfway between them: forty plus 0.5 times the difference of 120 gives one hundred minutes. That value is not one of the original reply durations. It is the method’s interpolated high-percentile summary of this sample. Keep the calculation in raw minutes until presentation rather than rounding each duration first, which can move a result when timestamps include seconds.

Now choose a thirty-minute review target. Four of the six completed replies are at or below thirty minutes, so reply on-time rate is about 66.67 percent. This percentage comes from counting cases against the target, not from dividing the target by the median or P90. A fifteen-minute median and a hundred-minute P90 can coexist with four on-time replies without any contradiction. The three quantities answer different questions. These six observations are an original numerical illustration, not a claim about any platform, industry, or expected service level. A target must be declared separately from the distribution rather than inferred as a promise from its current percentile.

Understand interpolation, tiny samples, ties, and zeros

Different software can use different sample-quantile definitions. R7 interpolates across positions tied to the observed minimum and maximum; a nearest-rank method can instead select an existing observation. Two reports can therefore disagree on P90 even when both contain the same durations. Check the method before accusing either report of a transcription error. This analyzer uses R7 consistently, with the sole value returned when only one eligible reply exists. With no eligible replies, P90 and the other timing summaries are unavailable. An empty distribution is not an immediate-response record, and replacing its unavailable result with zero would imply evidence that the project does not contain.

Do not read a small-sample P90 as an exact statement that ninety percent of cases fell below its value. In the six-value example, five of six durations are at or below one hundred minutes, about 83.33 percent, while the sixth is above it. The interpolated quantile still equals one hundred under the stated method. With two durations, ten and ninety, R7 P90 is eighty-two, which is between the observations rather than a new observed wait. With one duration, all timing summaries describe that one case. Such results can be arithmetically valid while providing very limited evidence about a wider or future workload.

Repeated values do not require deduplication. If three separate cases each received a human reply after twelve minutes, all three belong in the distribution when the case IDs and source evidence are valid. Removing ties would change the unit from cases to distinct duration values. A zero-duration case likewise remains in the count, mean, median, and percentile. Check whether matching timestamps reflect real source precision, since a minute-level display can hide sub-minute differences. The tool can retain seconds, but it cannot manufacture finer measurement from a coarse source. Distinguish known equal instants from a reviewer rounding two different events to the same visible minute.

Keep pending ages and unknown tracking outside completed timings

Extend the six-reply illustration with three known pending cases aged twenty, ninety, and 240 minutes at the cutoff, two unknown cases, one not-required case, and one future receipt. The full project now has thirteen rows, twelve in scope, nine known-needed cases, and eleven needed cases. Reply rate is six divided by nine, about 66.67 percent. Known tracking coverage is nine divided by eleven, about 81.82 percent. The completed response median remains fifteen minutes and P90 one hundred because those statistics still use only the six observed replies. The added categories change the interpretation substantially even though they do not change those two timing values.

Pending-age mean is 350 divided by three, about 116.67 minutes, while its median is ninety and R7 P90 is 210. These are ages at the cutoff, not estimates of eventual first-reply durations. Against the thirty-minute target, two pending cases are overdue and one is within target. Do not add those two overdue cases to the completed-reply compliance calculation or call their current ages completed response times. Some pending cases may already have waited longer than the replied P90. That is a useful warning that the completed distribution describes only part of the workload, not evidence that the ages belong in the same statistical sample.

The unobserved completed durations are censored by the snapshot: the first human reply has not been observed by the endpoint. This calculator does not fit a survival model, predict completion, or fill those durations with waiting age. Unknown tracking is not even a confirmed censored pending observation, so it stays separate. If only the first five completed durations in the illustration were observed in an earlier snapshot, their median would be twelve and P90 31.2. Observing the long reply later could raise both values without making any already recorded reply slower. A changing completed subset can explain a changing statistic; the review needs its case history to interpret that movement.

Pool case durations rather than averaging account percentiles

Split the six completed durations into two account groups. Account A has zero, four, and twelve minutes, giving median four and R7 P90 10.4. Account B has eighteen, forty, and 160, giving median forty and P90 136. Their combined median is fifteen and combined P90 one hundred, calculated from all six durations. Averaging the account medians would produce twenty-two, and averaging their P90 values would produce 73.2. Neither is the combined result. A percentile depends on the sorted positions of the underlying observations, so summary values alone do not preserve the information needed to reconstruct the pooled distribution correctly.

The same caution applies to separate days, channels, projects, and exports. A daily P90 chart can be useful as a series of daily summaries, but its arithmetic average is not the P90 of all cases across those days. A mean can be pooled from group means when the correct counts are used as weights, yet that does not make the same operation valid for medians or percentiles. When you need an overall timing result, use the relevant underlying eligible durations with a consistent case definition. Do not enter already summarized medians as fake case durations merely to force the calculator to produce another summary of summaries.

Even correctly pooled data can hide a changed mix. An account receiving many short factual questions can dominate a combined median while another handles fewer, more complicated requests. The tool’s account and channel filters help inspect those supplied subsets, but they do not adjust for case complexity or establish a fair performance ranking. Compare each group’s replied count, coverage, pending ages, and collection rules alongside its timings. A filter producing only unknown or not-required cases should display unavailable timing, not make the group disappear from the discussion. Describe what is actually comparable and leave the unresolved operational differences visible rather than attributing the entire gap to response effort.

Make the calculation reproducible from timestamp evidence

Keep enough private source evidence to reproduce each duration without storing message bodies in the project. A stable case ID can link receipt and first human reply to an authorized ledger. Verify chronology, calendar date, clock precision, and offsets, especially across midnight. A duration of ninety seconds is one and a half minutes, not one minute after truncation. An overnight reply can be many elapsed hours even if the team was not staffed. Repeated or nonexistent daylight-saving wall times need verified correction or an explicit valid offset, not an automatic guess. A valid-looking timestamp is still a human-supplied statement that the calculator cannot independently confirm.

Use project title, time zone, cutoff, response target, account filter, channel filter, and next-step note to preserve the intended review context. The initial cutoff does not mean now; it is fixed until edited. Batch input must map to record_id, account, channel, received_at, reply_status, and first_reply_at, with the tool’s exact channel and status keys. Keep the CSV input template distinct from the flattened report CSV. Save project produces the editable JSON that Open project can restore, including all source rows and settings. That backup is the appropriate starting point for reproducing the review, not a screenshot that hides the case counts and timestamp distinctions.

A practical independent check uses a small sorted list and a hand-calculated expected result before reviewing a larger project. The six-duration example tests a known zero, an even-count median, and interpolation between widely separated tail values. A one-case review checks that P90 equals its sole duration; an all-pending review checks that completed timings remain unavailable. A case with a later recorded reply checks historical pending behavior. These are suggested user checks, not claims that your current source collection or browser has been independently audited. If an output differs, compare the selected rows and cutoff first, then the quantile definition and timestamp offsets, before changing any source values.

Report a bounded conclusion and a useful next question

A useful summary of the expanded illustration would say that six of nine known-needed cases had received a first human reply at the cutoff, with two additional needed cases unclassified because tracking was incomplete. Among the six replies, median elapsed time was fifteen minutes and R7 P90 one hundred; two pending cases were older than the chosen thirty-minute target. That sentence keeps the sample, interpolation method, coverage limitation, and waiting workload together. It does not claim that every request was answered within one hundred minutes or that a ninety-percent service promise was met. Keep the cutoff, zone, and collection boundary beside it wherever the conclusion is shared.

Preserve privacy when sharing the supporting review. Full outputs retain all raw project rows and notes, including records outside active filters and timestamps after the cutoff. The PDF shows a bounded account summary and the oldest eight pending cases, with complete project JSON and report CSV attached. Filtering the screen does not redact those attachments. Make a separate reduced project for a recipient who should see less, then inspect the exported files themselves. The response target and backlog guide can help turn the descriptive result into a human review sequence without treating P90 as a forecast or an automatic priority rule.

Choose the next question from the limitation that matters most. You may need to repair unknown tracking, compare like-for-like arrival cohorts, or inspect the few long waits in their native context. Recurring factual questions can also suggest a clearer organic explanation, which remains a separate publishing task rather than proof that content will reduce demand. SMTasker offers supported account and publishing routines, and Skye can assist with supported workspace setup for review. Explore those organic workflow options without assuming that this calculator manages human inbox replies. Return to the analyzer when the next deliberately collected snapshot is ready, keeping its definitions consistent enough to understand any descriptive change.

Questions about Response-Time Percentiles

Continue with another response-time guide

Review supplied conversation records in the Social Media Response Time Analyzer, or choose another guide below. Find more practical resources in all free tools.