What a caller actually waits through, on a real phone call to Clara

300 real human phone calls, every one read turn-by-turn (1,355 agent replies measured), plus a 50-call sample of the robot-driven test line, pulled straight from ElevenLabs' own per-turn timers. Window: 2026-07-22 → 2026-08-20 (the last full 30 days). Read-only — nothing in prod was touched to build this.

The headline, in one paragraph

Half of Clara's replies land inside 2.5 seconds of the caller stopping talking. Nine in ten land inside 5.8 seconds. The worst 1% — long holds, garbled starts, a caller who trails off mid-sentence — run past 16 seconds, and when we opened those calls up, almost all of that time is the caller being genuinely quiet (mid-thought, spelling an email, thinking it over), not Clara being slow to think or speak. The model itself (the "LLM time-to-first-byte") is a median of about 1.0–1.1 seconds across every line we checked; text-to-speech start is a fast, stable ~0.22–0.28 seconds. The slow parts are turn-taking judgment calls — how long to wait before assuming the caller is really done — not raw horsepower.

1 · How long a caller actually waits, by line

Every number below is convai_ttf_audio_since_silence — ElevenLabs' own measurement of the gap from "caller went quiet" to "Clara's audio starts playing." This is the number a caller feels. p50 = typical, p90 = the wait one call in ten produces, p99 = the rare bad one.

Renewal, Turnover, and Emergency Relay have too few calls in this window (2–15) to trust their p90/p99 — flagged as small-sample, not treated as a finding. Triage and Willows have real sample sizes.

2 · The worst 10 waits — and what actually caused each one

We pulled the ten single slowest replies in the whole human-call set and broke each one into two pieces: how long the caller was already quiet before this reply started the clock (marked on ElevenLabs' own turn timer), versus how long Clara's own pipeline took once it decided to respond (model "thinking" time + voice-generation start time, added together). That split is the difference between "Clara is slow" and "the caller was still talking to themselves."

Nine of the ten worst waits are caused by the caller being quiet, not by Clara. Clara's own processing on these calls stays in the 1.4–4.8 second range even on the worst calls in the whole window — it's the same range as a normal reply. What made these ten feel bad is a long real-world pause: someone thinking, spelling something out, or trailing off. Clara is correctly waiting rather than talking over them — that's the right behavior — but from the caller's chair it still reads as "did the call drop?" past about 6-8 seconds.

One clear outlier is worth separate attention — a July 28 call where a reply took 16.6 seconds with essentially zero caller silence beforehand (the caller had already spoken). Model time and voice-start time only account for about 1.2 seconds of that 16.6; the rest isn't explained by any of the per-turn timers ElevenLabs gives us. That's a real, un-attributed processing stall, not a caller pause — it happened once in this sample, so it's noted as a live unknown rather than a pattern.

3 · Does calling a tool slow Clara down?

Yes, but only a little, and it's not the main story. Replies where Clara fired a tool (looking something up, transferring the call, booking a tour) run about 45% slower at the typical case than replies with no tool — but at the worst-case tail, tool-turns are actually a bit faster, because the worst no-tool waits are the caller-silence cases from section 2, not tool slowness.

Which tools carry the most weight (by how often they fire and how slow they run)

Nothing here is a smoking gun — every tool clusters in the 3-4 second typical range, which is Clara's normal pace with a bit of lookup work added on top. end_call has the widest spread (some hang-ups are instant, some carry a trailing pause), and transfer_to_number is consistently the single slowest common tool, which lines up with the separate transfer investigation already on the docs site (see section 8).

4 · Willows vs. Camellia — is the prototype actually faster, or does it just feel that way?

Fede's question, answered: Willows is genuinely faster, not just smoother-feeling — by about 12% at the typical case and 31% at the worst-case tail — but the gap is not because the underlying model or voice engine runs quicker on Willows. Same models, same voice stack, close-to-identical "thinking time." The real difference is that Willows calls tools less often (16% of its replies vs. 23% for Camellia's Triage line) and its voice-generation start is marginally faster. Fewer detours into tool calls means fewer of the slower turns from section 3.

One wrinkle worth knowing: Willows also gets interrupted by callers 2.6× more often than the Camellia Triage line (13.3% of Willows' replies vs. 5.1% for Camellia — see section 6). Part of "Willows feels faster" may be callers naturally barging in sooner on the tighter, terser prototype phrasing, not the platform alone. Both things can be true: Willows is measurably quicker to first sound, and callers are more willing to talk over it.

5 · English vs. Spanish

Spanish calls measure faster in this window, not slower — the opposite of the "Spanish calls felt different" hunch. But there are only 34 Spanish replies in 30 days (versus 1,321 English), so this is too small a sample to call a real difference either way. Worth re-checking once Spanish call volume grows; not actionable today.

6 · Interruptions and talk-over — a proxy for how natural the conversation feels

"Ignored as backchannel" (Clara correctly not reacting to a caller's "mm-hm" or "yeah") reads as effectively zero across every line in this window — either it's genuinely rare, or ElevenLabs isn't populating that flag much in practice. Not enough signal either way to report a rate here; flagging it as an open question rather than a finding.

7 · Trend over the window, and the four change dates

Fede asked us to check four specific dates against the data. Being honest about what the numbers can and can't show:

• Jul 19 — leasing read-injection (change #4129): falls before this 30-day pull even starts (window opens Jul 22). No before/after comparison possible from this data.
• Jul 21 — prompt diets: one day before the window opens — we only have "after." Can't show an effect; nothing to compare it to.
• Aug 19 — turn_v3 fleet promotion: this is the one date where something real shows up. The Escalation Callback line's typical wait jumped from its normal ~2.3s to 11.3s median on Aug 19 (13 replies that day), then dropped back to 2.3s median on Aug 20 (20 replies). Five of the ten worst waits in the entire 30-day window (section 2) landed on Aug 19, all on this one line. This is a correlation with the date Fede gave us, not a confirmed cause — we did not cross-check it against a deploy log or release timestamp.
• Aug 20 — quick-facts add+revert: same day as "today," so intraday before/after isn't resolvable from daily numbers. What we can say: across all human calls (196 replies, the single busiest day in the window), Aug 20's typical wait is 2.33s — same or better than every other day in the past two weeks. Fleet-wide, there's no visible regression on this date, whatever happened with quick-facts.

Outside of the Aug 19 spike (small sample, one line), day-to-day movement in this window is noise — typical waits bounce between roughly 1.5s and 3.8s with no sustained trend up or down. We're not claiming any of the four dates produced a clean, provable fleet-wide win or regression except the Aug 19 spike, which is real but narrow (one specialist line, one day, already recovered).

8 · Where this lines up with — and differs from — what's already on the docs site

Honesty check: the specific "July latency audit" numbers already published on docs.propflowai.co turned out to be about a different thing — /a/latency-audit-2026-07 and /a/latency-ledger-2026-07 measure how long PropFlow's web pages take to load (database scans, API waterfalls), not how long a caller waits on the phone. The local file path we were pointed to (~/.claude/propflowai/docs/voice-latency/*.md) doesn't exist on this machine. So there is no exact prior baseline for this specific number (caller-silence-to-first-audio, measured per turn) to compare against — this deep dive is the first time it's been measured this way, at this scale.

The closest real prior work on voice turn-taking is the transfer-handoff investigation (Jul 28), which measured Clara Triage's "thinking time" before speaking (a narrower slice of what we're measuring here, and only around specialist handoffs) at a median of 0.98 seconds. That's model-thinking time alone, not this doc's full caller-felt wait — so it's not a fair apples-to-apples comparison, but it's consistent with what we found here: the model itself replies in about a second; the multi-second waits callers actually feel come from elsewhere (silence judgment calls, tool detours, and — separately — the transfer/ring-time investigation on Aug 9, which found the "call gets transferred to a human" step averages 18.5 seconds, mostly the destination phone ringing).

9 · Method, so the numbers can be checked

• Source: ElevenLabs' Conversational AI API — the conversation list, then the full per-call detail (including per-turn timers) for every call analyzed. Nothing was written back; this is a read-only pull.
• Window: last 30 days of call data as of 2026-08-20 (2026-07-22 → 2026-08-20).
• Every human-facing phone call in that window on Clara's core lines and the Willows prototype was pulled and analyzed in full — 300 calls, 1,355 measured agent replies. Nothing was sampled or dropped on the human side.
• The robot-driven test line (Voice Eval Robot and related bench/QA agents — 160 calls available) was capped to a random sample of 50 calls for reference/comparison only, per the sampling rule for this project — it is not the focus of this doc.
• Excluded: text-only/SMS conversations, and internal throwaway/proof-of-concept test agents.
• The one ElevenLabs data quirk we had to work around: raw API responses sometimes contain stray control characters that break JSON parsing — stripped before parsing, standard practice for this API.
• All timestamps in this doc are Denver time (Mountain).