2026-09-02 — Morning report: missed transfers, deep inspection & turn-on readiness

A follow-up pass on the same failure this page already documents — this time tracing the last 14 days of real transfer attempts end to end: what happened, why Johanna never sees it, what Clara already knows but doesn't say, and what it would take to safely turn the alert switch on.

2026-09-02 · Camellia House · Proposed — pending Fede's review · nothing shipped overnight · evidence in session 004 scratchpad (transfer-data/, transfer-mechanism/, caller-context/, frontdesk-benchmark/, coworker-emails/, email-corpus/)

1 · What actually happened (14 days, 60 voice calls)

• Six failed hand-offs are stamped "resolved" in our records (incl. Paul and Desiree). Three calls where someone clearly asked for a person are tagged "none / ghosted." Two open tickets (Desiree, Maxwell Weekley) are past deadline.
• The only failed-transfer email the office got in the fortnight (Maxwell, 8/30) came from an unrelated lane. Desiree's went to hello@propflowai.co.
• Today (9/1): three transfers to the office line — 11:19 AM "leasing agent please" (86s leg), 1:03 PM Paul (21s), 1:11 PM "front office" (30s). None produced an email, ticket, text, or callback. Paul's only email reached the office at 8:48 PM, hand-written by Fede's other session. Clara's own words to him: "I only have a balance snapshot, not a payment or credit history."
• Unresolved conflict for Paul's 21-second leg: Twilio says the office end "answered" (the office number forwards to a cell, so a forward/voicemail box counts as answered); no audio proves anyone spoke; Paul heard nothing. Our detector called it "no pickup." Treat the carrier's "answered" as unreliable on a forwarded line.

2 · Why Johanna sees "missed call from Clara"

• The hand-off is ElevenLabs' native transfer: a separate outbound call from Camellia's main number (+1 844-510-1007). All 19 legs show that as caller ID. Carrier rules only allow passing the original caller's number through on a Twilio-side bridge of the same inbound call — not on an independent outbound call. So caller-ID passthrough is a rebuild of the transfer, not a setting. What she gets today: a two-word whisper (caller's name or "Unknown caller"); she cannot decline the call; no answering-machine detection on the leg.
• After a failed leg, Clara says nothing; the caller's line ends the instant the office leg ends. No "leave a message," no text.
• After-hours take-a-message IS shipped (prompt-gated on office hours) but fails open — dials a dark office if a property's hours are missing.

3 · The intelligence gap (what we know vs. what reaches whom)

Six of the eight facts a proper "what we know" line needs are one existing function call each. Only the charge breakdown needs new AppFolio data work.

Other session today (Gera): merged "stop guessing the balance" (Clara now says she only knows the total and transfers) + an open PR adding last-payment amount/date. Nothing gives her lease-status-on-the-call or a breakdown. The six options on the 9/1 unbilled-rent page are all still unpicked.

4 · The email, done like a coworker with system access

Bar (measured, 318 real internal coworker emails): subject ~3 words naming the thing; body ~50 words; ask up front; nothing said twice; no meta-commentary; bare-name sign-off. Front-desk training adds: never editorialize or predict on the caller's behalf — paraphrase, quote only when wording matters. Shape: lead line → facts line (required when a fact exists) → optional quote → ask with number → "Clara."

Paul, as the record actually reads:

Raul (spoke into a silent line, 8/29):

Unknown caller, asked for the office (today 1:11 PM):

Transfer answered by a person → no email (the human already has it live).

Banned: "I took a message", "the line picked up but nobody was there", "this is the only copy", "the conversation has everything we have", "this needs a person to follow up", "Clara said:", any first-person offer by Clara to do the follow-up, any speculation where a fact exists, any non-English. Harness asserts: ≤55-word body, subject ≤8 words after the name, ask present + number, facts line present when a fact exists, ≤1 quote, no repeated sentence, English, no email on connected transfers, exactly one email per failed transfer.

5 · Decisions (pick one per line; recommendation first)

6 · Turn-on checklist (after D1-A lands)

1. Hardening PR merged, dark.
2. Willows robot-call proof: failed transfer → exactly one email matching the spec; connected transfer → none; silent-line message → quote captured.
3. Set Camellia's escalation email (D2).
4. Confirm office hours are set (after-hours path fails open otherwise).
5. Flip transferMissedOutreachEnabled at Camellia (script, Fede's go).
6. Watch the first 48h: every email reviewed against the spec; any false "missed" → pull the switch.

The original consolidated doc this report builds on — RCA, decisions, field research, and email design.

RCA — The voicemails nobody heard

Camellia callers asked to leave messages for the office. This page shows what they actually said, word for word, and every reason those words reached no one.

2026-08-31 · Camellia House · RCA complete · single consolidated doc — RCA, decisions, research, and email design in one page

What callers said — the recordings, verbatim

Three further recordings (Aug 11, a vendor; Aug 14, Metropolitan Building Maintenance; Aug 22, a prospect who waited 94 seconds) show the same signature: answered, then nothing. All five far-side transcripts were searched for any mailbox greeting, "mailbox is full," a beep, or a menu — zero hits across all five. And three callers in the same period did leave successful voicemails — on those days a working mailbox picked up at exactly 18 seconds. The failure is intermittent, and it lives on the far-end phone, not in a pattern we control.

Every failed transfer on record — the office line

All 15 transfers to the current office line that reached no one, from the full Twilio history (152 calls). "Duration" counts from the moment the line picked up. Grading of outcomes only began Aug 9; earlier failures are identified by their quick-drop signature.

Not shown here: Camellia transfers also went to a second line historically (59 calls, 7 quick-drops of its own — including Kenya Jenkins' dead transfer on Aug 17) and a third briefly in spring. This table is the current office line only. 9 of the 15 failures happened when the office was closed — calls that should never have been transfers at all.

Impact

Root causes — the five-layer failure

1 · The line itself: answers, then silence primary

The transfer destination has been a personal AT&T cell since May 20, when the office number and the transfer target were split during a cleanup and the transfer side was set to a staffer's cell — before that, transfers rang the actual business line, which took voicemails properly. On the recorded failures the cell "answers" and produces no audio at all: the documented signature of device-side behavior (call-screening apps, car-Bluetooth auto-answer that fails to route sound) — AT&T's network does not do this on its own. Ruling (Fede, 08-31): the property controls this line and always will. Every fix must live on our side.

2 · The classifier: a message spoken into silence cannot be credited proven bug

The rule that recognizes "caller left a voicemail" requires a timestamp for when the far side went silent. A line that was never active has no such timestamp, so the rule can never fire — every message left on a silent line falls through and is filed as a dead outcome. This is why Raul's message vanished: not judgment, arithmetic. We record everything ("recording is ground truth") and then don't use the recording.

3 · The alerts: delivered to a black hole, then self-silenced verified in prod

A failed transfer opens a "callback owed" record whose only email goes to Camellia's escalation owner — hello@propflowai.co, which no one reads. Sending that email suppresses the direct page to the mailbox the team does read. The record is flagged to never send reminders. And the promise tracker then grades "let me connect you with someone" as kept, because an email was delivered. Every layer reports success; no human hears anything.

4 · The evidence: deleted by design contributing

When a machine greeting is detected by transcript, that processing arm deletes the recording and doesn't store the matched phrase. The four calls most likely to contain a "mailbox is full" announcement destroyed their own audio. The investigation had to be run on the five calls that happened to keep theirs.

5 · The design: no path except the dial contributing

Clara already knows the property's office hours (an "is it after hours?" flag is computed and delivered into every call) and already has a working take-a-message tool. But the transfer rules say: caller asks for a person → dial, no exceptions, no clock check. Maxwell called on a Sunday afternoon and Clara dialed a closed office's forwarded cell. Separately, the voice vendor ends Clara's side of the call a third of a second after dialing — she structurally cannot hear that nobody answered, so she can't recover in-call. Both facts were already documented (the "four ways to never strand a caller" investigation, decision D21 — still pending).

What did NOT cause it — suspicions checked and cleared

• The Aug-14 "announcement" change. It speaks to the caller, not the office line. The robot line read to whoever answers is the vendor's built-in behavior since March, with no off switch — and our only change to it made it 8 seconds shorter.
• Any code gate blocking voicemail. The full git history of the transfer path was traced commit by commit: no machine detection was ever removed, no timeout shortened, no keypress gate added. Statistics across all 152 calls show no shift after any of our changes.
• Vendor config drift. All 37 live voice-agent configs were diffed against the repo: every transfer destination is the correct dynamic variable; no stray phone numbers. (One unexplained anomaly remains: six recent dials to the old business line that no config can produce — open item.)

Process failures this RCA also owns

• The Aug-10 rule "a transfer voicemail emails nobody, ever" assumed the far mailbox is monitored — and the test suite pins that behavior as correct, so the defect is defended by a passing test.
• The caller-facing apology text shipped inside an approved batch that didn't list it; the order to gate it off at Camellia ("on at Willows, not Camellia") is still an unmerged PR while the texts keep sending.
• The prior handoff mis-stated the announcement mechanism, the gate status, and the time of Maxwell's call — each error survived until an independent check. Investigation altitude matters: three separate agents had to correct each other before this page could be written.

Fixes

Carried as five multiple-choice decisions, with recommendations, on the companion page: Why callers can't leave voicemails at Camellia — decisions D1–D5. In one line each: rescue and deliver the messages callers already leave · point Camellia's alerts at the inbox the team reads · finish gating the apology texts · stop stranding callers in-call (instant callback rescue, then owning the transfer dial) · call Maxwell and Raul back today. A Willows test harness for the whole lane is being built so every fix is proven on the test property before Camellia sees it.

Evidence trail

• Five dual-channel recordings re-cut from the transfer instant and transcribed via the production pipeline; transcripts in session evidence CSVs (agents 000, 2026-08-31).
• All-time Twilio call census to the transfer line (152 calls), joined to conversation records; before/after statistics.
• Full git history of the transfer path (Mar 24 → Aug 29); classifier rule and its missing-timestamp precondition verified in code.
• Prod reads 08-31: Maxwell's apology text delivery, the callback record's owner and no-reminder flag, the promise graded "kept."
• Carrier + vendor research: AT&T mailbox/timer behavior; live ElevenLabs config diff; competitor transfer-fallback features. Prior art: coworker map (D21), tour-day RCA, connect or take a message.

The problem, in one sentence: when someone calls and no human is available, Clara takes the message, and the team gets one plain email. Everything below serves that sentence; anything that didn't was cut (voicemail copies, mailbox-health conditions, per-property monitored flags).

Rollout, per the standard playbook: everything is deployed OFF at real properties → proven at Willows (harness drives all four failure shapes on demand) → Fede turns customers on, property by property. No step 3 without his explicit go.

Held separately, unchanged: Camellia's alert-inbox repoint (Fede: hold) · the Willows bench still transfers to Fede's cell (one-line change, his call) · the not-covered case from review: a caller who hangs up on Clara without engaging leaves no trace today — add to the email lane or not, Fede's call.

The research reference: what phone carriers actually do, how the industry detects it, and the Twilio/ElevenLabs capabilities we pay for and don't use.

Phone-provider quirks — what answers when nobody does

A working mailbox (the good case)

• Cell carriers roll an unanswered call to voicemail on a fixed network timer — AT&T's default is commonly ~20 seconds (settable 5–30s in 5s steps by dialing *61*…# codes from the handset). That timer is why Camellia's working-mailbox pickups landed at exactly 18 seconds every time: consistent timing = the network, not a person declining.
• A normal greeting runs several seconds, then a beep, then recording. Anything played into the line before the beep (like a robot announcement) is talking over the greeting, not being recorded.

A full or broken mailbox

• AT&T's network answers fast (seconds, not the 20s ring-out), plays a short announcement — documented wording: "The mailbox belonging to [name] is full. Please hang up." — and disconnects. No beep, no chance to speak. Verizon/T-Mobile behave similarly with their own wording.
• Signature from the outside: pickup in ~5 seconds, short audio burst, call dies ~4 seconds later. This matches several Camellia failures, though the surviving recordings happened to be the silent kind instead.

Answered into pure silence (the worst case — and Camellia's)

• No carrier network does this on purpose. A silent answer is device-side. Best-documented causes:
• Car Bluetooth auto-answer with no audio route — a known, reproducible bug class (Android Auto and various head units): the car answers the call but never routes sound, both sides sit in silence. Fits Camellia's 35–88-second silent connects.
• Call-screening features — Google Call Screen (Pixel dialers) pre-answers suspect calls, asks the caller to state their business, and silently hangs up on no-response, without the owner ever knowing. Carrier apps (AT&T ActiveArmor, T-Mobile Scam Shield, Verizon Call Filter) mostly block or divert before ring rather than answering silently, but a user setting of "send suspected spam straight to voicemail" can make a spam-labeled call look like an instant mailbox pickup.
• Spam labeling matters for us specifically: calls from VoIP/Twilio numbers with weak caller-ID attestation (STIR/SHAKEN level B/C) are more likely to be labeled "Spam Likely," which triggers those behaviors. A branded/verified calling number reduces it.

Things you cannot do from the outside

• No carrier exposes any way to check a number's mailbox state, ring-timer, or screening settings remotely. The only diagnostics are calling it and listening, or asking the owner three questions: is your mailbox full, do you use car Bluetooth, does our number show as spam on your screen.

Detection — knowing what answered, in seconds

Voicemail best practices — leaving and taking messages

• Leaving a message on someone's mailbox: wait for the beep — use beep-detection mode, never talk over the greeting. Business mailboxes have long greetings; detection timeouts must allow for it.
• The universal never-do (every major platform — Vapi, Retell, Bland, Amazon Connect — agrees): never silently drop the caller. Every fallback returns them to the AI, an offer to take a message, or a clear spoken outcome.
• "Failed transfer returns to the AI" is a standard, documented feature at Vapi and Retell. Amazon Connect ships a five-way answer classifier (person / voicemail-with-beep / voicemail-no-beep / not-detected / error) with a branch per case — including an honest "I don't know" branch, which is the right model for ambiguous answers.
• Taking the message beats forwarding for small teams: forwarding an office line to a personal cell is a documented anti-pattern (full personal mailbox, DND black holes, no call waiting, spam screening, the owner's number leaking to callers). A message captured with the caller's own words + callback number + urgency, delivered to a read inbox, out-performs a voicemail on someone's cell in every reviewed setup.
• Measure "reached a confirmed human" as its own alerted metric. A falling human-connect rate is the early-warning signal; ours was invisible, which is why weeks of failures surfaced only via caller complaints.

Twilio & ElevenLabs features we pay for and don't use

Twilio (all available today, none wired)

• Machine detection on the transfer dial — a parameter on the exact outbound call we already make. We have literally never requested it; the "what answered?" field is empty on every transfer ever made. <1¢ per answered call.
• Beep detection ("DetectMessageEnd") — waits through a mailbox greeting and signals at the beep, built precisely for leaving/taking clean voicemails. Unused.
• Press-1 call screening — a whisper prompt to whoever answers, bridge only on keypress. Unused; would make bridging into dead air impossible.
• Conference leave events with reasons — Twilio can tell us the instant the far side drops and why (no-answer, busy, hangup). We instead let the far-side hangup instantly kill the caller's whole call (the wrong leg holds the end-conference flag).
• Ring-timeout tuning — we accept the ~60-second default for dials to a cell phone that resolves in 20; callers sit through doomed hold that a 25-second cap would cut.
• Voice Insights silent-call tagging — Twilio's own dashboards flag calls that carried only silence. Nobody has ever looked; our dead-air epidemic was visible there.
• Branded calling / caller-ID attestation — raising our numbers' trust level reduces "Spam Likely" labeling, which is one plausible trigger for the silent screening answers on personal cells.

ElevenLabs

• Transfer screening — exists but locked for our account ("requires feature access — contact support"). This is the vendor's own version of "verify before bridging." One support ticket could unlock it and answer whether a failed transfer can hand the caller back to Clara. Outbound message to a vendor — needs Fede's go.
• Post-call webhooks — already in the stack but underused; the after-call review found us polling on a timer where the vendor pushes the real event.
• The agent_message contract — the robot line read to whoever answers has no off switch, but it accepts an empty string; we already cap it at 9 words. Worth setting to empty when a machine answer is suspected (needs AMD to know).
• Alternative transfer types (conference vs. SIP-refer) and any native voicemail-detection option in the agent platform — unverified; the same support ticket should ask.

How this maps to our build

Sources

• Twilio: Answering Machine Detection docs + FAQ/best practices; <Dial>/<Number>/<Conference> TwiML references; call-whisper/screening glossary; Voice Insights silent-call tagging; US voice pricing.
• AT&T: ActiveArmor documentation; ring-timer (*61*) GSM codes; network recordings archive for the full-mailbox wording.
• Google: Call Screen support docs. Android Auto community threads on auto-answer no-audio.
• Vapi assistant-based warm transfer; Retell transfer nodes + voicemail handling; Bland warm-transfer + voicemail-detection engineering blog; Amazon Connect "Check call progress" block.
• STIR/SHAKEN attestation explainers (Twilio trust pages et al.); SMB phone-system comparisons (ring groups / hunt groups).

How the field delivers this to property teams (researched 2026-08-31)

• EliseAI (market leader): no email — a task queue inside their own portal with push notifications, and phone/text reserved exclusively for emergencies (call the on-call rotation, then text everyone "accepted" so the rest stand down — a pattern worth copying when we do after-hours emergencies). Right for big operators whose staff live in their portal all day; wrong for a 2–4 person team that won't log into a second system for ~3 events a month.
• Every answering service studied (Smith.ai, Ruby, PATLive, AnswerConnect…): one plain email per message, immediately — caller, number, what they want, urgency tag, transcript link. Most add a daily digest ON TOP of real-time, never instead. Smith.ai's Slack integration is literally email-forwarding — build the email well and other channels come free.
• Verdict for our shape (small team, AppFolio, ~3/month): the one-plain-email design is what the evidence supports. At this volume, fatigue is a non-issue; the risk is the opposite — rarity — so the email lands in the inbox habit AppFolio already trained.
• Two failure modes ours must not have (both documented killing competitors' trust): duplicate/late sends, and a shared inbox where two people unknowingly work the same message (a simple "first reply claims it" convention covers this at our volume).
• Writing into AppFolio instead: confirmed unavailable. AppFolio's partner API has no notes/tasks/guest-card write endpoint — leads and work orders only. Even EliseAI falls back to emailed CSVs on AppFolio. A message that genuinely is a work order can become one; "call this person back" cannot.
• SMS to staff as the default: don't. The famous "98% open rate" stat is unmeasurable vendor marketing; serious vendors keep texting for emergencies only; and routine after-hours texts to non-exempt staff cells are compensable work time (real, modest wage-and-hour exposure for clients).
• Later additions, in order: morning digest for overnight/weekend batches (on top of, not instead of, per-message email) → emergency call/text tier when we handle after-hours maintenance → property name loud in every subject line from day one (multi-property clients).

Fede picked option A, the coworker note. Final wording ships only with his approval (PR held).

What's wrong with today's email — the "before"

Reads like a system log: label-stacked header, "Intent: General Inquiry" robot-speak, the caller's actual words buried or missing, no clear action, and at Camellia it went to an inbox nobody reads. Everything below fixes those four things.

Option A — the coworker note recommended

Looks like a short note from a colleague. One paragraph, their words, their number, the ask. Nothing else.

Option B — the message slip

The classic "while you were out" slip, digital: fixed fields, instantly scannable, same content.

Option C — note + morning digest

Option A per message, plus one 8 AM summary on business days listing everything that came in overnight/weekend: "3 messages waiting: Raul (tour), a vendor (invoice), Maxwell (for management)." The digest is a safety net for slips through a busy inbox.

Decision

• A — coworker note, per message. recommended, ships first
• B — message slip, per message.
• C — A now, digest added for the nights-and-weekends client once real volume is known.

Whichever you pick: subject formula is "Message from <name> — <what they want, in plain words>", the caller's verbatim words always appear, urgency lives in the subject not a label, and emergencies never come through this email at all (they transfer to the emergency line live). Copy ships only after you approve the final wording.

Fede's spec, 2026-08-30. Their office line (303) 789-3030 is hosted business VoIP (Level 3).