What the Email Response-Time Calculator does
This calculator measures reply times against working hours rather than the clock. A message that arrives at 17:55 on Friday and is answered at 09:05 on Monday took 63 hours by the clock and ten minutes by any sane service target; both figures are shown side by side so the difference can be argued about honestly rather than quietly assumed.
It reports the median and the 90th percentile rather than the average, because reply times are skewed: a handful of threads that sat for days will drag a mean upwards until it describes nobody's experience. Percentiles use the nearest-rank method, so every figure quoted is an actual thread you can point at, and the spreadsheet's interpolated value is shown alongside for reconciliation.
How to use it
- Set the working schedule: opening and closing times, an optional break, which days are worked, and any holidays.
- Enter the first-response target in minutes, measured in working hours.
- Paste the threads, one per line:
id, from, received, replied, resolved. Times are written2026-09-21 09:05; leave the reply blank for anything still unanswered. - Read the median first, then the 90th percentile - the gap between them is the real story.
- Check the weekday chart and the "waited to open" column to see how much of the clock time was simply the office being shut.
Reading the results
Working minutes exclude everything outside the schedule. Clock minutes include it. Quoting the first to a customer and the second to a manager is how service reports lose credibility, so both are always shown.
The median is the middle thread; p90 is the thread that only one in ten exceeds. When p90 is several times the median, the tail is where the complaints come from and the average will hide it entirely.
Unanswered messages are excluded from every statistic and counted separately. An unanswered message is not a fast one, and a report that silently drops it is flattering itself.
"Waited to open" is the time a message sat before the office opened. It is excluded from the working figure, and showing it makes that exclusion visible rather than convenient.
Worked example: a Friday evening message answered on Monday
A support inbox works 09:00 to 17:00, Monday to Friday, with a four-hour first-response target. A message arrives at 17:55 on Friday 18 September 2026 and is answered at 09:05 on Monday 21 September.
By the clock that is two full days plus fifteen hours and ten minutes: 3,790 minutes. In working hours it is five minutes, because the only open time between the two stamps is 09:00 to 09:05 on the Monday. The remaining 3,785 minutes are reported separately as time waiting for the office to open.
Add a message received at 09:12 on Monday and answered at 09:41 (29 minutes), and one received at 10:30 and answered at 14:05 (215 minutes). The median of 5, 29 and 215 is 29 minutes; the nearest-rank 90th percentile is the slowest of the three, 215 minutes. All three are inside the 240-minute target, so the breach count is zero.
The mean of those three is 83 minutes - a figure that describes none of them, and the reason the headline here is a median.
Formulas and scoring rules
- Working minutes
sum of the overlap between [received, replied] and each open windowHolidays remove a day entirely; a break splits the day into two windows.- Clock minutes
(reply day - receipt day) x 1440 + reply time - receipt time- Nearest-rank percentile
value at index ceil(p x n) in the sorted sample, 1-basedAlways returns an observed value - the actual thread that defines p90.- Interpolated percentile
linear interpolation at index p x (n - 1)What PERCENTILE.INC in a spreadsheet returns. Differs from nearest rank on small samples.- Breach rate
breaches / answered threadsUnanswered threads are excluded from the denominator and reported on their own.
Why working hours and not the clock
A team that works 09:00 to 17:00 has 40 hours a week and 128 hours where nothing happens. Measuring against the clock therefore measures the calendar, not the team: the same four hours of actual delay reads as four hours on a Tuesday morning and as sixty-seven hours across a weekend.
The one honest use of clock time is the customer's experience, which really does include the weekend. That is why both figures appear on every row. Choose whichever one the conversation is about, and say which you chose.
Medians, percentiles and the tail
Almost all response-time distributions are right-skewed: most replies are quick and a few take an order of magnitude longer. The mean sits between the two and describes neither. The median describes the typical case, and the 90th or 95th percentile describes the case people complain about.
Service targets are therefore normally written as a percentile - "90% of first responses within four working hours" - rather than as an average, which can be met while a tenth of customers wait a week. The page reports the percentage inside the target as well as the breach count so the target can be stated either way.
Time zones, stated plainly
Timestamps are read exactly as written and compared against the schedule you set. No zone conversion happens, and none is inferred from your browser.
That is a deliberate restriction. A mailbox export can carry several zones, and silently assuming one produces a report wrong by hours in a way nobody notices until it is quoted in a contract review. Convert the log before pasting it, and the arithmetic here is exact.
Limitations: what the result does not prove
- It measures the timestamps you paste. It does not connect to a mailbox, a helpdesk or an API, and it cannot tell a substantive reply from an auto-acknowledgement.
- No time zone handling. Mixed-zone logs must be converted before pasting.
- A single schedule applies to every thread. Follow-the-sun coverage, per-agent hours and different targets per priority are not modelled.
- Small samples move a lot. Below about twenty threads the median and p90 are indicative rather than a measurement, and the page says so.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- ISO 8601-1 - Date and time: basic rules - checked 19 Sep 2026
- NIST/SEMATECH e-Handbook of Statistical Methods - Percentiles
Frequently asked questions
How do I calculate response time in working hours?
Count only the minutes that fall inside your open windows between receipt and reply, ignoring evenings, weekends and holidays. Paste the timestamps here with your schedule and the page reports both the working-hours figure and the clock figure for each thread.
Should I report the mean or the median response time?
The median, and a percentile alongside it. Response times are right-skewed, so a handful of slow threads pull the mean above almost every actual reply. "Median 29 minutes, p90 215 minutes" describes the service; "average 83 minutes" describes nothing that happened.
What is a good first-response time for email?
That is a policy question, not a fact - it depends on the channel, the contract and what customers were promised. What matters more is stating the target as a percentile in working hours and then measuring against it honestly, rather than adopting a benchmark from an industry report with no definitions attached.
Why does my p90 differ from the spreadsheet's?
Because there are two conventions. Nearest rank returns an observed value - the actual thread at that position - while the spreadsheet interpolates between neighbours. The page shows both, and on small samples they can differ noticeably.
How are messages that arrive out of hours treated?
The wait until opening is excluded from the working-hours figure and reported separately in its own column, so you can see exactly how much of a long clock time was simply the office being shut.
What happens to threads that were never answered?
They are excluded from every average and counted on their own line. Including them as zero would be nonsense, and dropping them silently would make an inbox with a backlog look fast.
Does this send my mailbox data anywhere?
No. Message timestamps and correspondent names stay in the browser - there is no upload, no storage and no mailbox connection. Paste an export, read the figures, close the tab.
Last reviewed by the A2Z.Tools team against the sources listed above.
