Clara herself texted the prospect asking him to apply. He applied, then replied three minutes later asking what happens next — and Clara handed him to the team instead of answering. Every piece of data needed to answer was on file (application submitted, linked to the PMS, status "Decision Pending"). But the post-application answering feature we shipped this week is email-only by design, Camellia is deliberately not enrolled in the lease-policy knowledge that feeds those answers, and even on email the feature intentionally refuses "what happens next" questions for undecided applications. Three intentional scoping decisions, made separately, stacked up to make the most predictable post-application question unanswerable on the most likely channel.
The thread is now escalated and latched: Clara will not answer further leasing questions on it until the team responds. A hot lead (toured same day, wants to move in Aug 15) hit a wall at the exact moment of highest intent — right after applying — on a question we prompted him to ask.
| Time (UTC) | Event |
|---|---|
| Aug 13, 05:13 | Application submitted online for unit 112. Prospect stage flips to applied; PMS shows rental application #35, status "Decision Pending". Everything needed to answer is on file. |
| 05:16 | Inbound SMS: "I just completed my application… what do I do now?" |
| 05:16:59 | Clara calls forward_to_property_manager. Her own stated reason: "Applicant asking what to do after submitting application — no post-approval grounding on file to answer next steps." The model knew exactly why it couldn't answer and followed its rules correctly. |
| 05:17:00 | Escalation email sent to the property team ("Salvador Guerra — Lease info"). |
| 05:17:03 | The same-turn escalation rule replaces any composed reply with the canned handoff ack. Thread status → escalated (does not auto-reopen). |
Ruled out: quiet hours (no quiet-hours gate exists on the inbound reply path — and the ack itself sent at 11:17 PM), feature flags (none govern this), and model misbehavior (the prompt's Rule 7.6 requires a grounding block to answer next-steps questions; none was present, so routing was the mandated move).
The application-status scope we shipped Aug 10 (application-status-scope.ts) returns nothing unless the channel is email (line 248). This was a deliberate, documented scoping call: email has a safe "exactly one applicant matches this sender" identity check, and the SMS/voice equivalent (a phone-number uniqueness counter) hasn't been built yet. The module header says so in plain terms. An SMS from an applicant routing to a human is the feature working as scoped — the scope just doesn't match reality: a prospect who tours and texts all day will ask this question by SMS, not email.
Clara doesn't improvise answers about leases. For each property she can only quote from an approved fact sheet: deposit amounts, lease lengths, fees, and what happens after you apply. The system for those fact sheets shipped weeks ago — but Camellia's was never created. The code deliberately blocks switching it on for Camellia (migrate-property-lease-policy.ts refuses its property ID) because the team decided that going live at a real property should happen in a sit-down session where a human verifies every fact — and that session was never scheduled. So even if Salvador had emailed instead of texted, Clara would have had no approved facts to answer him with. (A further personalization layer — quoting the applicant's own unit and terms back to them — is also switched off everywhere: a required input is hardwired to empty at the call site in conversation-manager.ts.)
The in-review disclosure we built answers "what's my application status?" ("it's in review"). It deliberately routes "what happens next for me?" to a human, on the theory that next-steps is the leasing team's call for an undecided application. So the precise question every applicant asks in the first five minutes — "I applied, what now?" — was designed out of scope of the very feature named after it.
| Shipped | What it did | Why it missed this case |
|---|---|---|
| Jul 3 (#5475) | Approved applicants get lease answers on voice + SMS | Requires stage approved. Salvador was applied / decision pending. |
| Jul 18–24 (#5545, #5573) | Email lease answers with a closed category list and identity gate | Email-only; and next-steps isn't in the closed category list. |
| Aug 1 (#5577), Aug 5 (#5603) | Lease policy moved into property knowledge; exact deposit tiers | Content infrastructure — Camellia never enrolled in it. |
| Aug 10 (#5638) | Verified applicant's status question answered for safe stages | Email-only (Gate 1); answers "what's my status", routes "what do I do now" (Gate 3). |
| Aug 10 (#5631) | Denied applicants get the published answer, not the sales pitch | Requires stage rejected — different scenario. |
Pattern across all five: each fix tightened one channel × stage × question-type cell of a matrix, and this incident sits in a cell none of them claimed. The gap was knowable — the Aug 10 module's own comments describe both the SMS gap and the routing of next-steps questions.
Decision state: Fede's two rulings above (all channels; answer next-steps with common sense) effectively select Option A. B remains the longer-term content story; C is available as a same-day stopgap while A is built.
When a prospect whose stage is applied with a pending PMS status asks what happens next, Clara answers from a small property-safe script: "Got it — your application for unit 112 is in. The leasing team reviews it, typically within X business days, and you'll hear back by email/phone. Nothing more needed from you unless the team reaches out." This needs: (1) the SMS/voice identity counter (phone-number analogue of the email one), and (2) a new disclosure arm for "received / what's next" — deliberately generic, so it doesn't need Camellia's lease-policy enrollment. It does not promise decisions or timelines we can't back.
Why recommended: covers the highest-frequency question at the highest-intent moment, on every channel, without waiting on the Camellia policy go-live. The identity counter is the only real engineering lift.
Enroll Camellia in the typed lease policy (the supervised session the code is waiting for), which unlocks the full grounding block on email, then add the SMS counter. Richer answers, but two dependencies deep, and next-steps questions would still route until Gate 3 is also changed.
Smallest change: when the forward reason is "post-application next steps", the ack says something useful ("Your application is in — the team reviews it and will reach out, usually within a couple of business days") instead of the bare "someone will get back to you", and the thread doesn't latch shut for unrelated questions. Improves the experience without answering anything new.
Options A and C compose: C is a one-day stopgap, A is the real fix. B is the long-term content story either way.