Proposed — pending review 2026-08-11 · Camellia Apartments · written by Claude for Fede
One prospect became two people because of a dot in a Gmail address
On August 11 a Zillow lead (Jordan Miller) and a direct email from the same person created two separate prospect records. Jordan typed millerjordan.1989@gmail.com into Zillow's form; their mailbox actually sends as millerjordan1989@gmail.com. Gmail treats those as the same inbox — our matching compares exact text, so it saw two different people.
What it caused
- The second record had no name or phone, so the escalation email to the property manager showed "Unknown" as the sender.
- Two automated follow-up sequences were running at once for the same human (double-texting risk).
- Jordan's co-signer question fell through — the answer (yes, we accept them) wasn't in the property's knowledge base.
Already fixed today ✓
- The two records were merged (reversible, audited); one clean record remains with the tour intact. The duplicate's follow-up sequence was killed.
- The knowledge base now says Camellia accepts co-signers and guarantors — Clara answers this herself going forward.
- A manual reply went to Jordan from Camellia's real mailbox, threaded into the same conversation, confirming co-signers are accepted.
Root cause — who, when, why
This was a latent gap, not a recent break. Three changes each made the same omission independently:
| When | What | Why the gap survived |
|---|---|---|
| Mar 23 | Duplicate-prevention guard on prospect creation (Fede) | Aimed at two simultaneous identical emails, not two spellings of one mailbox. |
| Apr 13 | Duplicate-prospect fix after the Nikolas Espinal incident (PR #68) | Solved this exact bug class — for phone numbers only (26 tests). Email got a one-line lowercase. |
| May 5 | Identity system's email rule: trim + lowercase (Gera, PR #639) | Apple's relay addresses got special handling, so provider quirks were considered — Gmail dots never made the list. |
A recent improvement (Aug 9 lead-intake work) made relayed Zillow leads parse better, which is likely why this pairing finally surfaced — it did not create the bug. Why tests missed it: no test anywhere feeds two spellings of one address and asserts one prospect comes back; every email test round-trips a single string.
Prod-wide scan results
- Dot-variant duplicates: Jordan is the only real-customer case (all 1,018 email identities checked).
- Separate, bigger finding: 20 email addresses in the live org are claimed by two different people each — same exact string, mostly minted by a July 21 AppFolio backfill run that created new people instead of matching existing ones. A few pairs cross-link two different humans, which could route a reply to the wrong person.
- The "Unknown" sender on PM escalations is its own small bug: a blank name gets stamped as the literal word "Unknown", which then defeats the template's phone-number fallback. An existing placeholder-name helper just isn't called on that path.
Decision needed: what to fix, in what order
Recommended · Option A — all three fixes, as three small PRs
1) Canonicalize Gmail addresses (ignore dots and +tags for gmail.com) in the one shared normalizer plus the two spots that bypass it, with the missing two-spellings tests. 2) Clean up the 20 backfill duplicates with a guarded merge script (dry-run first, per-pair review for the cross-linked ones). 3) One-line fix so PM escalations fall back to the phone number instead of "Unknown". Each ships dark and independently.
Option B — Gmail fix + "Unknown" fix now; park the 20 duplicates
Fastest path on the incident's direct causes. The backfill duplicates keep their (small) wrong-routing risk until scheduled.
Option C — backfill-duplicate cleanup first
Highest-volume data problem first (20 people vs 1). The Gmail gap stays open, but it has hit exactly once in all of prod history.
Note for the Gmail fix: changing the normalizer changes how stored identities are looked up, so it needs a small backfill/migration for already-stored addresses — the plan accounts for it.