First-party data · 2026-05-03 to 2026-08-01
89,858 inbound calls, and what they say about the numbers this industry publishes
Over 90 days, 89,858 calls arrived at our phone numbers and 48,761 of them reached a live agent. That is 54.3%. Measured the way a queue report measures it, it is 61.3%. Both are below what the industry advertises, and publishing them is the point: the useful thing in this dataset is not our score, it is what the distributions underneath it show about how call-centre statistics are built.
The headline finding is that our own average speed of answer looks close to perfect -- a median wait of 0 seconds, a 99th percentile of 4 seconds, a longest wait of 53 seconds in an entire quarter -- and that this is not a good sign. It is what the metric does when a system drops calls instead of queueing them.
What this is, and what it is not
This is one call centre floor. It is not an industry benchmark and it cannot become one, because there is no second floor in this dataset. Nothing on this page establishes what is normal, average or good. It establishes what 89,858 calls on one floor did, in a stated window, with the query behind every figure written down.
That is enough for the argument being made here, which is methodological. You do not need a second floor to show that a metric computed over survivors flatters, or that a pooled rate across 7 queues where two of them carry 84.9% of the volume describes those two queues and nothing else. Those are properties of the arithmetic, and one honest dataset demonstrates them.
It is also not organic demand. At least 31.2% of these inbound calls are our own outbound coming back -- 2,871 of 9,210 calls in the week of 2026-07-25 came from a number we had already dialled -- and that is a floor rather than a ceiling, because the outbound log is trimmed to a rolling window and only about five weeks of lookback existed to check against.
Finding one
A perfect wait time is evidence of dropped calls, not of fast answering
Average speed of answer, and every percentile built on it, is computed over calls that were answered. It cannot see the calls that were not. On this floor 43,926 of 48,761 answered calls (90.1%) connected to an agent with no measurable hold at all, and 99% connected in under five seconds. Reported alone, that is a service level almost no contact centre claims.
Now the other side. 41,097 calls did not reach an agent. Of the 23,562 of those carrying a usable elapsed time (57.3% of them -- see the caveat below the chart), 50.1% ended inside five seconds and 38 calls in the entire quarter lasted thirty seconds or more. Callers were not running out of patience. They were never put on hold.
Coverage, stated because it is not complete: 41,097 arrivals went unanswered, 30,830 rows in the queue table ended with no agent, and 23,562 of those carry a usable elapsed time. This curve therefore describes 57.3% of the unanswered calls, not all of them. The rest ended before or outside a queue record and nothing here claims to know how long they lasted. 30,830 counts the queue table directly and 30,792 counts only those matched to an arrival row -- a 38-row difference explained under Methodology.
The dialer names the reason itself
These are not our labels. They are the status names stored in the dialer's own status table, against the 30,830 queue records that ended without an agent.
| Dialer's own status name | Calls | Share |
|---|---|---|
| Agent Not Available | 22,448 | 72.8% |
| Lead To Be Called | 7,268 | 23.6% |
| Inbound After Hours Drop | 1,113 | 3.6% |
| Inbound Queue Timeout Drop | 1 | 0% |
A queue that made callers wait and then gave up would fill the last row. It has one call in it, across ninety days. Almost everything sits in the first: the system refuses the call at the door when nobody is free. That is why the wait-time distribution looks immaculate, and it is why the two numbers are only honest together.
What to do with this if you are buying. Ask any vendor for the answer rate and the wait time together, and ask which denominator the answer rate uses. A vendor whose average speed of answer is very low and who will not state an answer rate has told you almost nothing, and possibly the opposite of what you concluded.
Finding two
A floor-wide answer rate describes the two biggest accounts and nothing else
Our pooled rate is 61.3% on the queue-record denominator. Underneath it, 7 queues carried 100 or more calls, and their individual answer rates were 0%, 0%, 0.6%, 11.5%, 49.2%, 66.2%, 71.6%. The largest single queue is 48.3% of all volume and the largest two together are 84.9%. So the pooled figure is arithmetically a report on those two, and any client outside them is not described by it.
The identifiers and the per-queue volumes are deliberately not published, and not for presentational reasons: a rate published beside its volume is a fingerprint, and a competitor who knew roughly how big an account was could read that account's performance straight off the table. The spread is what a reader needs, and the spread is here.
A correction we had to make to our own reading
The median of those 7 rates is 11.5%, which invites the conclusion that the typical queue on this floor answers about one call in nine. That conclusion is wrong, and the reason is worth publishing because it is the sort of thing a benchmark table hides. Two of the 7 queues had zero agents assigned across the entire quarter. They are routing destinations, not queues that failed -- one is an after-hours drop bucket whose no-agent records are entirely "Inbound After Hours Drop", and the other is our own sales line. Counting an unstaffed drop target as a queue with a 0% answer rate is a category error.
Excluding them, the 5 staffed queues ran 0.6%, 11.5%, 49.2%, 66.2%, 71.6% and the median is 49.2%. Note what moved and what did not. Those two queues are 1,550 calls, or 1.9% of all queue records, so the POOLED rate barely shifts -- 61.3% to 62.5%. The MEDIAN moves by a factor of more than four. That divergence is the clearest demonstration on this page of why a pooled rate and a median answer different questions, and why publishing one without the other lets you pick your story.
Both medians are published above, with the rule that separates them, so a reader who disagrees with the rule can recompute. Either way the spread across staffed queues runs from 0.6% to 71.6%, which no single pooled number should be allowed to hide.
Finding three
Half of every answered call is a 24-second hangup
An answer rate measures a phone being picked up. It is routinely quoted as though it measured a customer being helped. Here is what our 48,761 answered calls actually contained.
50.7%
dispositioned as a hangup (24,700)
19.3%
wrong number, dead air, machine or prank (9,397)
0.6%
booked an appointment (281)
23.8s
mean length of an answered call
This is not a complaint about the floor; a large share of inbound volume anywhere is misdials and machines. It is a warning about the metric. Two vendors with identical answer rates can differ by an order of magnitude in what happened after the pickup, and no answer rate will show it. If a number is going to be used to compare vendors, it needs to be a number about outcomes, and this dataset says the outcome rate here is 0.6%.
Finding four
39.7% of calls arrive out of hours, and we answer two of those three windows badly
Measured in the caller's own local timezone rather than ours -- 31,116 of the 78,435 calls whose timezone resolved arrived outside 08:00-17:00 Monday to Friday. The timezone rule is not a detail: computing the same figure in floor-local time gives a different answer, and only the caller's own clock describes a homeowner ringing at seven in the evening.
Gold bars are outside 08:00-17:00 Mon-Fri. The shape was recomputed with the single largest contributing queue removed (n = 41,112) and agrees to within half a percentage point at every hour, peak included, so it is a property of the demand rather than of one account.
The companion number, which has to be published with it or the demand figure is just a sales argument: this is demand, not coverage.
| Window (caller local) | Calls | We answered |
|---|---|---|
| 08:00-17:00 Mon-Fri | 47,319 | 68.6% |
| Weekday evenings from 17:00 | 24,969 | 59.7% |
| Saturday and Sunday | 4,661 | 10.1% |
| Weekday mornings before 08:00 | 1,486 | 0.3% |
Weekday evenings are covered reasonably. Weekends and early mornings are not covered in any meaningful sense, and printing 39.7% while implying we answer it would be a claim this dataset does not support.
Two checks that license pooling this figure, both of which the answer rate fails. Per-queue after-hours share runs 16% to 49.2% with a median of 40.1%, and the largest contributor (48.3% of volume) sits at 39.1% -- so no single member is driving it. The low end of that range is our own sales line rather than a client account. And it is not a robocall artifact: the junk-disposition share of answered calls is 20.1% after hours against 18.8% in business hours, which is the same call mix.
Methodology
The two denominators
Two tables carry inbound and they are not interchangeable. One has a row per call that arrived at a phone number of ours; the other has a row per call that reached an agent queue, and it is a strict subset -- 79,553 of the 89,858 arrivals. An answer rate computed on the queue table alone silently drops 10,305 calls that arrived and never got that far, which is why both are published or neither is. 86,082 arrivals were routed toward an agent queue at all; the remainder went to an extension.
Where our own arithmetic does not close, and why
Subtracting 48,761 answered from 79,553 queue records gives 30,792, but the status table above sums to 30,830. Both are right and they count different populations. The corpus figures are derived arrival-first -- starting at the arrivals table and joining the queue table onto it -- so they count arrivals that matched a queue record. The status breakdown, the abandon curve and the per-queue rates are derived queue-first, reading the queue table directly, so they see 79,591 rows including 38 whose arrival row falls outside the window or carries no matching id. The answered count is 48,761 under both readings, so every one of those 38 rows is a no-agent row. That is 0.048% of the queue table and it changes no rate on this page at one decimal place (48,761/79,591 is 61.26%, 48,761/79,553 is 61.29%, and both are the 61.3% published above). It is written down because a benchmark whose whole claim is that it reconciles has to reconcile in public.
What "answered" means
A named agent leg on the call record -- the agent field is neither empty nor the system placeholder. Cross-checked rather than assumed: 97% of agent-flagged calls carry a row in the recording table, and the two no-agent states are named by the dialer itself, as printed in the table above.
Time, which was nearly got wrong
The dialer stores timestamps in server-local time and the server runs US Eastern. That was verified rather than assumed, by reading the server clock and its UTC clock on the same round trip, because the database driver stamps a "Z" on a value that is not UTC and taking that at face value would have shifted every hourly figure on this page by four hours. Caller-local time then comes from the lead record's own UTC offset, with a fallback to the archive table for leads that had rotated out -- without that fallback, 26.8% of the window is unresolvable; with it, 1.5%. The unresolved rows are kept as a visible bucket rather than dropped, so the after-hours figure is a bound: 39.1% if every unresolved call fell inside business hours, 40.5% if every one fell outside.
The window is fixed
2026-05-03 to 2026-08-01, 90 days, server-local US Eastern, verified against UTC on the same round trip. Nothing refreshes it. A dataset that silently re-derives itself lets a published figure change underneath a citation, so re-running the queries produces a new dataset with a new window rather than an update to this one.
Privacy
Aggregate only, under three rules. No queue identifier appears anywhere. No rate is published beside its volume, because together they are a fingerprint. No cut is published that has too few members to hide one -- which is why there is no per-vertical, per-client or per-agent table on this page, and why two queues that carried single-digit call counts in the window are inside the totals and are never a row.
The least flattering reading
Monthly answer rate on the queue-record denominator rises across the year, and we are not going to call that improvement, because this data cannot support it.
| Month | 2026-02 | 2026-03 | 2026-04 | 2026-05 | 2026-06 | 2026-07 |
|---|---|---|---|---|---|---|
| Answered | 40.3% | 55.9% | 49.2% | 58.2% | 59.4% | 63.1% |
| Calls | 36,621 | 16,977 | 11,994 | 10,276 | 28,147 | 41,382 |
Look at the second row. Monthly volume swings by a factor of more than three because the mix of queues changed, and two queues are 84.9% of all volume -- so this series substantially tracks which large account was busiest that month, not how well anyone answered. Separating the two needs a per-account series, which the privacy rules above forbid publishing. Its window is also wider than the window for every other figure on this page. It is here because leaving it out would mean hiding the least flattering available reading of the headline number.
What this dataset cannot see
- Carrier ring time before the call reaches our switch. Every wait figure here starts at arrival at a ccdocs number, so the true time from a caller pressing dial is longer by an unknown amount. The arrival-to-queue leg on our own side was measured separately and is 0 to 1 second (mean 0.35s over 6,042 calls in the week of 2026-07-25).
- What any call was about. There is no topic, intent or outcome field on the inbound path beyond the disposition an agent selects, so nothing here says whether an answered call was useful to the caller.
- Anything that happened on a client's own phone system. This is one floor. Calls a client answered themselves, or lost themselves, are invisible.
- Whether an unanswered caller rang back. The corpus is keyed on calls, not on people, so a caller who was dropped and redialled appears twice and is counted twice.
- Any industry comparison. There is no second floor in this dataset. Nothing here establishes what is normal, only what one floor of 89,858 calls did.
Using this data
Published under CC BY 4.0. Quote it, chart it, argue with it -- with a link back to this page, and with the window and the denominator attached to any rate you take from it, which is the whole argument above. If you operate a floor and can produce the equivalent cuts, that would make this comparable to something for the first time, and we would rather link to yours than be the only number in the room.
The outbound half of the same estate is published the same way, under the same rules, at outbound dial cadence benchmark -- which dial attempt reaches a person, how little the hour of day moves it, and every bucket a client-disclosure rule withheld along with the clause it failed.
Questions
What is a good answer rate for a call center?
There is no published figure this dataset can validate, and any vendor quoting one should be asked for its denominator. The two that matter are different questions: the share of calls that reach an agent out of everything that ARRIVED, and the share out of everything that reached a queue. On this floor over 90 days those are 54.3% and 61.3% of 89,858 calls, and the gap between them is 10,305 calls that arrived and never got a queue record. A benchmark that does not say which denominator it used is not comparable to anything.
Why is average speed of answer a misleading metric?
Because it is computed only over the calls that were answered. On this floor the median answered caller waited zero seconds and the longest waited 53 seconds across an entire quarter, which reads as an excellent service level. It is not one. It is what a queue looks like when it refuses calls instead of holding them: 45.7% of arrivals never reached an agent, and half of the ones that were dropped ended inside five seconds. The dialer names the state itself -- 22,448 of the 30,830 no-agent records are "Agent Not Available", while exactly one call in 90 days hit "Inbound Queue Timeout Drop". A faster average speed of answer can mean a worse service, and the only way to tell is to publish the answer rate beside it.
Does a high answer rate mean calls are being handled well?
No, and this dataset is fairly blunt about it. Of 48,761 answered calls, 24,700 (50.7%) were dispositioned as a hangup, 9,397 (19.3%) were a wrong number, dead air, an answering machine or a prank, and 281 (0.6%) booked an appointment. The mean answered call ran 23.8 seconds. "Answered" is a measurement of a phone being picked up, not of a customer being helped, and the two should never be presented as the same number.
When do inbound calls actually arrive?
39.7% of them arrived outside 08:00-17:00 Monday to Friday measured in the CALLER's own local timezone, not the floor's. That distinction changes the answer, which is why it is stated: computing the same figure in floor-local time gives a different number. The hourly shape peaks at 16:00 and is still at roughly 90% of peak at 18:00. The shape was re-derived with the single largest contributor removed and agrees to within half a point at every hour, so it is a property of the demand rather than of one account.
Can I cite or reuse this data?
Yes. It is published under CC BY 4.0 with a link back to this page. The window, the source tables, the row counts and the SQL behind every series are on this page and in the repository file it renders from, so the figures can be checked rather than taken on trust. If you are quoting a rate, quote its window and its denominator with it -- the whole argument of this page is that a rate without those is not a fact.
If you want these numbers for your own phone line
The reason we can publish this is that the floor is instrumented. Most businesses cannot answer "how many calls did we miss last month, and how long did the people who hung up actually wait" about their own line at all. That is the conversation worth having, and it is worth having before anybody quotes you a rate.