What Clara should do when a prospect wants an apartment that is not available yet: get them in to see something and talk to a person, remember the exact one they want, and come back to them when it is close.
3 September 2026 · research + design · updated 4 September (phone lane, Yale go-live readiness) · Shipped on text, email and the Willows phone line / Steps 3–4 + the prompt-sync fix pending manual merge · companion to One asking price
What changed, in plain terms.
Still to ship: the wait list, and the "it's almost ready" follow-up message. Both are built, tested, and approved. They're on hold only because each one adds a line to the file that controls which tools an AI agent is allowed to use — any change to that file gets an automatic hold for a person to merge by hand, on purpose. The follow-up message itself ships turned off everywhere; switching it on for real prospects at any property is a separate decision Fede makes later, not part of this merge.
| Piece | Status | Evidence |
|---|---|---|
| 1 · Date reaches Clara, no early tours | Live | #6912 |
| 2 · Same-size stand-in tour + wanted-unit note | Live | #6930 |
| Fix · date/stand-ins reach Clara before she replies, not only via the booking tool | Live | #6973, merge d2b444acc4 |
| Fix · "is the listing trustworthy" check matches the property's real update pattern | Live | #6999 merge b990f380, cleanup #7009 merge 29abfec3 |
| 3 · Wait list | Built, held | #6931 |
| 4 · "It's almost ready" follow-up message | Built, held, off by default | #6933 |
Proof at Yale, a real live test. An automated script emailed Clara's real Yale mailbox as a prospect, once per apartment — six apartments with a future ready date, plus two that are ready now as controls — and graded the actual replies against what should have happened. Before the fixes above, she got the date right 5 of 6 times, correctly refused an early tour 5 of 6 times, and offered a stand-in apartment only once. After both fixes: date right 5 for 5, no early tours 5 for 5, stand-in offered 5 for 5, and both ready-now controls handled correctly. Full replies are saved on the working branch (files named for the test run, before and after).
One apartment (326) never got a reply at all — the transcript shows Clara worked out the right answer inside a tool call, then the conversation ended before she sent it. This is a separate, known bug in how her turns end, not a future-availability defect: the same no-reply shape hit two different apartments in an earlier test. Tracked as its own Trello card (see below), not fixed as part of this work.
Proof at Willows, real scheduling data. The "come back when it's close" timing was run against Willows' real scheduling database (not a mock): nothing sent 15 days out, one message sent at 14 days out, nothing sent the same day the apartment turns ready, one nudge sent 3 days after that if the prospect stayed quiet, then silence — exactly the sequence designed above.
Test coverage going forward. 40 saved real-world scenarios that must keep producing the same answer, checked automatically on every change, with a guard that fails loudly if a scenario is edited without re-approving it and a control that mutation-tests the checks themselves.
What was broken, and it was not a small gap. The phone prompt had never been told any of this. Clara was never asked to name which apartment a caller wanted, so the check that refuses a too-early tour could not run at all — it was switched on in the code and unreachable on every call ever placed. She also had no way to say which apartment she could show instead: the list she reads at the start of a call gives bedroom counts and prices, never apartment numbers.
| On a call, can Clara… | Before | Now |
|---|---|---|
| See each apartment's ready date | Yes | Yes |
| Refuse a tour before that date, and say the date | Never ran | Yes |
| Offer a same-size apartment by number | No | Yes |
| Follow the not-ready-yet rule at all | No | Yes |
These were real phone calls into the Willows test line, not simulations. Each one worked, and each one exposed something the tests could not.
| Call | What happened | Result |
|---|---|---|
conv_5501m1ndzq…first call | Said the date twice, refused the early tour, booked nothing — then offered "other one-bedrooms" with no apartment number, and when pushed said the booking system would reveal which one. | Half right |
conv_5401m1nkza…after the fix | Named units 102 and 105 out loud, with no tool call — then called them the "same one-bedroom layout", which we ban because we know bedroom counts and square footage, not floor plans. | One phrase wrong |
conv_5601m1nnvd…final check | Named 102 and 105, said the date, offered nothing before it, booked nothing — and the layout wording is gone. Two rough edges left, neither a false statement: she answered a repeated "which one is that?" with "either one works" instead of picking, and the automated grader wrongly failed her for offering a tour on Monday the 14th — which is after the 13th, and the first weekday the office is open. | Fixed |
She was not disobeying the rules — she had nothing to say. That is the thread running through all three calls. The stand-in numbers existed in only one place, inside a tool she had no reason to use when she was answering rather than booking. So the fix was not another instruction: the apartment numbers now sit on the line she already reads at the start of the call, worked out the same way the booking tool works them out, so the two can never disagree. The same thing happened again with "same layout" — the ban was three screens up in the prompt, while the words she was echoing were right next to the numbers. Both times, the lesson was the same: a rule that is not next to the data loses to the words that are.
Where it stands after three calls. Everything that could mislead a caller is fixed: she states the real date, never offers the apartment before it, names what she can show instead by number, books nothing she shouldn't, and promises no callback. What is left is polish — one clumsy turn when a caller asks the same question twice — plus a grading script that needs teaching that "the Monday after" is not "before".
One more thing worth knowing. The list Clara reads at the start of a call is cached for up to a day. A freshly-changed ready date does not reach a caller until that cache turns over — which nearly made one of these tests pass while measuring nothing. That is now written into the test's own instructions.
Who hears this today. The phone changes are live on the Willows test property only. The shared phone agents that Camellia and Yale callers reach are updated by a separate, manual step — that is Fede's call and has not been run. The text and email side is unchanged by this work.
The one thing blocking go-live: tour confirmations, cancellations, and escalations all go to us, not Yale. When a prospect books or cancels a tour, or needs a human, that message currently lands on a PropFlow address and a PropFlow-owned Outlook calendar — not anyone on the Yale team. The one channel that already reaches the Yale team is the Slack card posted to #apartment-yale. Three fields on the Yale property record need real Yale values before anyone can tell the team Clara is live:
One quality bug found, fix in progress, shipping dark. On a real test call, the caller said his name out loud after Clara greeted him with the wrong one — and the tour still got booked under the wrong name. This is what a reassigned phone number, a shared household line, or someone calling on another person's behalf will look like to a real customer. The fix ships turned off until it's proven, per the standard rollout rule.
What's already cleared, with evidence:
What could not be proven yet:
Clara offers tours of apartments that are still occupied. On 3 September, ten of the eighteen apartments on Yale's website had a future date, some as far out as November. Clara told prospects each one was "available" and asked "want to come see it in person?", including for a unit that frees up on October 8.
Source: the website robot's after-run on 3 September (every reply saved in the robot's results file). Prices and the list of apartments were right in every reply. What Clara did not know was when each apartment is ready, because the date is dropped one step before the list she reads, even though PropFlow has it from the website scrape.
Fede, 3 September: this is not a wording fix. Yale prospects often want one specific floor plan. The goal is still to get them in to see something and speak to a person, note which apartment they actually want, and follow up when it gets close. PropFlow has none of that today.
Researched across Knock, Funnel, Yardi RentCafe, Entrata, AppFolio, RealPage, ResMan and the listing sites (report: research-future-availability-crm-2026-09-03.md), plus the AppFolio, Yardi and RealPage knowledge bases (research-future-availability-pms-2026-09-03.md). The pattern is the same everywhere, and it has settled vocabulary:
| Step | What a good leasing office does | Their word for it |
|---|---|---|
| 1 | Capture who they are, when they want to move, budget, and which floor plan or unit they want, on one prospect record. | Guest card; unit interest; floor plan preference |
| 2 | If that apartment is occupied, show something today: a model, or a vacant apartment with the same layout, so they see the building and get the feel. Note which one they toured. | Model unit; comparable unit |
| 3 | Put them on a list for that apartment or floor plan, with their move-in window. | Waitlist |
| 4 | Stay lightly in touch while they wait. No pressure. | Nurture |
| 5 | When the apartment is a few weeks from ready, or the resident gives notice, reach out: it's coming up, want to tour or apply? | Availability alert |
| 6 | The moment they say yes, a person takes it from there. | Hand-off |
| 7 | They can sign for the apartment before it is empty. | Pre-lease |
What the property systems give us, and what they don't. AppFolio keeps an Available On date and a separate Ready for Showing On date on each unit, and its guest card records interest in specific units. But moving a waitlisted prospect forward when a unit opens is a manual step a person does; AppFolio does not send the alert. Yardi's RentCafe has automatic availability alerts, but PropFlow's Yardi scope skips that module. RealPage has no waitlist for ordinary apartments. Conclusion: the "come back to them when it's close" part has to live in PropFlow, using the dates and statuses each system lets us read.
From the code map (research-future-availability-propflow-2026-09-03.md):
Say when it's ready. Show something now. Remember the one they want. Come back when it's close. Hand off the moment they say yes.
Renewals and current residents are untouched. This is prospect-side only.
When the apartment they want is occupied, what does Clara invite them to see instead?
Matches what Fede described and what the industry does. Uses data Clara already has (bedrooms, square feet). Gets the prospect into the building and in front of a person. The note on the tour carries the specific unit they want.
Closer match for the prospect, but PropFlow does not know floor plans yet, only bedrooms and square feet. Would need a floor-plan field per unit before it works.
Simplest, but loses the visit and the human conversation, which is the point.
What makes the "it's coming up" message go out?
Covers both cases: a known date from the website or AppFolio, and a surprise (notice given early, or the date slips). Two weeks is the industry's usual window and matches how far ahead renters plan.
Simpler, but misses the unit that opens early and fires on a date that has slipped.
Never fires early enough for a prospect who needs to plan a move.
Do we keep the wait list in PropFlow, in AppFolio's guest card, or both?
PropFlow is the system of work; the PMS stays the system of record for leases, not for who is waiting. Works the same at Yale (no PMS feed), Camellia (AppFolio) and Situs. Nothing to reconcile.
Nice for teams who live in AppFolio, but only AppFolio has the field, the partner API's write scope for it is unverified, and it creates two copies to keep in step.
Some properties show an occupied unit with a day's notice to the resident. Should Clara ever offer that?
One rule, no per-property setting, no notice-to-enter handling. Right-sized for two properties. Revisit when a client asks.
Needs the resident-notice workflow and a property switch. Not worth it until someone wants it.
Each step is its own pull request with its own proof. Step 1 is the part that blocks real prospects at Yale; steps 2 to 4 are the capability Fede asked for.