Customer phone-system recordings into PropFlow

What works today (proven 2026-10-28)

Pieces and the seam each reuses

The one decision: which engines run on a staff call

Privacy gate (Fede, 2026-10-28 night)

What two office days of calls look like against PropFlow (Oct 27–28, read-only)

Situs Group's phone-system export for Oct 27–28 was matched, number by number, against PropFlow's records for Situs. A number counts as "known" only when a prospect, guest card, tenant, lease or vendor record holds that exact phone number. Carrier caller-ID names are never used as identity. Nothing was written anywhere.

What this says for the privacy rule. Outbound calls are almost all to people we know (16 of 20 numbers), so "keep only known counterparties" would keep most of what staff do on purpose. Inbound is the opposite: more than half of office-hours callers are unknown to PropFlow (22 of 38), and carrier names suggest businesses, vendors and cold calls. Vendor matching is weak today because only 71 of Situs's 1,282 vendor records carry a phone number, so a "vendor with a work order" rule would miss most vendor calls until vendor phones are filled in.

38% of outbound dials lasted 10 seconds or less (no answer or voicemail). One tenant was dialed 5 times in 10 minutes on Oct 28. The longest outbound time went to a waste-hauling vendor (26 minutes over 2 calls). 24 people appear both in the phone export and in a PropFlow conversation, but in all but one of those threads the PropFlow side is a mirror of staff's own AppFolio texts and emails, not Clara. Two numbers that reached Clara after hours were PropFlow team test phones; one of them left three real-looking work orders at a Situs property that should be cleaned up.

Full tables (per number, per staff member, vendors, tenants with recent maintenance) stay in the session scratch folder; they carry customer names and never enter a repo or this page.

Practice days (Oct 29–31): the whole pipeline runs, nothing is written to PropFlow

Decided, Fede 2026-10-29 "Build the whole pipeline, transcribing to matching to the conversation, but don't write anything to PropFlow yet. A practice day or two where we log the transcript and what we would have done with it."

A local runner checks the Situs bucket every 30 minutes during office hours. For each recording it transcribes the audio ourselves (the phone vendor sends audio only; no transcript feed exists on Crexendo's side), matches the outside number to the person and the thread Clara would attach the call to, and logs the decision. Every call is transcribed during practice, even the ones the privacy gate would delete, so we can count what the gate would wrongly drop. The runner reads PropFlow, never writes it; the bucket is never touched.

The outside number was inside the WAV file on every call, so no CDR join is needed. Real calls use file-name shapes the test file did not (a letter-and-number suffix, some with no timestamp); the parser was fixed on the local branch and the fix goes into PR 3. Call direction is inferred from which party sits first in the tag and is marked as such until the practice days settle it. The test call matched a test prospect record at Zephyr that carries a PropFlow team number; that record is test data, not a lead. Full rows with transcripts stay on the Mac, never in a repo.

What comes after the practice days: if the gate holds (no real customer dropped, no personal call kept), PR 3 wires the same pipeline to the person's timeline (transcript, audio, "who called" label), proven on Willows, then Situs supervised week with the switch on, Fede's call.

Quality check of both office days (Oct 29–30), graded against the transcripts on Nov 1

The practice runner stopped after Wednesday (its working folder was deleted, so Thursday never ran). On Nov 1 it was re-run over Thursday read-only, and an independent grader read every transcript of both days against the narrow "known" rule. Transferred calls are counted once.

The three misses. A Zillow prospect called twice about a 1-bed at a Lakewood building and booked a showing; his guest card was taken under his wife's name and phone, so his own number is unknown to PropFlow (2 calls). A caller locked out of an office suite, transferred to maintenance, looks like a commercial tenant whose phone is not on record (1 call, unconfirmed). None of these is fixable by the gate: the number was never on the record. Correctly dropped: a friend handling a tenant's account, a former tenant on a payment plan, a wage-garnishment law firm, two cold callers, a vendor call, an employer verification, a staff-to-staff call.

What the grader found wrong in the pipeline itself (all folded into PR 3):

• A real two-way call (a showing moved to 3:30) came back with one speaker label and was filed as "did not connect", losing its transcript. The attempt rule must use length only (under 10 seconds), never speaker count.
• Three voicemails left by the assistant were labelled as answered calls. An outbound call with only the staff voice is "left a voicemail".
• 10 of 32 calls produced two files (transferred between staff); 6 of those are kept and would show twice. One timeline entry per call.
• Extensions that are not a person rendered as names ("Assistance VA1", "System Administrator"), and the phone vendor's own extension rendered as Situs staff with direction "internal". Unmapped extension = company name; an unknown extension on the far side is an outside party.
• Speakers swapped or merged in about 8 of 43 transcripts (8 kHz mono audio through AWS Transcribe). Speaker 0 is never assumed to be staff.
• One prospect filed at the wrong home: he applied at one building but matched his older inquiry at another. The label shows the person and the canonical thread, not a property guess.
• Direction inference: 41 of 42 checkable calls right. Spanish: 2 calls, both transcribed cleanly.

Dry run of the attach (what the 18 kept calls would do): 17 land on a thread that already exists in PropFlow, 1 starts a new one; 10 prospects, 4 applicants, 4 tenants. Kept calls carry content staff said on the line: a co-applicant's name and number read aloud, a medical reason for breaking a lease, office side-talk about other people during a tenant's call. That is what capture-only means; it is visible to the customer's own staff only.

Grading table with masked numbers stays on the Mac. Next: PR 3 (trigger, transcription, timeline row, backfill entry point) merges dark behind the existing switch; the 18 kept calls attach through the same code after a dry run; then the Situs switch goes on. Before any real call shows at Situs: the heads-up to Situs and the Colorado consent check (Fede's two items), and the three test work orders at Dexter.

Option A practice run: what Clara's engines would have done (Oct 29-30)

We replayed the 18 kept Situs staff calls through Clara's existing after-call engines, on this Mac, read-only (0 writes, nothing sent). Four engines ran for real: work orders, lead capture, the after-transfer summary that books tours, and the company-brain summary. Tenant facts and policy notes have no engine yet, so one model pass stood in for them.

What a real build needs: treat staff as the person on the call, not as Clara; record what staff already did instead of acting on it; strip medical, third-party and fair-housing details before anything is saved; ignore years-old "open" work orders (tenants carry 7 to 39). Estimate: 2 to 3 weeks to a proven, default-off build, most of it reusing the after-transfer pipeline.

Nov 1: attached and live at Situs

Backfill of everything in the bucket (47 files)

Dry run matched the Oct 29–30 quality check file for file: 24 keeps right, 15 deletes right, 3 deletes the check already called misses the phone-match rule cannot catch.

Live path, on a test file:

• 09:16:00Z: file copied into the mapped test folder.
• 09:16:03Z: forwarder logs "queued".
• 09:16:06Z: processor logs "pbx_recording kept … org=org_sandbox".
• Failed-message queue: 0.

Production check, all 5 pass: an ordinary inbound call page; a transferred call shows as one entry; an outbound voicemail reads "Situs Group left a voicemail for …"; the conversations list (voice filter, page 2, a row opens); the admin row reads "Office phone recordings: ON".

What is set

Rollback: bucket notification off (one command, in that Terraform folder's README), or the admin row off.

Proof ladder climbed (testing playbook): unit-covered → read-only dry run over the real bucket against production records → Willows live run (sandbox company) → real backfill → live-path proof → production screenshots. Supervised week now running at Situs.

Follow-ups filed: transfer heading missing the second staff name; a staff greeting with a dropped name; a staff voicemail labeled automated; a raw placeholder on a prospect page.

PRs (merged): #23406 · #23403 · #24204 · #24205 · #24236 · #24256 · #24279

Call notes on the guest card (live at Situs since Nov 1; no separate setting)

One switch: Office phone recordings. When recordings are on, the call goes into the conversation and the note goes on the card (Fede, Nov 1: "if we have recordings enabled this should default to write notes, and add to conversations"). Tenants and vendors: never. Showings: shadow only.

Proven at Willows, Nov 1 (twice)

• Second call: conversation 17a181aa-… (the persona's own thread), card entry sent 2026-11-01T19:16:22Z, AppFolio test property 45, card 362
• First call: entry sent 2026-11-01T14:31:09Z, same card
• PRs #24240 + #24293 (filter) · #24237 (entry) · #24302 (hookup) · #24308 (drain) · #24330 (one switch) · #24333 (calls into the conversation) · #24339 (reads the card first)

Situs backfill, Nov 1

• Last week's 18 kept calls moved from their own pages into 16 people's conversations; the old pages are gone.
• 14 were lead calls; 11 got a new card entry, 3 were already logged by staff and were left alone. One entry needed a second pass after the sensitivity check timed out once; nothing unchecked was posted.
• Four were tenant calls: in the conversation, nothing on a card.

Open

• Situs has no Clara login name stored in our records, so Clara tells her own card entries apart by their text; storing the login is Fede's call.
• Follow-ups #24305: call state from stored flags, property-scoped card fallback, anonymized eval set.
• Monday Nov 2: a session watches the first real office day: one entry per kept lead call, none on a call staff already logged.

Timeline QA, Nov 4: why office calls look out of order on the person page

Fede opened a Situs prospect's page and saw call cards and transcript lines in a strange order. Every Situs office recording uploaded Nov 2–4 (55 files) was read back and compared with what the thread rows say. The page itself orders rows by their stored time; the stored times and the grouping are what are wrong.

Nov 5: what changed (before → after)

Page check, Nov 5 00:20 MT, production, Alyssa's conversation at Situs: the voicemail (1:03) and her call back (1:25) are two cards with the right headings. Still visible: the two calls overlapped in the same minute, so their transcript lines interleave by time under one "Outgoing" label; the timeline groups voice lines by time, not by call. Separate UI change, not part of this fix.

Open: Darwin's Nov 3 entry (a 3-line voicemail) now reads "called" instead of "left a voicemail" because the re-transcription no longer matches the voicemail phrase list, a string rule that should be a model judgement. Patricia Reed's thread, empty on Nov 4, now carries three Situs voicemails to her (two on Nov 3, one later), so the re-drive covered her as well. The AppFolio note already written for Alyssa's merged card cannot be edited.

Not a defect: Jessica Marsteller's two calls on Nov 4 (12:28 and 12:50 MT) are the Situs receptionist, not Clara. Both times she asked for Deiby or Miriam and was told "let me connect you"; the phone system uploaded no second leg either time, so whether the transfer rang unanswered is not visible to us. Cosmetic: the transcriber hears "Situs" as Citus, Cyrus, Isis, Playfish; a vocabulary hint would fix it.

Method: every file read from the customer's upload bucket (leg metadata, length, file-name stamp), compared with the thread rows and the ingest logs; page order confirmed from the thread component (rows sorted by stored time, voice segments labelled from the stored direction). The smoke login cannot open people pages at Situs (it holds no membership), so the page check used Fede's own screenshot.

To verify before the rule is final (one data point each so far)

• Which leg is which on an outbound staff call. Needs a second test: a staff user dialing out.
• A transferred call makes two recordings per Crexendo's docs. Confirm, and keep one timeline row.
• Upload lag (2 min once) and diarization quality on 8 kHz phone audio.
• The new bucket has no expiry rule yet. Propose 365 days, same as Clara's recordings.
• Recording consent: Crexendo records without telling the caller. Check Colorado's one-party rule applies to Situs before staff recording goes on for real.

Proof ladder and PR cut

1. Mapping + switch. Merged and live 2026-10-29 (the "Office phone recordings" row on the customer admin page, off).
2. Parser + trigger. Merged 2026-10-28.
3. Practice days (above): the full pipeline in log-only mode, Oct 29–31.
4. Transcription + timeline row. Proven on Willows: a staff-shaped recording lands on a test person's timeline with a Play button.
5. Situs supervised week: one Situs staff user with recording on, switch on for Situs only, Fede's call. Engines are a later decision.

Sources: Crexendo help center (retention, remote storage, recording), NetSapiens API docs, the repo map taken 2026-10-28. Bucket and key details are in the session notes, not here.