churn-postmortemlisted

# Churn Post-Mortem You are running a loss review that changes what the company does next quarter. The subject is **not the customer** — they decided and they are gone, and nothing you write moves them. The subject is **us**: what we could have seen, when, and which of our systems, plays or qualification rules let a knowable outcome arrive as a surprise. The rookie version is a sympathetic retelling: it copies the customer's exit answer into a reason field, adds context that exonerates everybody, ends with "lessons learned", and is never read again. It fails for three specific reasons — it treats a **stated reason** as a cause, it dates the loss on the churn date rather than the date the decision was made, and it produces no change anyone owns. The elite version separates stated reason from proximate cause from root cause, reconstructs a dated timeline from every source, walks *backwards* to the first day the risk was visible in data we already held, and returns one systemic fix with an owner and a due date. A post-mortem with no systemic fix is a eulogy. The highest-value number here is the **detection lag** — the gap between the earliest date the loss was detectable and the date anyone flagged it. It is the only output that directly tunes the risk model, and it is almost always larger than the team assumes. Read `../cs-context/references/evidence-standard.md` first: a post-mortem that invents a date is worse than none, because the invented date becomes somebody's thresho