Western Slope, Oct 13. How a prospect got a tour on Kat's calendar without anyone asking who they are, and the rule going forward.
Oct 13, 2026 · decided by Fede the same day · facts from the production records
Nobody asked the name, and when the prospect said "see you at 11:30" the system booked instead of asking.
Clara texted them at 10:55 AM asking for their name. They answered within minutes: Alfredo Espinoza, two people coming. The tour and the person record now carry the name, and Kat got one proper note with the full context: who, Ridgway, 565 Redcliff Circle #102, Spanish speaker, asked about an Auberge Madeline employee discount, moving in now.
The fix (ask for the name at booking, then confirm) is in review and ships live everywhere on merge, no switch.
Alfredo's tour is on Kat's calendar, but AppFolio never got a guest card or a showing for him. The blank name was not the reason.
Western Slope, last 14 days: 21 guest cards landed, 11 writes failed. None from login, rate limits or a changed AppFolio form.
| Why the write failed | Count |
| No name on file (today's name fix closes this) | 4 |
| Booked on the main-line placeholder (this case) | 2 |
| Robot could not read the card back / held send | 2 |
| Home not on AppFolio's vacancy list | 1 |
| Note did not read back / cancelled showing | 2 |
Name rule proven live, 1:40 PM: at the Fairhaven test line a prospect with no name picked 3:00 PM. Clara held the time and asked for the full name; the name came, the tour confirmed with it on the calendar and in the team email. On the phone, a test caller who refused a name twice got no booking and Clara said so plainly. The guest-card fix is in review, replay green on Alfredo's own records.
Done, 1:01 PM: Alfredo's tour now points at the real home (Northridge Apartments, 565 Redcliff Cir #102). His guest card is in AppFolio (card 3013: name, phone, unit, Spanish speaker, 2 people, move in as soon as possible, Auberge Madeline discount question). His showing is on the card for Oct 14, 11:30 AM. Kat's calendar event was updated in place, one event, no duplicate. Nobody at Western Slope or the prospect was messaged.
Next: a harness is being built that replays every one of these failures and places real calls and texts into Willows, which must land a card and a showing in AppFolio. Red before the fix, green after. Then the fix (text bookings request a card; a main-line booking resolves to the real home), no switch, proven live here.
The bounced text, fixed 9:50 PM: Alfredo's Saturday answer about application requirements never arrived. It was 701 characters of accented Spanish, which phones send in 67-character pieces, so it became 11 pieces and the carrier refused it (Twilio error 30019). Our sender only split texts past 1,600 letters and nobody was alerted. Fix merged and live the same night, no switch: texts are now counted the way the carrier counts and anything over 5 pieces goes out as separate texts cut at sentence ends, and a size rejection logs as an error. Proof: the exact Saturday text replayed from the Willows line to our test number went out as three texts of 5, 5 and 2 pieces, all delivered (SM1a464805, SM34af15da, SM7f4d650b). Before: 1 text, 11 pieces, undelivered. After: 3 texts, every one delivered.
One decision for Fede: the Western Slope "main line in front of many buildings" shape exists only at Fairhaven, whose buildings were put in sandbox mode on Oct 9 and cannot write to AppFolio. Options: (a) recommended keep the sandbox rule; prove the main-line resolution by replaying Western Slope's own records read-only, prove card and showing landing with real calls and texts at Willows, and watch the first real Western Slope bookings after the fix ships; (b) take Fairhaven's two buildings out of sandbox mode, point them at the Willows AppFolio property and turn on showing sync there, which reverses part of the Oct 9 cleanup and risks duplicate records.
Built a test that replays the failed AppFolio writes and places real bookings into Willows. It runs on this Mac only, never in CI. The fix has not been started.
Offline replay, on today's code: red where it should be.
| Case | Expected today | Got |
| Alfredo-style text booking at a main-line home | Red | Red: no guest card requested, tour stays on the main line, showing stuck on "no PMS configured" |
| Same booking by phone (control) | Green | Green: card and showing on the real building and unit |
| Card with no name, from a call | Red | Red: queued, then fails "no usable name" |
| Note AppFolio did not read back | Red | Red: given up after one try, no retry |
| Showing with no unit | Green | Green: already fixed Oct 7 |
168 failed writes from the last 14 days at Western Slope and the test companies are frozen and sorted by cause, names and phones hashed.
Live phone call into Willows: expected green, came back red. That is a finding.
| What ran | What happened |
| Robot caller asked to tour unit 102 | Clara said 102 is occupied and booked unit 105 for today 2:30 PM |
| Showing in AppFolio | Never landed. Unit 105 has no AppFolio unit id in our records, so the showing retried for 20 minutes with "no AppFolio unit id captured". No showing id. |
| Guest card | None requested. The robot's test number already has Willows card 141 from earlier runs, so no new card was due. The call log for this call was refused: "card has no inquiry group to file the communication under". |
| Cleanup | Tour cancelled through the normal cancel path |
Only 3 Willows units (101, 102, 412) carry an AppFolio unit id, so any tour Clara books on the others cannot reach AppFolio. The harness also needs a fresh caller each run so a new card is due; today's test line is a returning person.
Live text booking: not run. Stopped after the phone call came back red, as agreed.
Re-run, from the harness branch: npx vitest run --config scripts/guest-card-write-harness/vitest.config.ts; phone: l4-e2e-postcall.ts --scenario tour-booking-appfolio-readback --i-know-where-notifications-go; text: scripts/guest-card-write-harness/live/text-leg.ts --live. Call: conv_voice_37efed02, tour 2b85e683.
Update, 2:00 PM: Willows access fixed. Fede restored Clara's access to the Willows AppFolio property around 2 PM. A unit sync right after confirmed AppFolio lists 37 Willows units and all 37 already carry their AppFolio id. The other 93 Willows units in our records (unit 105 among them) do not exist in AppFolio at all, so any tour booked on them can never reach AppFolio. 23 earlier Willows failures where the robot could not write or could not read its write back are now marked "possibly access, re-test" instead of defects.
Second phone call (fresh robot line with no Willows history):
| Expected | Got |
| Tour booked, new card, showing on the card | No tour. Clara picked 10 AM tomorrow, then said "I'm having a little trouble finishing that booking, the team will confirm". No showing. |
| A new caller gets their own card | Filed on someone else's card. The robot gave the same name as the first call, so the new number was folded into that person, and the card request and call log landed on AppFolio card 141, which reads "Jordan Pike", a different phone, no unit. That one is partly our test's doing (reused name), but a new phone being filed on another person's card by name alone is worth a look. |
Text booking (test number, unit 102, tomorrow 2 PM): red, as expected. Clara booked the tour (Oct 14, 2 PM, no unit on the tour) and never asked AppFolio for a guest card. The showing then waited 20 minutes on "has no card to address yet". Same failure as Alfredo, reproduced live. Tour cancelled afterwards.
Separate finding, returning callers: on the first call the call log for a returning caller was refused by AppFolio: "card has no inquiry group to file the communication under". Their existing card has an inquiry with no unit, and the log named unit 102. Looks like a real defect for repeat callers; the second call's log, with no unit, went through.
Ids: first call conv_voice_37efed02 (tour 2b85e683, cancelled); second call conv_voice_7c0422a5 (no tour); text tour 0f1641c5 (cancelled); AppFolio card 141.
Green-after, 3:15 PM, with the guest-card fix live. Same scripted text booking at Willows, fresh test name and number. The fix works: the guest card now lands. The tour and showing are still red, for a Willows setup reason, not the fix.
| Check | Before the fix | After |
| Guest card requested and sent | Never asked | Sent, AppFolio card 215 |
| Card name and phone, read back from AppFolio | No card | Match ("Emery Ketteringridge", the test number) |
| Tour on a unit AppFolio knows | No unit | No unit: Clara still would not book 102 |
| Showing in AppFolio | Stuck on "no card" | Refused: AppFolio's showing picker does not list unit 102 |
Why 102 still is not bookable: we gave it an available date of today in AppFolio, and our records picked it up. But Clara only offers a unit that AppFolio marks as posted to the internet, and 102 is not posted. AppFolio's showing picker appears to apply the same filter. Posting 102 would put a public ad for a test unit on the listing sites, so that is Fede's call, not something the harness should do. The phone retest was skipped because the text run was not fully green.
Run: tour c6c41f80 (cancelled), card 215, inquiry 6ac0e7a2, production commit b1685f591f.