The PM briefing is not discarded. This page previously said the briefing Clara generates for the PM is thrown away and never played. That is wrong. Fede tested it live, and the ElevenLabs documentation agrees: on our native-Twilio conference transfers the briefing is always read aloud to the PM by a robot voice, and there is no switch to turn it off. The caller-side analysis could not see it because it plays on the separate Twilio leg to the PM, which the ElevenLabs recording never captures. It averaged 25 words — about 10 seconds, worst case 21 — because nothing constrained its length. Fixed in PR #5579.
The PM's voicemail is not unmonitored. The PM gets her voicemail normally. The real gap is on our side: PropFlow cannot see it. Those calls are stamped connected, there is no record that a message was left, and nothing appears on the conversation timeline. Fixed in PR #5580.
Both PRs are open, awaiting the review bot's recovery.
This page replaces the 9 August version. A verified reinvestigation confirmed its numbers, overturned its diagnosis, and then found something worse than latency. The wait is real — 18.5 s from the caller's last word to the destination answering — but most of it is the phone ringing, and Clara speaks before the ring starts. The finding that matters is elsewhere: 42% of the transfers we record as "connected" reach nobody at all.
The old number was not fabricated. "16.5 s" approximates something real — the time from the caller's last word to the destination line answering, which on that same window is 18.5 s median, 34.3 s p90, 42 s worst case. The wait is real and it is long.
What was wrong is the character of that wait, and the character is what decides the fix. About 9.5 s of it is the PM's phone ringing, not silence. The old doc's "SILENCE" column is numerically identical to ring time — the same column, mislabeled. And the roughly 8 s before the ring is broken by Clara's own voice.
Here is how the mislabel happened. Twilio's start_time on the outbound leg is the answer instant, not the dial instant — proven by end_time minus duration equalling start_time in 135 of 135 dials. Measuring up to start_time swept the whole ring into "silence".
transfer_to_number. This is the highest-value finding here — it is the one that will keep producing surprises.Voice only, by Fede's ruling. The email/SMS escalation section from the previous version has been moved out of scope — parked, not retracted.
The wait after someone asks for a person has three parts. Only the first is ours.
The old version was wrong about the number and about the shape. There is no long block of silence. There is a short one, and then Clara talks.
The order matters: Clara speaks before the tool fires, and never after it. That is airtight across all 147 transfers — zero have any Clara utterance after the tool fires. What the caller never hears is any handoff narration. The PM, on her own leg, does hear a briefing read by a robot voice, and the caller holds through it. So the only silence we own is the thinking pause before she answers, about 6 seconds at the median.
Everything after that is either Clara's acknowledgment or the phone ringing.
Dead air here is an upper bound. ElevenLabs reports turn-start times as whole seconds only, so "last word → dial" silently includes the length of the caller's own utterance, roughly 2 s. The true median is likely nearer 7 s than 9 s. The post-tool silence is counted across all 147 transfers; the second-by-second structure comes from the 14 locally-available ElevenLabs transcripts, independent of the Twilio timing join. The repo configs contain no static wording — they set enable_client_message: true and nothing more, so both the caller-facing line and the PM briefing are generated per call at runtime. Nothing capped the briefing's length, which is why it grew to 25 words.
Measured, not inferred. Two retained dual-channel Camellia recordings show continuous broadband audio through the whole ring window with zero off-periods. Ringback pulses; this does not, so ringback is ruled out. ElevenLabs Scribe independently labels the same stretch "[on-hold music]" on both.
So the caller is not sitting in silence waiting for a pickup. They are on hold, and it sounds like being on hold.
The same measurement narrowed the pre-dial gap: Clara's acknowledgment lands inside the ~2 s gap, leaving only about 0.6 s of true silence there. The only real dead air in the whole transfer is the 5–9 s thinking window before she speaks.
During the transfer itself, mostly no. 2 of 147 callers hang up while waiting — 1.4%. 135 are confirmed to have stayed on the line. The wait is worth fixing because it is a bad experience, not because it is measurably losing people.
That figure only covers the wait, though. It does not count the callers who were handed to a silent line and gave up after the bridge — those are stamped connected and look like successes. Read this 1.4% as "the wait itself rarely drives people off", not as "transfers rarely fail".
Note when the two left: both hung up at 21 seconds, right on top of the 18.5 s median time-to-human. That is the tolerance threshold, and it sets the budget. Any fix has to keep the wait comfortably under about twenty seconds — today the median sits just below the line and the p90, at 34.3 s, sits well past it.
This was flagged on two recordings in the previous version. All 30 retained recordings have now been audited, and it got worse rather than better.
Of 12 auditable transfers stamped connected: 7 demonstrably reached a human — a real two-way conversation is transcribed. The other 5, or 42%, reached music then hard silence: hold music continues 12–17 s past the answer instant, then 16–102 s of silence with no far-side voice, ever. The caller waits, then hangs up on nothing.
The recording-artifact explanation is ruled out. The pipeline plainly captures the far side — 7 of these same calls carry full two-way conversation after the bridge. The silent calls are not a recording gap. They really reached no one.
Two more recordings, unstamped, caught the destination answering with an explicit voicemail prompt — "Please record your message… [beep]". So an automated path on that line demonstrably exists.
N=12, so the true rate could plausibly sit anywhere from about 28% to 85%. The direction is not in doubt; the precise figure is.
Every auditable recording belongs to one PM number. The other property's number has a single unauditable recording, so there is no contrast and no basis for saying whether this is one line's problem or both.
And the ring-window audio is not a tell. All 13 auditable ring windows carry hold music or ringback, and the cadence does not predict the outcome — successful and silent transfers sound identical while ringing. We cannot detect this before the answer.
This page previously said the briefing was generated and discarded. That was wrong, and it was wrong in the expensive direction.
On our native-Twilio conference transfers the briefing is always read aloud to the PM. There is no off switch — not require_acceptance, not any other field. Fede confirmed it by dialling through the flow live, and the ElevenLabs documentation says the same. The caller-side audit missed it for a simple reason: it plays on the Twilio leg to the PM, and the ElevenLabs recording only ever captures the caller's leg.
Because nothing constrained its length, it grew. 25 words on average — roughly 10 seconds of synthetic voice, 21 seconds at worst. The caller is on hold for every one of those seconds, on top of the ring. And it is largely wasted: callers repeat their whole situation to the PM anyway.
From the raw meeting transcript, not a recap. Joanna says callers hang up mid-transfer "because they don't think it's going through to a person" — the caller-experience findings above, described independently from the other end of the call. She finds the briefing too long and repetitive, would shorten it or drop it entirely, and notes that vendors already talk straight over it.
The briefing now has a contract instead of free rein. It says what we actually know and stops:
Expected effect: about 10 s of robot voice becomes 1–2 s, and the caller's hold shrinks by the same amount. The PR also fixes the mechanism that let this drift in the first place — tool descriptions were being synced by no script at all, so the written contract and the live agent were free to diverge.
One check outstanding: whether the platform accepts an empty briefing value. It needs a single live dial to confirm.
New from the recording audit, and it reframes the 42%. Of the 7 transfers that demonstrably reached a human, 5 open with 12–33 seconds of hold music before any person speaks. That is not the ring — it is after the line answered.
So the PM line very likely answers every incoming call with a hold or queue system. On the good calls someone eventually comes out of that queue. On the 42%, nobody ever does. The caller hears the same thing either way; the only difference is whether a human arrives.
That sharpens the one question this investigation still cannot answer from data: what actually answers that line? Fede's planned test calls are the step that confirms it.
| Old claim | Status | What is true |
|---|---|---|
| 16.5 s median silence | Mislabeled | The duration is roughly right — last word to the destination answering is 18.5 s median. It is not silence. About 9.5 s is ringing, and Clara speaks during the rest. |
| 9.5 s ElevenLabs post-tool seam | Refuted | That 9.5 s is ring time. The actual post-tool seam is about 2 s. |
p90 lands exactly on response_timeout_secs: 20, so a timeout is being waited out | Refuted | Coincidence. 20 s is simply the p90 of the ring-time distribution. No timeout mechanism is involved. Do not shorten it — it does nothing. |
| "Silence — nothing is running" | Refuted | Clara is thinking, then she speaks, then the phone rings. Work is happening throughout. |
| N=30 is representative | Holds up | Re-derivation reproduces that window to the decimal, and the wider April–August population (N=137) shows the same shape. |
| Transfer tool-error alerting is an open gap | Stale | Already shipped. |
| The no-pickup recording is deleted | Stale | Retained since #5459 when the caller spoke. |
8a25dd40 shows a recording-window bug | Refuted | Not a bug. The caller hung up 16 s before the pickup, so there was nothing to record. The existing logic classifies this call correctly. |
| The PM briefing is generated and discarded, never played | Refuted | It is always read aloud to the PM, with no off switch — ~10 s of robot voice the caller holds through. Capped by PR #5579. |
| The PM's carrier voicemail is unmonitored | Refuted | She receives her voicemail normally. The gap is that PropFlow cannot see it. Closed by PR #5580. |
We cannot cut total transfer time by 50–80%. The largest single slice of the wait is the PM answering their phone — 9.5 s of the 18.5 s median. That is an operations question, not a latency bug, and no config change touches it. What we can cut is the perceived silence, by roughly 80–100%.
| # | Change | Effort | Expected effect |
|---|---|---|---|
| 1 | Set pre_tool_speech: "force" on transfer_to_number. The identical change on transfer_to_agent is already measured. | Config one-liner | Cuts dead air. Measured −47% on the sibling tool: 8.06 s to 4.25 s. |
| 2 | Add soft_timeout_config to Triage. Leasing already has it; triage does not. | Config | Brings triage in line with the agent that already behaves better. |
| 3 | Fill the ring window with a bridging line. Sanctioned by Fede's ruling — see Resolved, below. | Prompt edit | Covers the ring window, which nobody currently speaks into. |
| 4 | Disable interruptions during the transfer tool. 18 of 230 transfers silently died because the caller spoke during the tool window; 9 are stamped "abandoned due to user input". | Config one-liner, with precedent | Recovers roughly 8% of transfers that currently vanish. |
| 5 | Route by destination. One PM number rings a median 26 s; the other rings 12 s. | Routing change | Halves the ring wait for callers currently sent to the slow number. |
| 6 | Do not touch response_timeout_secs. | — | Zero effect. It is never reached. |
| 7 | Stop reporting connected as success. Relabel it answered. | Rename | Our own dashboards stop overstating how often a caller reaches a person. |
| 8 | Far-side-voice classifier inside processPostTransferRecording, where the split audio already sits in memory. Shipped — PR #5580 | Low — no new capture or API | 14/14 on the labelled real set. Stamps answered_no_voice, voicemail_message_left or no_pickup, writes the caller's message onto the conversation, notifies the PM. |
| 9 | Cap the PM briefing. Nothing constrained its length, so it ran ~10 s of robot voice into the caller's hold. Shipped — PR #5579 | Contract + sync fix | ~10 s → 1–2 s. Caller hold shrinks by the same amount. |
On #3, the "no bridging lines" rule is narrower than it looks. It applies only to the generic branch, the vendor branch already permits a bridging line, and no test pins the ban. So this is a free edit, not a fight with the harness — and the agent is already making that edit for us on most calls.
Bridging lines are not an exception. Across all 147 Camellia transfers, 108 say one — 73%. Only 39 are the compliant bare acknowledgment the prompt asks for.
The single most common line is literally "Sure, one moment." — said 25 times. That is the exact phrase the prompt bans. Another 37 or so are variants of "let me connect you with the property team right now", across seven phrasings.
No complaint traces to any of them. So the question is not whether a bridging line is safe. It is whether the prompt should describe what the agent already does three times out of four.
The reason this drifted so far is structural: there is no drift guard on transfer_to_number. Nothing compares the written rule to the spoken behaviour, so the two diverged to 73% unnoticed.
The ban is also recent. It arrived on 18 July. The June design doc that preceded it assumed a "One moment." line existed — so the ban reversed an assumption the design was built on, and production never followed it.
Her pre-transfer line ends in "…" in 36% of transfers — 53 of 147. Her baseline rate on every other utterance is 14%. That is a 2.6× elevation specific to the transfer turn, which is exactly where you would expect clipping if the tool fires while she is still speaking.
Inference, not proven Two ways this could be innocent. The ellipsis may simply be an ElevenLabs marker for trailing speech. And there is a length confound: bridging lines are longer than "Sure!", and longer utterances may trail off more often for reasons that have nothing to do with the transfer. The 2.6× concentration on this one turn is hard to explain away, but neither explanation is ruled out.
The recording audit that settled the hold-music question did not settle this one. It stays open.
Prompt rule: agents/clara/lib/voice-agents/triage.ts:399
On #6: measured tool latency is 0.23–0.35 s, and response_timeout_secs sits at its default on 77 of 78 tools. It is a red herring. Leave it alone.
Dropped from the old plan: "open an ElevenLabs support ticket about the pre-dial window." There is no pre-dial platform window. There is nothing to escalate.
An earlier version of this page called the PM's carrier voicemail an unmonitored black hole. That is not right, and the correction matters. The PM receives her voicemail normally. A caller who lands there is not shouting into nothing.
The gap is entirely on our side. When a caller reaches voicemail, PropFlow stamps the call connected, keeps no record that a message was left, and shows nothing on the conversation timeline. Anyone reading our data sees a successful hand-off. That is the defect — blindness, not loss.
Evidence: transfer-transcript-verdict.ts:22-30
transfer_to_number.Outcome labelling shipped on 6 August but was scope-cut to labelling only, and its default assumed success. The classifier inverts that default and does the rest of the job:
answered_no_voice, voicemail_message_left or no_pickup, each with its basis and timing recorded for analytics.14 of 14 correct on the labelled set of real calls.
Rechecking the 42% against it: the classifier overturns exactly the 5 of 12 — and downgrades none of the 7 real pickups. The finding survives its own fix.
Yes, and the decision is already locked. A decision doc from 16 June, locked by Fede, specifies: notify the PM on no-answer, and route the caller to our own recorded voicemail. It is Phase 4. It has not been built. So the answer is: designed, decided, not built yet.
docs/planning/unknown-caller-transfer-no-answer-detection.md, 16 June 2026. Dropping the caller silently today is an owner-decided seam from 5 August, not an oversight.
The reason is structural, and it is worth stating precisely so nobody proposes a fix that cannot work.
Twilio's answering-machine detection is a creation-time-only option. It has to be set when the call is created; the participant and call update APIs cannot switch it on afterwards. And ElevenLabs' transfer_to_number exposes no passthrough for it — the config surface simply has no such field.
Put those together: the outbound leg is ElevenLabs' call, created by them, and detection can only be enabled at creation. Nobody is in a position to turn it on. Not us, not through config.
Voice Insights does not rescue this. Its answered_by field is an AMD readout rather than an independent signal, it is a paid add-on, and the Silent flag detects missing RTP — a broken audio path — not a voicemail greeting.
One line explains the whole mislabel. Music-then-silence produces no transcript phrases. So the transcript assessment finds nothing to judge, and the code falls through to its default: a completed outbound call counts as connected.
post-transfer.ts:1063
Worth stating plainly, because it decides what is still worth building. The classifier runs after the call, minutes late. It rescues our reporting, puts the caller's message where someone will see it, and makes the 42% self-measuring instead of something we find by hand-auditing recordings.
It does nothing for the caller sitting on a silent line right now.
post-transfer.ts:1030, after splitDualChannelWav
The motivation has shifted. Detection is no longer the point — the classifier already detects. The reason to own the dial is live rescue: acting while the caller is still on the phone rather than telling us afterwards. Both variants below give us that, because in both cases we create the outbound call. This is Phase 4 territory.
| Variant | How | Trade-off |
|---|---|---|
| A — take over the dial entirely | Place the call ourselves with async detection and message-end detection, plus a status callback. Async means detection runs alongside the call rather than delaying it, so no dead air is inserted. Detecting the end of the greeting is what lets Clara speak after the beep. | Most control, most rewiring. We take ownership of the leg ElevenLabs currently manages. |
| B — the proxy number | Keep the ElevenLabs conference transfer exactly as it is, but point it at a Twilio number we own. Our TwiML answers and dials the PM onward with detection enabled and answer-on-bridge set. | Cheaper. No agent config rewiring, and the conference warmth survives. Adds one hop we operate. |
Variant B is the one to look at first if Phase 4 feels too large to schedule — it buys the detection without the rebuild.
Either variant extends the locked June design in a useful direction. That design covered no answer. Detection covers answered by a machine, which is what the 42% actually are.
Four data-quality problems, all of which bias our own reporting toward looking better than reality.
| Finding | Effect on our numbers |
|---|---|
transferredAt is stamped at the end of the AI leg, not when the tool fires. | It overcounts transfers by 7.8%. 18 of 230 are stamped for transfers that never happened. |
| Outcome stamping only began 31 July. | The single no_pickup on record is a floor, not a rate. Do not quote it as a rate. |
| "Connected" is an upper bound — with a confirmed live false positive. | On 2026-08-04 22:05:59 the caller hung up before pickup. The PM answered anyway, and the record is stamped transferOutcome: connected against a 120 s dial. The residual is acknowledged in code at post-transfer.ts:823-826. |
| 10.2% of transfer calls are followed by a callback within 15 minutes. Six of those came back within 25 seconds. | Consistent with dropped hand-offs that our outcome field records as successes. |
| The human-leg column contained negative durations, as low as −16 s. | A join bug. Any human-leg figure quoted from the old version is unreliable. |
| Dead air is flat at 8–10 s median across all five months. | Good news: nothing regressed. This is the steady state, not a recent break. |
| Behaviour | Covered? | Note |
|---|---|---|
Pre-dial window on transfer_to_number | No | The drift test covers transfer_to_agent only. |
| The "no bridging lines" rule | No | No test asserts it. That is why live behaviour drifted to 73% non-compliance unnoticed. |
| A triage→human scenario | No | Does not exist. |
| No-pickup does nothing | Yes | A test asserts this as correct. It is a deliberate seam, so changing it means changing the test on purpose. |
| Transfer tool-error alerting | Shipped | The old version listed this as open. It is not. |
The minimal additions worth making: pin the pre-dial window for transfer_to_number, add a triage→human scenario, and pin whatever we decide about the bridging line. None of these are built.
transfer_to_number drift guard is added — its absence is what let the gap reach 73%.The one thing the data cannot settle, and now the most interesting question in the document: 5 of 7 real pickups begin with 12–33 s of hold music, so something is queuing every caller. Confirmed by Fede's planned test calls, or by simply asking the PM team what handles that line when staff are busy or after hours. Cheapest first — and it may explain all five silent transfers outright.
The motivation has changed. Detection is done; what owning the dial buys is live rescue — acting while the caller is still on the line instead of learning about it afterwards. Variant B, the proxy number, remains the cheaper way in. The product question of what Clara does when a machine answers rides along with this and is worth deciding when it is scheduled.
One PM number rings a median 26 s against 12 s for the other. That gap is ours to route around, and nothing has been done about it.
The last unverified piece of PR #5579. When we know neither a name nor a topic, the contract sends nothing — and we have not confirmed the platform tolerates an empty value. One live dial settles it.
Both fixes are written and their PRs are open, waiting on the review bot to come back up. Once they land, the caller's hold gets about ten seconds shorter and the calls that reach nobody stop reporting themselves as successes. What remains is the question we cannot answer from our own data: what is on the other end of that PM line.
transferredAt. Ten of them — all dated 2026-05-21 — are replayed conversations. Including them would double-count April traffic, so every population figure here uses the remaining 137.connected transfers and 13 have an auditable ring window.ParentCallSid is not usable — 0 of 230 transfers have a child leg, because the dial is an independent outbound-api call rather than a child of the inbound one. And transferredAt marks the end of the AI leg, not the transfer instant. Both were corrected for here; either one taken at face value produces wrong seconds.