Key Pickup: from a misrouted call to a booked appointment
2026-08-12 · Camellia Apartments · incident from Aug 11, fixes shipped and verified live the same week
Fixes shipped & live
Decisions 1 & 2 — Decided (Fede, 2026-08-13) and shipped · Decision 3 still open
A new resident called the day before his move-in to ask how to get his keys. Clara answered every question he asked, correctly — and then let him hang up with nothing on the calendar and nobody at the property expecting him. The ability to book that appointment already existed. The call simply never reached the part of Clara that has it. This page explains what happened, why, what we changed, and the three choices we'd like Fede to make.
1 · What happened
Aug 11 — Jacob Warren's call
Jacob Warren is an approved applicant moving in on Aug 12. He called to ask how to pick up his keys. Clara handled the conversation politely and accurately: she confirmed his move-in date, told him where the leasing office is, and told him who to ask for.
What she never did:
- Offer to book a time. He hung up without an appointment.
- Tell anyone at the property. No note, no calendar entry, nobody on site expecting him.
- Flag it. The call was automatically marked resolved, so it never showed up as needing a human.
The frustrating part: the ability to schedule a key pickup had shipped on Aug 7, four days earlier. It worked. Jacob's call was handed to the wrong specialist — the one that doesn't have it.
In plain terms
Clara has several specialists behind one phone number, like departments in an office. The department that can book key-pickup appointments never got the call. The department that did get it gave good directions and then said goodbye. Jacob showed up the next day on faith.
2 · Why it happened — three layers, each enough on its own
Layer 1 — The phone system thought he was a shopper, not a resident
When a call comes in, Clara looks up the number and asks one question: is this an active tenant? Jacob's lease hadn't started yet, so his record was still marked pending. The answer came back "no", and he was handed to the call as a returning prospect — someone shopping for an apartment.
Layer 2 — The routing rules send prospects who say "move-in" to Leasing
Clara's triage step (the receptionist that decides which specialist takes the call) has a rule: a prospect talking about moving in goes to the Leasing specialist. Leasing is the one specialist with no booking tools at all — it can talk about the property, but it cannot put anything on a calendar.
Layer 3 — Even routed correctly, the booking check would have refused him
The rule that decides "is this person allowed to book a key pickup?" only accepted active tenants. So even if the call had reached the right specialist, a person who hasn't moved in yet — the only kind of person who ever needs a key pickup — would have been turned away.
Also found while digging: two different "move-in" dates
Jacob's lease paperwork is dated Sept 1 — the office writes leases to line up with the start of a month. The move-in date field on his record says Aug 12, which is the real day he gets keys. We confirmed the rule: the move-in date field in the property management system is the authoritative one. The "desired move-in" date a person types on their application is preliminary and can drift; the lease term start date is an accounting boundary, not a day anyone shows up with boxes.
In plain terms
Three separate things all had to be true for this call to fail, and all three were. The system asked the wrong question about who he was, sent him to the one department that can't book anything, and had a rule that would have refused him anyway. Fixing only one of them would not have saved the call.
3 · What shipped today
All three changes are merged and running in production.
Key-pickup appointments are now 15 minutes
They were being blocked out as 30-minute slots. Handing over keys and signing the last page doesn't take half an hour, and the longer block was eating the on-site manager's day. (PR #5713)
A person with a lease on file is now an "incoming resident"
Four related fixes, shipped together: (PR #5714)
- A caller who has a lease on file is recognized as an incoming resident — never as a prospect — even before their lease starts.
- Callers who are moving in now route to Resident Services, never Leasing. The standing rule from Fede: a known tenant or future tenant never goes to Leasing. Their only destinations are maintenance, resident services, or a human.
- A caller who hasn't moved in yet can no longer be pushed into the maintenance-request path — you can't have a broken faucet in a unit you don't live in yet, so that route was only ever a dead end.
- The "may this person book a key pickup?" check now accepts people who are moving in, not just people already living there.
A dry run for putting move-ins on the manager's calendar
Groundwork for the next step: every move-in appearing on the property manager's calendar as an all-day teal event, so the on-site team can see at a glance who is arriving this week. What shipped is the planner plus a read-only rehearsal — it works out exactly which events it would create and prints them, and writes nothing. Writing went live the following night under Decision 2: events are now created and kept up to date automatically, and the back-catalogue was filled in under Decision 1. Verified against the live calendar — all three current Camellia movers have their events, and a re-run has nothing left to do. (PRs #5717, #5725)
4 · Proof — tested against the live system after deploy
Not a lab result. These are simulated callers driven against the phone agents actually answering the Camellia line, after the fixes were deployed.
| What we tested | Result |
|---|
| A person moving in calls the main line — does the receptionist send them to the right department? |
5 out of 5 to Resident Services. Never Leasing. |
| Does Resident Services actually book the appointment, end to end? |
2 out of 2 clean runs. It checks real open slots first, offers only times that came back as available, books one, and confirms only after the booking succeeded — never the other order. |
Two things had to be built into the test rig before those results were even measurable, and both are permanent additions:
- The test can now assert where a call was transferred. Previously it could only check that a transfer happened — which is exactly why this bug survived: the handoff was tested, the destination was not.
- A parser fix so the test can see what the agent passed to its tools. Those details were being dropped, so simulated runs were partly blind.
In plain terms
We had been checking that the receptionist transferred the call. We had never checked which desk she transferred it to. Now every future change gets checked on that, automatically, forever.
5 · Decisions — three choices for Fede
Pick one option per question. Answers save automatically and everyone on the page sees them.
Decision 1 — Move-ins whose date has already passed
DECIDED (Fede, 2026-08-13): Option B — create them all. The calendar doubles as a record: past move-ins get their events written retroactively, and every future move-in gets one automatically. Shipped and verified — the Aug 7, Aug 10 and Aug 12 movers all have their events on the manager's calendar.
Decision 2 — Green-light real calendar writes
DECIDED (Fede, 2026-08-13): Proceed. The writer is live: move-in events appear on the manager's calendar in their own teal colour and refresh automatically whenever the property-system sync runs. Each event carries a stamp so repeat runs update the existing entry — a re-run creates nothing new. Zero production errors in the hour after go-live.
6 · What we learned
- A lease start date is not a move-in date. Camellia writes leases to start on the first of a month; people move in when they move in. Anything that needs to know when someone actually arrives must read the move-in field, not the lease term.
- Signing status was deliberately left out of what Clara knows on the phone. That was a scope decision by Fede for this round, not an oversight — worth writing down so nobody "fixes" it by accident later.
- The untested seam was the transfer destination. We tested that calls got handed off. We never tested where they landed, and that is precisely where this bug lived. It is now covered by standing regression tests, so the seam cannot go quiet again.
The capability existed four days before the call that needed it. Nothing was missing except the path to it — which is the kind of gap that only shows up when you test the whole journey, not the pieces.