What we agreed on the September 9 kickoff call, what each side does this week, and the path to Clara answering your leasing line on Thursday September 17.
Contents: Leasing hand-off chain (client request 2026-09-19) · Go-live must-haves · Their phone provider and the forward · Client meeting 2026-09-16 · Org vs property architecture — overnight stress test · Readiness verdict · Tenants on a leasing-only line · Inbox test · Answer coverage
Proposed — pending review. Written 2026-09-19 10:30 MDT from Jason Fish's email of the same morning. Capability check against the code done 2026-09-19 11:15 MDT; see "What we have today."
Jason Fish, 2026-09-19 10:11 AM, to hello@ and the team:
Clara: "Let me connect you with someone on the leasing team — one moment." Never a staff name; the caller hears only "someone on the leasing team." She stays on the line while the ring happens.
Kat's number rings for about 20 seconds. No answer → Bev's number rings for about 20 seconds. Whoever picks up gets the caller with a one-line intro (still no names to the caller). A busy signal or no answer moves to the next person. Why 20 seconds: US mobile voicemail typically answers at 20–30 seconds, so each ring is kept shorter than that, and the caller's total wait across the chain stays under about 45 seconds. A "press 1 to accept" screen (so voicemail can never count as an answer) is a later refinement, not part of this build (Fede, 2026-09-19).
Once Clara hands a call off, she cannot take it back (the phone platform bridges the caller out of her conversation). So the message step lives on the PropFlow-owned line that did the ringing: "Nobody on the leasing team is free right now — leave your name, number and what you need after the tone." The recording is transcribed and written onto the same conversation record, exactly where Clara's own messages land today.
Within seconds the existing missed-call alert fires from that transcript: the email to the leasing inbox with the caller's name, callback number and what they wanted — the same alert Clara sends today. No text (Fede, 2026-09-19: "just email like we do today"). If Kat or Bev did pick up, nothing is sent.
Principle (Fede, 2026-09-19): one route per intent, each its own setting. Leasing person-ask → the ring list above. Maintenance → the maintenance call-center setting (already separate). Everything else Clara cannot serve → the client's normal office line, for now. They never share a value: "in the future maintenance will need a separate call routing," and any new module gets its own route rather than reusing another's.
| Piece | Have it? | Detail |
|---|---|---|
| Forward a caller to one person | Yes | The "talk to a person" setting holds one mode and one number. Camellia → Joanna uses it. |
| Try the next person if the first doesn't answer | No | The phone platform's hand-off dials one number, once, and Clara leaves the call. The chain has to be built on our own phone line (ring Kat, then Bev, then record), which Clara forwards to as its one number. Never done before; the first proof is a test call. |
| Know that nobody answered | After the call only | We detect "nobody picked up" by looking at the call afterwards. Good enough to send the alert; not usable to bring the caller back to Clara mid-call. A "press 1 to accept" screen would make this certain; deferred for now. |
| Take the message | Yes, but only while Clara still has the call | Hence the recording step on our line after the chain rings out; it writes to the same place. |
| Kat and Bev as people in the system | No | Neither number exists on any record today; they get added when the setting is turned on. |
| Option | How it works | Pros | Cons |
|---|---|---|---|
| A. PropFlow rings the chain (recommended) | Clara hands the caller to a PropFlow-owned "hunt" step that dials Kat, then Bev, with a ring timeout, and returns the caller to Clara if nobody answers. | We know exactly what happened (who answered, or nobody), so the text and the message are accurate. Works the same for every future customer as an ordered list of people. Ring time and order are settings. | New build: the ringing line (ring, next person, record), the write-back of the recording onto the conversation, and nothing else. Nothing in Clara's prompts changes: she forwards to one number as she does for Camellia. |
| B. Client builds the chain in RingCentral | Western Slope sets up one ring-group number in their phone system (Kat, then Bev, then their voicemail). Clara forwards to that one number. | Smallest change on our side; forwarding to one number already works. | Clara can't tell whether a human or their voicemail picked up, so she cannot take the message herself or know when to text. Caller lands in RingCentral voicemail, not with Clara. |
| C. Ring Kat only, then message | Clara forwards to Kat; no answer → Clara takes the message and texts both. | Half the chain with today's one-number forward plus the text. | Bev never rings; doesn't match the ask. |
| Before (today) | After (Option A, on) | |
|---|---|---|
| Leasing caller asks for a person | Clara takes a message; email to leasing@. | Kat rings, then Bev; a human takes the call when one is free. |
| Nobody free | Same as above. | The caller leaves a message on our line; the missed-call email goes to leasing@ within seconds, as today. |
| Proof | — | Real phones, not test rigs (Fede, 2026-09-19): the chain is configured with Fede first and Gera second on the Willows test line. Test 1: Fede answers — call connects. Test 2: Fede lets it ring, Gera answers — call connects on the second hop. Test 3: neither answers — message recorded, transcript on the conversation, missed-call email received. Call ids, timings and the email land on this page before the client hears a yes. |
Living checklist: updated in place as rows change. Last updated 2026-09-16 18:00 MDT.
Incident, 16:30 MDT: the moment the leasing inbox became the team-notice address (13:00 MDT), Clara's hourly "application awaiting review" reminder found every open application in their AppFolio and emailed 100 notices to leasing@westernslopepm.com at 14:00 MDT. Each repeats tomorrow at 14:00 unless stopped. Fix in flight: those reminders will not run at a company that is not live. Immediate mitigation (clear the address vs. turn reminders off per property) is Fede's call, asked at 16:30.
Turn on means Western Slope forwards 970-434-7000 to Clara's line. This list replaces the older readiness notes above and below: only what still stands between us and that, with what is proven and what is not. Everything not listed is either done and proven, or not needed for leasing day one.
Where things stand at noon Wednesday: the knowledge base, the guest-card sync, Kat's calendar, and the shared mailbox are all connected on Western Slope's real account. Text and email replies are proven on the test company. Two call paths (maintenance, talk to a person) are not built, and the calendar and notification settings are still off for them.
| Must have | Status | What it takes | Owner |
|---|---|---|---|
| Clara's 970 number routes to the real Western Slope company (the one with Kat's calendar, the mailbox and the knowledge base) | Proven. The number is routed to the company's front-door property, verified on the live record 2026-09-16. Fede's own test calls ran against the real company. An earlier note here saying it pointed at a deleted placeholder was wrong; it came from a stale copy of the routing file. | Nothing. One note: that front-door property's team email is set to Fede's address, so tour emails from the 970 line go to him until the company-level notification setting lands. | — |
| Maintenance callers are forwarded to their 24-hour call center with the menu digit pressed for them, one leg, no extra numbers | Call-center forward re-landed (dark state proven at the bench); on the 970 line Clara still handled maintenance herself on two test calls at 17:46 and 17:47 MDT — prompt fix in review. The transfer step carried a "digits to press" field filled per call; for every property without a call center it arrived empty, ElevenLabs rejected it and dropped every call after the caller's first sentence (14:58 to about 15:45 MDT, Camellia included). Re-land plan: same plain forward with no digits field at all, proven on the bench on a property with and without the setting before it merges. MVP decision stands (Fede, 2026-09-16 14:50 MDT): plain forward, caller works the menu. Clara tells the caller she is connecting them to the maintenance line and hands the call to Western Slope's call center; the caller hears the menu and presses for themselves, exactly as if they had dialed it. Proven twice on the real line today (handoff in 24 seconds, menu audible to the caller). Pressing digits for the caller stays available in the setting for later; skipped for launch because their three-level menu makes blind timing fragile. | Not done: code reverted, value kept. Western Slope's company record still holds the call-center number (set 14:48 MDT); it is harmless until the forward is re-landed. Re-land is the blocker for Thursday. | 003; values on their company = Fede's go |
| "I want to talk to a person": Clara takes a message and the team gets it by email; no live transfer (their choice) | Not built. Today the call would try to transfer to a number that is not set. | Same settings reader: a transfer number per role (empty for Western Slope means take a message), office hours (their appointment window, 9 to 5, default 9 to 5 when unset), and the team notification email below. | 003 |
| Emergency callers reach a human 24 hours a day | Covered by the maintenance route: their call center is the 24-hour line. | Nothing extra once the maintenance forward works. | 003 |
| Callers who are not prospects (current residents, vendors, rent questions, wrong numbers, vague callers) get a sensible answer | Run today, 4 of 7 dead-end. Wrong-number and vague-caller calls pass cleanly. Every call where Clara offers to connect the caller to a person (someone asking for a human, a rent-balance question, a renewal question, an unverified maintenance leak) says "let me connect you with someone" and then the transfer fails, because no office number is configured for the line. The leasing call also greeted an anonymous caller by a wrong name before any name was given. | Same fix as "caller wants a person": an office phone number set at the company level, with a take-a-message path when it is empty. The wrong-name greeting is a separate bug to chase. | 003, today |
| Spanish speakers are offered Spanish | Built; proven on the test line; never exercised on the real line. | Covered by the re-point test call. | 003 |
| Must have | Status | What it takes | Owner |
|---|---|---|---|
| Tours book on Kat's own calendar | Done in code, merged today. The on/off switch is gone. Whenever a leasing agent on the company has a connected calendar, tours book there; otherwise the company calendar is used. Proven end to end on the test company on Monday. | Kat's calendar is connected at the company level, so bookings land in her Outlook either way (as the company calendar today, as her own once her person record carries the leasing role). Verify with one test booking on Thursday morning before the line is forwarded. | Setting = Fede's go; proof = 003 |
| Prospect gets the confirmation and reminder texts | Proven on the test company, including the one-hour reminder. | Nothing. | — |
| The team gets an email when a tour is booked, moved or cancelled | Fix in flight, one PR. The company-level "escalation contact" address already exists in the product, so no new setting is being built; the fix makes the five team-notice senders fall back to it when a home has no team email (none of the 69 homes has one). Two PRs collided this afternoon; ours is closed, the remaining one is being reworked to the reviewer's shape. | Fede chose their leasing inbox (2026-09-16). The "must not be the connected mailbox" guard from Saturday was ruled incorrect (Camellia already works this way); a PR removes it, and the address is now set on Western Slope's company record and verified by a read-back (12:58 MDT). The remaining notification PR merges green, then one test booking on Thursday morning proves the email lands in leasing@. | 003; value = Fede's go |
| Must have | Status | What it takes | Owner |
|---|---|---|---|
| Texts to the 970 number get answered from the same knowledge, and can book, move and cancel tours | Proven on the test company. Not exercised on the real number because of the routing gap above. | One text exchange after the re-point. | 003 |
| Must have | Status | What it takes | Owner |
|---|---|---|---|
| Replies from prospects on email threads are read and answered from the leasing inbox | Reading today, replying held. Western Slope's leasing inbox is on the live push connection (subscribed since 2026-09-15, renewed through 2026-09-18), so new mail reaches Clara within seconds; no arming or nightly reader needed. Nothing has been sent from it: outbound replies are held by the company-level "Clara live" switch until Fede flips it. The nightly pull reader only matters for mailboxes Microsoft refuses push on, such as our own sandbox tenant; the test-company proof used that lane. | Session 000's switch chain merges (reader always on, page switch, gate), then Fede flips the switch on the customer page when he wants email replies live. | 000 builds; Fede flips the switch |
| Clara's first email to a new lead | Built and gated; nothing for it to answer yet. The first-email machinery (read the lead notification, find the home, write and send from the leasing inbox) is built and sits behind the company-level "Clara live" switch. But a read-only pass over 120 days of their inbox (1,050 messages) found zero AppFolio guest-card notifications. Every lead arrives as a Zillow relay: 407 in four months, 30 with a renter email address. Fede ruled Monday that Clara never answers Zillow relays by email, and session 000 is shipping that block. Net: until the client moves leads onto AppFolio guest cards, email lead intake on Western Slope is zero by design. | Decided (Fede, 2026-09-16 14:30 MDT): the rule stands, Clara replies to guest cards, not Zillow relays. Thursday ask for the client: turn on AppFolio's new-guest-card email notification to leasing@westernslopepm.com, so every lead (Zillow included, once it lands in AppFolio as a guest card) reaches Clara. Then Fede flips the "Clara live" switch when he wants replies on. | Fede decides; 000 owns |
| We can see Clara's outbound test emails arrive | Explained, not a bug. Tuesday's reply was composed and accepted, then our Microsoft test tenant refused to deliver it outside itself (trial-tenant ban, code 5.7.708). Western Slope's own mailbox is not affected. | Pay for the test tenant, or confirm delivery on Western Slope's own mailbox during the first real thread. | Fede |
From the client, still needed: confirmation that Zillow leads flow through AppFolio guest cards; nothing else. Message recipient, hours and emergency number are now covered by their leasing inbox, the approved knowledge entry, and the call center.
Superseded 2026-09-19. Fede: forwarding a caller from Clara to 970-434-7000 does not loop; this was proven on live calls (2026-09-18) and the main line is a valid destination for "everything else." The paragraphs below are kept for the RingCentral research only; ignore the loop analysis.
What it is. Western Slope's main number, 970-434-7000, is a RingCentral-hosted business line (Fede confirmed; a Twilio number lookup on it also comes back as a hosted/VoIP line carried over Level 3 Communications, the wholesale carrier RingCentral uses under the hood, not a plain home phone line). Clara's line, 970-822-0641, is a normal Twilio number. For comparison, Camellia's setup is different in a way that matters: the number Camellia's callers actually dial, 844-510-1007, is itself a Twilio toll-free number that PropFlow owns and controls — it is not a forward from some other phone system. Camellia's real office phone, 720-936-2043, turned out to be a cell phone (AT&T), not a business line at all.
Why Camellia's "transfer back to a person" doesn't loop, and Western Slope's might. Because Camellia's public number already lives inside Twilio (PropFlow's own system), sending a caller "back" is just PropFlow's own routing — there's no outside carrier's forwarding rule in the path to double back through. Western Slope is the opposite: 970-434-7000 is a real line sitting in RingCentral, and RingCentral's admin settings decide what happens to every call that hits it, including a call Clara places back to it. The standard way to wire "forward this business line to an outside number" in RingCentral is: the front-desk auto-attendant routes the call to one extension, and that extension is set to "Forward all calls" to the outside number (Clara). "Forward all calls" is unconditional — it does not ring the desk first, it just redirects immediately, every time, to anyone who dials that extension's path. If that is how Western Slope's forward is built, then when Clara transfers a caller back to 970-434-7000, the call lands on the same extension and gets redirected straight back to Clara — a loop, not a transfer to a human.
The fix RingCentral actually offers. RingCentral extensions have a separate "ring settings" mode: ring the desk phone(s) for a set number of rings, and only forward to an outside number if nobody answers or the line is busy. That is the mode Western Slope needs — not "forward all calls," but "ring the desk first, forward to Clara only on no-answer/busy." Set correctly, a callback from Clara rings a real phone at the office; only if no one picks up does it fall back to Clara again (which is an acceptable edge case, not a hard loop). This is admin-portal work only — RingCentral does this through the Admin Portal (Phone System > Auto-Receptionist / Users > Call Handling & Forwarding), not old-style *72/*73 phone codes, and there's no separate per-minute charge documented for forwarding to an external number on a standard plan.
One more thing to check while they're in there: caller ID. RingCentral normally passes the original caller's number through when a single user's extension forwards externally. But if the call instead passes through a call queue or a receptionist hop first, the caller ID Clara sees can get replaced with the queue's or the office's own number instead of the real caller's — which would break Clara's ability to recognize a repeat caller by phone number. Worth a quick real test call once the forward is set: confirm Clara's line shows the actual caller's number, not Western Slope's.
| Option | What it does | Loop risk on "get me a person" | What the client clicks |
|---|---|---|---|
| Forward all calls (unconditional) | Every call to 970-434-7000 redirects to Clara immediately, no ring at the desk | High — a callback from Clara hits the same rule and bounces straight back to her | Extension > Call Handling > "Forward all calls" (this is likely what's live today) |
| Ring desk, then forward on no-answer/busy (recommended) | Desk phone(s) ring first for N rings; only an unanswered or busy call falls through to Clara | Low — a callback rings a human first | Extension > Ring Settings > set desk phone(s) to ring, add Clara's number as the no-answer/busy forward |
| Forward-all plus a separate number for transfers | Keeps the simple forward-all, but Clara transfers "get me a person" callers to a different, non-forwarded office DID instead of 970-434-7000 | None, if such a second number exists | Requires Western Slope to hand over a second, unforwarded number — not confirmed to exist today |
Recommendation (Proposed — pending review): set Western Slope's RingCentral extension to ring the front-desk phone(s) first and forward to Clara only on no-answer or busy, rather than an unconditional "forward all calls" — this is the smallest change that makes "get me a person" actually reach a person, and it should be confirmed with one live test call before Thursday's cutover.
Sources: RingCentral — Forwarding calls to an external number; RingCentral Community — transferring a main number to an external number (click path, "forward all calls" behavior); RingCentral Community — forwarded-call caller ID behavior; RingCentral Ideas — outside caller ID passthrough on forwarded calls; Twilio Lookup v2 (line_type_intelligence) run 2026-09-16 against 970-434-7000, 970-822-0641, 844-510-1007 and 720-936-2043.
| Item | What the client said | Status |
|---|---|---|
| Ridgway home | Remote lockbox showing, ~3-hour drive, no in-person or live-video tours; code released only after the prospect texts arrival, they text on leaving, Jay changes codes every other week, no ID check; "carve that property out" of normal booking for now | Knowledge entry in progress tonight; custom lockbox flow later |
| Tour notice | One hour heads-up | Matches Clara's default |
| Showing hours | Weekdays 8–6, Sat–Sun 10–3; 30-minute tours | To verify against the WS settings |
| Weekend tours | Booked by a Friday cutoff; need a yes-confirmation or Clara cancels | Open |
| Reminders | 24 h and 1 h before | To verify against defaults |
| Application | Link 1 h after the tour, two more non-templated nudges | Open |
| Backup shower | Jonathan (maintenance), calendar to connect; possible second backup (Ryan/Fusion) if on Outlook | Open |
| Turn off AppFolio auto-reply before Clara goes live; CC Bev and Kat on Clara's replies at launch | Open |
Transcript: Client meeting notes
2026-09-16 incident fix: the Ridgway knowledge entry above was in the approved gold set but never reached what Clara reads — she told a caller Ridgway tours are in person. A loader + verify command shipped tonight so a fact like this can't go missing silently (see the onboarding playbook).
The fix for all 7 home exceptions, including Ridgway's lockbox flow, is ready to run (dry run places all 7, zero writes so far) — the write into Western Slope waits for Fede's yes.
Tested ten seams of Gera's org/property model overnight — settings ladder, calendars, mailboxes, phone lines, identity, isolation — read-only, against the Fairhaven test company and Western Slope's real reads. Cheap worker agents ran the probes; one Opus verifier checked every claim before it counted.
Result: 23 confirmed (4 high, 11 medium, 8 low), 6 already known and tracked on the isolation lane, 3 turned out not real, 2 couldn't be checked without writing.
Design of record: Gera's portfolio architecture.
| Seam | Rule | What we found | Expected | Observed | Evidence | Severity | Fix |
|---|---|---|---|---|---|---|---|
| attachments | R02 | Missed-call page for Western Slope goes to Fede's test mailbox | Missed-call notices go to the property's or company's own inbox. | Goes to Fede's personal test mailbox because a stale test field outranks the real one. | pm-contact-email.ts:173-208 | high | Western Slope data fix — Fede's go |
| settings-ladder | R31 | Leasing settings never look up to the company; each home answers alone | A property-level setting falls back to the company's setting. | Turning reminders off at the front door did nothing for Western Slope's 70 synced homes. | resolve-pm-action-reminder-config.ts:57-64 | high | PR #8962: reminders become a per-company opt-in (default off), resolver reads the company row |
| calendars | — | A cancelled or moved tour can silently skip the calendar | A calendar failure on update/delete is logged and flagged, same as on create. | Update and delete both give up silently with no failure record when the calendar can't be reached. | sync-tour.ts:1161-1162, 1232-1233 | high | dark PR tonight |
| calendars | R19/R20 | One dead agent calendar login blocks booking even though the company calendar works | With nobody usable assigned, booking falls back to the building or company calendar. | Western Slope's one connected agent's calendar token expired; there is no fallback to the company calendar. | sync-tour.ts:519-537 | high | design question to Gera's side (bridge) |
| attachments | R05 | Company calendar has no coverage list, so every home inherits it | A shared calendar declares which homes it serves. | The calendar code never checks the coverage feature phone lines already use. | resource-coverage.ts:176; sync-tour.ts (0 hits) | medium | design question to Gera's side (bridge) |
| calendars | R17 | Company calendar and company mailbox share one login | The calendar and mailbox are separate, independently rotatable. | Both point at the same stored credential, so revoking the mailbox connection would take the calendar with it. | channel-attachment.ts ATTACH#calendar#primary / ATTACH#mailbox#primary | medium | design question to Gera's side (bridge) |
| change | R32/R33 | Mailbox, calendar and setting changes leave no undo trail | Every structural change logs a numbered, reversible entry. | Four writers (mailbox, calendar, settings, vendor) skip the undo log; Western Slope's company row has no version number at all. | map-writers-logged.drift.test.ts:107-165 | medium | design question to Gera's side (bridge) |
| lines | R13 | Western Slope's phone line has no nameplate row saying who owns it | Every routable number has a record naming its owner. | The line routes correctly only because the code falls back to a hardcoded map. | phone-lookup.ts (ADDR#phone#+19708220641/HEAD missing) | medium | Western Slope data fix — Fede's go |
| lines | — | A property with no office phone hands the voice agent a blank transfer number | A caller asking for a person reaches someone, or hears a clear "can't reach anyone." | The transfer number goes out empty with nothing logged to explain why. | route.ts:570, 1241 | medium | dark PR tonight |
| identity | R43 | A manager who works at two companies can be filed under the wrong one | A call files against the company whose line was actually dialled. | The tie-break for which company a caller belongs to isn't filtered to the dialled property first. | pm-call-context.ts:250-286 | medium | dark PR tonight |
| identity | R09 | Property-to-company lookup is cached forever, including a missing answer | The property-to-company link is cached with a bounded refresh, not forever. | A property briefly missing its company id mid-backfill reads as company-less until the next restart. | phone-lookup.ts:634-670 | medium | dark PR tonight |
| identity | R09 | One of two identity checks in the chat agent isn't fenced to the company | Every place that resolves a caller's identity filters out other companies' records. | The second lookup relies on an earlier pin instead of checking the company itself. | conversation-manager.ts:3611 vs :7044 | medium | dark PR tonight |
| settings-ladder | R39 | Tour length is registered as a company setting but read from a separate shortcut | A registered setting has one path to its value. | The real value comes from a parallel shim, not the setting chain — the shape of Western Slope's 15-minute mismatch. | registry/keys.ts:139; settings-resolver.ts | medium | design question to Gera's side (bridge) |
| calendars | R16 | No way to say which agent covers which building | A building holds its own list of who covers tours there. | Every leasing agent in the company is eligible for every building; the first connected takes them all. | tour-calendar-pool.ts:39-43, 62-91 | medium | design question to Gera's side (bridge) |
| settings-ladder | R08 | Western Slope has no configured answer for "let me talk to a person" | A company going live has a deliberate answer for that request. | No setting exists at any level; both test companies fall to the generic built-in message. | human-handoff-route.ts:33-38 | medium | docs only |
| identity / isolation | — | Two error-handling blocks drop a lookup with no log line | A dropped lookup says why, so a blip reads differently from "no record." | A failed person fetch and a failed company check are both silently swallowed. | persons.ts:2410-2416; org-boundary.ts | low | dark PR tonight |
| mailboxes | — | Company-level email lookup gives up silently when a property has no company | Every rung of the notification chain that gives up says so. | Only the company-read failure is logged; a missing company id on the property logs nothing. | pm-contact-email.ts:83-95 | low | dark PR tonight |
| attachments | R01/R38 | Fourteen retired mailbox/calendar rows still sit on the live shelf | Ending a connection moves its row to the history key, never leaves it live. | 14 ended rows on the Fairhaven test company are still on the live key; code filtering is the only thing hiding them. | channel-attachment.ts:608-627 | low | Western Slope data fix — Fede's go |
| attachments | — | A blank property inbox silently swallows every notice | An intentional "send nowhere" is distinguishable from an accidental blank field. | No log line marks the case where the property's email field is blank rather than absent. | notification-recipient.ts:35-43 | low | dark PR tonight |
| lines | R41 | The code map, not the nameplate row, decides which building a number answers for | The address row is the single source of truth for who owns a number. | Working as designed; the written rule hasn't caught up with the shipped decision. | route.ts:640-668; phone-lookup.ts:263-290 | low | docs only |
| identity | R12 | The setting registry has 62 keys, not the 61 the rules say | Rule doc and code agree on the count. | Code is right at 62 (new human_handoff key included); the written rule is stale. | registry/keys.ts:13-20 | low | docs only |
| identity | R09 | The nameplate row is read with a bounded query, not a single get | The rule calls for one plain GetItem, never cached. | Functionally the same for a one-item partition, but implemented as a limit-1 query instead. | address-head.ts:329-345 | low | docs only |
| calendars | R18 | A person can only connect one calendar today | The rule describes support for several calendar providers per person. | Only a single "primary" slot exists per person; multi-calendar is unbuilt, not broken. | channel-attachment.ts (CHANNEL_SLOT_PRIMARY) | low | docs only |
Tracked on the isolation architecture page.
Bridge question to Smith trimmed on Fede's ask (2026-09-17 02:30Z, id stress-2026-09-17-org-seams-v2) to two design calls: dead agent calendar falls through to the company calendar or refuses; per-building coverage lists for calendars and agents. The other five are ruled already (settings walk up to the company, tour length at company level) or ship as dark hygiene PRs (change log on four writers, separate calendar and mailbox credentials).
Superseded by the checklist above on 2026-09-16; kept for history.
Verdict as of Tue Sep 15, 23:15 MDT — updates as tonight's proofs land.
| Channel | Works today (proof) | Gaps before Thursday | Size | Owner |
|---|---|---|---|---|
| Phone | Books, reschedules and cancels tours on the leasing agent's calendar; opens with a neutral bilingual greeting; handles callers with more than one home to show. Proven on a live test call tonight. | Maintenance callers need to be forwarded to the client's own 24-hour line instead of landing in our repair system. Callers asking for a person need a message taken with a real recipient, hours and emergency number from the client. Four small voice rough edges (asks budget twice, stacks questions, states a raw home count, one wrong-day reschedule). Bench calls for non-leasing callers (vendor, person, rent, renewal, wrong number, vague) did not complete tonight; rerun Wednesday morning. | Small (both fixes are narrow) | Session 003, Wed AM |
| Text | Passed all 5 test steps tonight: home facts, property rule overriding company rule correctly, company policy, and booking/rescheduling/canceling a tour. Recognizes a real tenant. | Needs a re-run now that the knowledge base was just refreshed, to confirm nothing regressed. | Small (re-test only) | Session 003 |
| Once a conversation exists, replies are correct and on-brand: right home, right thread, pet and deposit answers pulled from real policy, sent from the company's own leasing address. | Nothing yet sends Clara's first email when a new lead arrives from the property system — by design, pending Fede's decision — so today the email channel is silent on new leads. Reply reader: passed its live proof at 11:58 pm. A prospect reply on a Clara-started thread was picked up, filed, and answered with Thursday tour times. Earlier zero results were tests that sent brand-new mail, which the reader ignores by design. One open item: the outgoing reply was logged as sent but no copy was found, likely the test tenant's external-send ban; 000 confirms Wednesday. Push notifications for that mailbox also deliver. A test on 600 real inbox emails found only 3 wrong replies out of 600, but that number doesn't include new-lead emails, which aren't answered yet. | Medium (a decision, then a small build) | Session 000, Wed AM; decision = Fede | |
| Knowledge | Company and building information rebuilt today from real data. Tested against 100 real questions asked by real prospects: correct answers rose from 35% to 70%, wrong answers fell from 56% to 23%. "How do I apply" is answered correctly almost every time. | Two known miss patterns remain: math on tour times near closing time, and questions answered about the wrong building. Neither is a blocker — both are named and being tracked. | Good enough to launch; ongoing tuning | Session 002 |
Leasing first, forward the line, keep everything else exactly as it is. Clara takes over the leasing side of your main number and inbox. Maintenance keeps going to your 24-hour call center. Renewals come next, maintenance after that, each one built and tested with you before it is turned on — so if something breaks it never takes the whole phone line with it.
What this means for a leasing-only customer: a real tenant reaching Clara is still recognized, still gets the full repair conversation (photo request included) and full rent/lease answers, on every channel. Only the final ticket save is silently blocked, and Clara doesn't know that, so she can sound like she filed something that was never created. This is the exact Western Slope bug found this week, and it is a general product gap, not one customer's glitch.
| Option | What a tenant hears | Work | Risk |
|---|---|---|---|
| 1. Recognition always on, abilities gated by a company-level stage Recommended | Recognized by name either way. If maintenance/renewals is off for that company, Clara takes a message instead of running the flow. | Small. Move today's per-building check up to run before the ability grant, at the company level with a per-building override. | Low. No false promises; slightly less personal message-taking until the company turns maintenance on. |
| 2. Recognition itself off unless a tenant ability is on | A real tenant is treated as an unknown caller, message-only, no lease or rent answers. | Medium. New check before recognition runs, touches every other reader of "is this a tenant." | Medium. Simpler, but a resident asking their rent amount gets a worse answer even though we already know it. |
| 3. Keep today's model, set the switch on all 70 rows explicitly | Same as option 1, if every row is correct. | Small now, fragile later: a new building or missed row reopens the leak silently. | High long-term. Already happened once at Western Slope. |
Recommendation: Option 1. Fixes the coupling once, at the company level, without changing Camellia's experience, and matches Gera's portfolio design, which already resolves this kind of switch at the company or building level, nearest-wins.
Top gaps, ranked:
A. Recognition. Identity types are exactly three: tenant, prospect, unknown (src/lib/domain/identity/resolve.ts:148); staff are resolved separately by role, not as an identity type. resolveIdentity (resolve.ts:580) tries, in order: (1) tenant by phone (:618, via getTenantByPhone), (2) tenant by email (:626), (3) prospect by phone/email, best candidate (:633-640), (4) prospect by conversation thread, property-gated (:652-666). getTenantByPhone (src/lib/data/store.ts:865-877) resolves phone → Person via findPersonByPhoneAcrossOrgs (cross-org at the phone-claim level) → that Person's tenancies, hard-gated to the requested property only when a propertyId is passed; called bare (as most call sites do (agents/clara/lib/agent/conversation-manager.ts:3889,4011, agents/clara/lib/messaging/inbound-dispatcher.ts:300,571,799,1047) it checks every property in the caller's org. No switch disables recognition anywhere in this chain. Resident data source: PMS import PMS_IMPORT#org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38/ACCOUNT#appfolio#westernslopepm#17a5, stage "People and leases" ran 2026-09-13T16:20:08Z–16:22:54Z, wrote tenant:142, lease:142. Live counts (read 2026-09-15, consistent reads on base-table items): Western Slope occupancy rows = 356 (GSI3 OCC#org_c42d9150..., entityType index); Camellia property PROP#1773625953462 and Yale 25 Station PROP#1773625952029 both live under one org, org_jpco; Fairhaven (TEST) org org_53047a06-2c49-4231-92c2-6f2a7009149a.
B. Triage and routing. Voice: a single Triage ElevenLabs agent classifies intent and transfers to one of maintenance_tenant, maintenance_handyman, lease_and_billing, leasing, renewal_inbound, renewal_outbound, turnover_intake, unknown_caller (agents/clara/lib/agent/specialists/registry.ts:52-135). Known-caller greeting fails closed to a neutral open on any resolution error (src/lib/integrations/voice/triage-greeting.ts:1-30). The Lease & Billing hand-off has a spoken verification question when identity vars are empty ("are you a current resident, what unit?", see agents/clara/lib/voice-agents/triage.ts:466); the Maintenance hand-off has none and defaults straight to maintenance_tenant when no company is named (triage.ts:452-455). Text/email: one shared pipeline (agents/clara/lib/agent/conversation-manager.ts) composes a system prompt and tool list from composeCapabilities for every channel adapter (voice, SMS, email, AppFolio-sourced messages alike). forward_to_property_manager is a general escalation tool, not maintenance-specific (agents/clara/lib/agent/tools/index.ts:331). Emergency/after-hours handling (gas smell, fire, flooding, no heat) is voice-only: agents/clara/lib/voice-agents/maintenance-tenant.ts:121-159 (classification + 911 guidance + forced escalation) and agents/clara/lib/voice-agents/after-hours-message-desk.ts:1-38; no equivalent keyword-triggered urgency branch exists in the text/email maintenance or resident-services capability files.
C. Switches. Property.capabilityStage (src/lib/data/types.ts:3579-3585): {leasing, renewals, maintenance} each 'off'|'shadow'|'live'; absent or 'live' = fully live, by design ("existing properties like Camellia are never gated by omission"). .leasing reader was deleted 2026-09-14 (dead field). .renewals was never wired (temporal/activities/renewal.ts:113 still carries an open TODO). .maintenance is read in exactly one place, isDomainOutboundSuppressed (src/lib/domain/properties/computations.ts:112-117), called only from handle-create-work-order.ts:690-699: it blocks the ticket save, nothing upstream of it. Organization.claraLive (src/lib/data/types.ts:13634, default false, src/lib/data/dynamo/organization.ts:110) gates prospect/inquiry outbound sends only (src/lib/domain/organizations/clara-live.ts); not read anywhere in the tenant path. Organization.operatingModel is a UI descriptor with zero references inside agents/clara/lib/agent/capabilities. TURNOVER_WORKFLOW_ENABLED and other *_ENABLED env vars gate background Temporal workflows, not agent tool composition. Live values (propflow-prod, consistent reads on base-table items, 2026-09-15): Camellia (org_jpco): capabilityStage absent, claraLive=true. Yale 25 Station (same org): capabilityStage absent. Western Slope (org_c42d9150-...): operatingModel="centralized", claraLive absent (dark); of 70 properties (roster via proporg-index), 69 have capabilityStage absent and 1 (the synthetic western-slope-front-door listings row, not a real building) has {leasing:'shadow', maintenance:'off', renewals:'off'}. Fairhaven (TEST, org_53047a06-...): claraLive=false; the seeded test property fairhaven-homes has {leasing:'live', maintenance:'off', renewals:'off'} explicitly set.
D. Coupling. composeCapabilities (agents/clara/lib/agent/capabilities/index.ts:168-173): if (identity.type === 'tenant') { caps.push(maintenanceCapability); caps.push(residentServicesCapability); if (hasRenewalContext) caps.push(renewalCapability); }, no stage read anywhere in the file. Tool lists are cleanly separated (leasing.ts vs. maintenance.ts's TENANT_INELIGIBLE_TOOL_NAMES filter). One real prompt leak: the leasing-only prompt file itself carries a "RENEWAL CONVERSATIONS" section for a replying tenant with no property/stage guard (agents/clara/lib/agent/clara-leasing.ts:1682-1691). Greetings are cleanly forked per channel/agent, not shared. Answer to "can a leasing-only customer have zero tenant handling by configuration alone": no. A real tenant who reaches the line still gets recognized and still gets the full repair and rent/lease conversation; only the final ticket write can be turned off, and only for repairs.
E. Western Slope tenant walkthrough (code read, not executed). "Sink is leaking," text: dispatcher asks for a photo (agents/clara/lib/messaging/channel-capabilities.ts:43), then calls the ticket-save tool, which returns {success:false, parked:true} at handle-create-work-order.ts:694-699 with no scripted response for that outcome. Phone: same gate, reached after the voice agent's own repair workflow (agents/clara/lib/voice-agents/maintenance-tenant.ts:205 tells it never to ask for a photo by tool, only to mention texting one in). "Rent is due," text and phone: answered directly and correctly from synced lease data (agents/clara/lib/agent/capabilities/resident-services.ts:33; agents/clara/lib/voice-agents/lease-and-billing.ts:135,231), unaffected by any Western Slope setting. "I want to renew," text and phone: with no open AppFolio renewal cycle on file (the normal pre-cutover state), the renewal ability never turns on and the request is correctly forwarded to a human (resident-services.ts:37; lease-and-billing.ts:204), correct today only because no real cycle exists yet, not because of a deliberate gate.
F. Portfolio-architecture fit. Gera's design already generalizes exactly this kind of switch as capability_stage.<function>, resolved nearest-wins across org, group, and property (~/.claude/propflow-docs/artifacts/portfolio-architecture-how.html, solution section). Option 1 above reuses that resolver and the field already in prod; it needs no new mechanism, only moving the read to happen before the ability grant and adding a company-level default.
Jay is away from Sunday, so everything on the Western Slope side is aimed at Thursday and Friday. Each line names one owner.
| When | Western Slope | PropFlow |
|---|---|---|
| Thu Sep 10 | Jay: open the invite email, sign in, and paste the AppFolio API key where the setup asks for it. It is stored encrypted on our side; nobody at PropFlow sees it. Your Microsoft 365 admin: one approval for the company, covering the shared leasing mailbox (leasing@westernslopepm.com) and the company calendar. That is what lets Clara send from your leasing address. Kat: once she is added as a user, sign in and connect her own Outlook calendar, so tours land on it. |
Fede: send Jay the PropFlow invite. Keep building the knowledge base from AppFolio. |
| Fri Sep 12 | Jay and Kat: answer the knowledge review page — fees, deposits, pets, screening wording, application steps, tour hours. Jay: email Fede anything that lives outside AppFolio: lease form, fee schedule, application process, specials, "the more the better." Jay: tell us which properties are affordable or Section 8, so Clara asks the waitlist questions there instead of the standard application questions. Jay: fix the Ember Estates listing on your website and in the AppFolio marketing description so it says water, sewer and trash are included, not gas. Clara reads your own listing text, which is where the wrong answer came from (in your words: "it told me that water, sewer, trash, and gas were included. And I know that gas is not included, but I also know that it got that information from the Ember website, because the person who put that website together got it wrong"). We do not edit our copy of it; once you fix the source, Clara picks it up on the next sync. Kat: the tour rules — bookable hours and the towns she covers. |
Fede: send the knowledge review page. Set the showing rules per location: one hour minimum notice is already the default, so Kat only adds bookable hours and how much room to leave between towns; same-street tours book as one visit. Point "want a person" at leasing@ and maintenance at MCC. |
| Sat–Sun Sep 13–14 | Nothing. Call the test line if you feel like trying to break it. | PropFlow: run the full set of scenarios against your real homes and rules on the test line. Fix what breaks. |
| Mon–Wed Sep 15–17 | Whoever is at the desk calls the test line a few times and tells us what felt wrong. | Fede: tune from your feedback and the review answers. Confirm who on your side sets the RingCentral forward, since Jay is travelling. |
| Thu Sep 17 — go live | Jay or Jason: set 970-434-7000 to forward permanently to 970-822-0641. That is the switch, and it is yours. | PropFlow: watch every call and lead live all day. Same-day fixes. |
| Sep 18 onward | One hour a week with us: what Clara did, what to change. | Tune daily from real traffic for a full week before adding anything else. Then plan renewals. |
These came up on the call and are good ideas. None of them is needed to go live, and each one would push the date. They are written down here so they are not lost, with our recommendation for each.
| What you asked about | When | Our recommendation |
|---|---|---|
| Renewals | Phase 2, after a week of live leasing | Before we connect it, move renewals onto AppFolio's renewals function instead of lease amendments, and settle on one process and one template for the portfolio. That gives you the 6/9/12-month offer letters and the renewal reports, and gives Clara one way to do it. We will walk through it with you. |
| Maintenance | Phase 3 | MCC stays through April 30, 2027 regardless, so there is no rush. When we get there we look at the dispatching tool you built and how it fits. |
| Kat texting Clara "clear my afternoon" | Later phase | Not built yet. Today a prospect can reschedule or cancel with Clara, and Kat gets the calendar invite and a confirmation email. Rescheduling from Kat's side comes once we see how often it is needed. |
| Your Monday.com vacancies board | Maybe, after launch | Start with what you publish in AppFolio; it already feeds Zillow and your site. If "coming soon" homes turn out to matter to callers, we look at reading the Monday board then. |
| Affordable housing income certification and annual recertification | Exploratory, not on the roadmap | Genuinely interesting and we want to explore it with you. Not part of this rollout. What we need now is only the list of which properties are affordable, so the screening questions are right. |
| Emergencies and "call the police" situations | Deferred | Leasing-only scope keeps this off the table for now. The 2 AM fire and the neighbor situations get designed deliberately before maintenance or resident calls are turned on, not improvised on launch day. |
| Replacing RingCentral | No | Clara sits on top of whatever phone system you use. Forwarding is enough, and you keep full control. |
| Clara reading Zillow Rental Manager or lead emails directly | No | One source of truth: the guest card. Fix the syndication feed instead (above). |
| Something more urgent than a calendar notice when a tour is booked | Already covered | The moment Clara books, Kat receives two things: a booking confirmation email, and the calendar invite on her Outlook calendar with the prospect's whole story in it. Nothing new to build. |
| A test script for your team | Not needed | The review page and "reply to Clara's email when she is wrong" find the gaps faster than a script would. We run hundreds of scenarios on our side daily. |
| Lease language about sharing data with an AI | Your call | Jay has it on his list to check the current lease wording. Nothing to build; our privacy policy and terms cover the PropFlow side. |
The numbers below come from your own AppFolio data as of September 7, 2026, covering the last twelve months. Where a number comes from a sample rather than everything, we say so. None of this is a criticism of your team — it is a small team running a lot of doors, and every item here is something Clara is built to carry.
241 rental homes are listed across your properties, mostly 3-bedroom (100) and 2-bedroom (92), with 30 four-bedrooms and a handful of 1-bedrooms and studios. Median advertised rent is $1,950. A prospect calling your one main number could be asking about any one of them, in four different towns. That is the hardest kind of leasing question to answer quickly, and it is exactly what Clara is for.
1,073 leads in twelve months — about 82 a month, with real peaks: 162 in September 2025 and 146 in August 2026, against 45 in February. Peaks are when a lead is most likely to go unanswered, because they land on the same team. Clara does not have a busy season.
| Where the lead came from | Inquiries | Share | Showings | Applications | Moved in |
|---|---|---|---|---|---|
| Zillow (both feeds) | 621 | 46% | 184 | 60 | 27 |
| Referral | 79 | 6% | 9 | 39 | 32 |
| Your own website | 103 | 8% | 26 | 17 | 13 |
| Everything else | 546 | 40% | 70 | 31 | 17 |
| Total | 1,349 | 100% | 289 | 147 | 89 |
Referrals are 6% of your leads and 27% of your applications — 32 of your 89 move-ins came from 79 referrals. Zillow is the opposite: eight times the volume, a fraction of the yield. Both are opportunities. Referrals deserve a same-minute answer because they almost always convert. Zillow deserves one because the volume is where the leaks are — and, as we heard on the call, a share of those leads never reaches AppFolio at all.
Across a sample of 500 guest cards, the median wait for a first reply from a person was 174 minutes — just under three hours. 116 of 403 leads got an answer inside 15 minutes; 84 waited more than a day. And Zillow leads are the ones most likely to get nothing at all: 37% of Zillow leads in the sample never received a human reply, versus 19% across all sources. Shared application links are worse again at 56%.
Nobody chose that. Zillow's leads arrive in a separate stream that is easy to lose behind the phone and the inbox. Once they land as guest cards, Clara answers every one inside a minute, at 9pm and on Sunday.
413 showings in twelve months. The median gap between confirming a showing and the showing happening is 2.1 hours, and every single one of the 299 we could measure was confirmed less than a day ahead. Tuesday is the busiest day; 2pm and 3pm are the busiest hours; Kat is assigned to 329 of the 413.
Same-day showing is your competitive advantage in this market. It is also a single person's calendar, and today Beverly checks it by hand and estimates drive time in Google Maps. Clara books straight onto that calendar, inside the notice and travel rules you set, so the advantage survives Kat being in Fruita, at lunch, or off.
In your leasing report, 1,339 of 1,354 leads have no assigned person. In practice your team knows who is on it — but the system doesn't, so nothing can tell you what fell through, and nothing can chase it. Clara owns every lead from the first message, and hands it to a named person the moment it needs one.
482 applications in twelve months. Median time from application to a decision is 12.1 days. 102 were cancelled — the reasons your team recorded include "Found another place" and "Never called me back after multiple attempts." Those two lines are the whole opportunity: an applicant who hears from you every couple of days does not go quiet, and does not go elsewhere.
Your qualifying standard appears on your listings three different ways: "income of resident group must equal or exceed 2x the monthly rent", "must make 2 times the rent to qualify and have zero evictions and/or money judgements", and "income of residents must equal or exceed 2x the monthly rent; all applicants must have zero evictions or money judgement". They mean nearly the same thing, but not exactly.
Deposits are similar: 67 homes carry a default deposit and 174 do not. Where a deposit is set, 46 are exactly one month's rent and the rest range from a fifth of a month to slightly over. Application fees and pet terms appear on some listings and not others; late-fee wording differs between property records. Ten lease templates and 28 letter templates are in use.
This is normal for a portfolio grown one owner at a time, and it is exactly what the review page is for: agree the standard answer for income, deposits, pets, application fees and screening, note the buildings that are genuine exceptions, and Clara says the same thing every time. Jay said it on the call: one process and one template across the portfolio makes everything downstream simpler, renewals included.
Phone, text and email. English or Spanish. She answers about the specific home from the knowledge base, offers a nearby alternative when the one they asked about is gone, and never quotes a home you have not published.
Timing first, then budget, then what they are looking for. Straight onto Kat's Outlook calendar, inside your notice and hours rules, with the prospect's whole story in the invite.
Every caller and every lead ends up as an AppFolio guest card with everything they said, so your team works one dataset.
Prospects who stop replying, on a schedule, until they answer or you tell her to stop.
A caller who wants a person gets a message taken and emailed to leasing@. A question outside the knowledge base gets emailed to leasing@, and your reply becomes the answer. A maintenance caller goes to MCC, as today.
| Question | Why it matters | When |
|---|---|---|
| Who sets the RingCentral forward on September 17, with Jay travelling? | It is the go-live switch. | Before Jay leaves Sunday |
| Who is your Microsoft 365 admin for the company approval? | Without it Clara cannot send from leasing@. Kat's own calendar connection is a separate, personal step. | Thu Sep 10 |
| Kat's tour rules: bookable hours and how much room between towns (one hour minimum notice is already set) | This is what stopped the prototype from booking next-door units an hour apart. | With the review answers, Fri Sep 12 |
| One deposit rule, or a rule per home? And the exact income and screening wording? | 174 of 241 homes have no default deposit; three screening versions are live. | With the review answers, Fri Sep 12 |
| Which properties are affordable or Section 8? | Different screening questions (waitlist versus standard application). | Fri Sep 12 |
Corrected 2026-09-15: the first version graded the classifier against the wrong rule ("reply to every real prospect email, including short Zillow thread replies") and reported 45 "missed" leads. Not how Western Slope works: leads come in only as AppFolio guest cards from our own sync, and only cards created after switch-on get a reply; humans keep every in-progress conversation, Zillow threads included. Clara reads/writes the leasing mailbox only to continue a thread she already started, never to find leads. See the tracker row and the lead-flow design.
Under the real rule, "should reply" on inbox mail is essentially zero — no Clara-started thread existed in this 4-month window. What's left worth measuring: would the classifier ever wrongly trigger a reply on mail it shouldn't touch, and does the non-lead / adversarial coverage still hold.
| Source | Count | Why |
|---|---|---|
| Keyword fallback (AI call failed) | 1 | Flagged a marketing digest as a tour request on the word "tour." |
| Mixed tenant/staff thread | 1 | Utility-bill dispute answered as a lease question. |
| AppFolio "Website Inquiry" form | 1 | Read as a genuine tour request. |
| Zillow first-contact | 103 | Real intake for these is the guest card, not the email. |
| Zillow thread-reply ("Yes," "Perfect!") | 49 | Stays with a person under the real rule regardless. |
~150 Zillow messages plus 3 non-Zillow false positives — none should ever reach the reply path. Only real risk: the keyword fallback, which must never emit a reply on its own.
| Kind | In sample | Correctly left alone |
|---|---|---|
| Zillow noise | 290 | 97% |
| AppFolio system notices | 86 | 98% |
| A person (bills, tenant mail, spam) | 28 | 100% |
| Vendor | 9 | 100% |
| Internal staff forward | 4 | 100% |
Of the 3 failures, two are correct under the real rule: A15 ("Yes" confirming a tour time) and A16 ("Perfect!" after a proposed time) are mid-thread Zillow replies — a person's job, not Clara's. One real failure remains: A08, an Apartments.com lead with an empty message, flagged needs_review instead of a thin lead — a real gap, but not one that touches the leasing inbox.
Keyword fallback must never emit a reply on its own — small, the only real risk found here. The reader stack (PR 8649 family — every-minute check, drain, cursor cleanup) is scoped to threads Clara started; it never reads the inbox for leads, so the labels above aren't on the go-live path. The scrubbed corpus (~/appfolio-dumps/westernslopepm/leasing-inbox-scrubbed/) is the fixture for testing that the reader's thread filter holds.
Corpus: 5,517 inbound / 201 sent, leasing@ mailbox, May 15–Sep 15 2026, anonymized, kept locally. 600-message sample, production model call, offline, no DB writes.
We took the 24 policy answers you already approved (17 company-wide, 7 for specific buildings) and loaded them onto our internal test property, side by side with the 5 answers it already had. Then we replayed 100 of the real questions your prospects have actually asked (weighted toward the ones asked most often — that's 261 "asks" once you count repeats), once before loading your answers and once after, and graded every reply as a real answer, an honest "let me check," or a wrong answer.
| Result | Before | After |
|---|---|---|
| Answered correctly | 92 (35%) | 184 (70%) |
| Honest "I'll check" | 23 (9%) | 17 (7%) |
| Wrong answer | 146 (56%) | 60 (23%) |
Loaded correctly, answering how to apply is now solid (117 of 118 asks answered right). Two gaps remain, both worth fixing before this goes live: how we handle tour-scheduling edge cases (32 of 71 asks still get a wrong detail, usually the wrong closing time or an invented showing slot), and a batch of miscellaneous questions ("other," 19 of 56 wrong) where the assistant sometimes answers about the wrong building entirely.
Every other topic we tested (how to apply, availability, appliances, bedroom count, pets) had zero "let me check" responses left after loading your answers — the leasing team will still see fewer than 20 topics worth of gaps once this runs on your full question set, not the 100-question sample.
Most "wrong" grades are like the first four above: the assistant blending in facts from the internal test property it was tried on, not facts from your business. That risk goes away once this is loaded onto your real account instead of our test bench. The genuine, still-open gaps are the tour-scheduling office-hours math and a handful of miscellaneous questions — those need a fix regardless of which account this runs on.
Method: 100 of 227 real prospect questions (weighted to the most frequently asked, same 100 questions both times), each answered through the same no-send preview tool used for prior dry runs, graded automatically then spot-checked by hand on 20. Full data, exact rows written, and how to undo this test load: internal engineering log, available on request.
Unchanged from the proposal already with you. This page is the schedule, not a new commercial offer. Jay said on the call the deposit invoice is being paid; the contract goes through DocuSign from Sean.
Every number on this page comes from your AppFolio data as of September 7, 2026, read with the account you gave us. Everything else comes from the September 9 kickoff call. Reply times and reply-by-source come from a sample of 500 guest cards out of the 1,171 in the last twelve months.