Churn Postmortem

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 threshold.

Before Starting

1. Read .agents/cs-context.md (fallback .claude/cs-context.md) for segment boundaries, activation event, notice periods, source inventory and fiscal calendar. If absent, run cs-context; never ask what that file answers. Read ../cs-context/references/business-model-profiles.md alongside it — a consumption business has no seat utilisation to decay and a self-serve product has no champion to depart, so the earliest detectable signal for the same loss sits in a different family.
2. Export before you analyse. The commonest reason a post-mortem cannot be done is that the data was deleted at offboarding — product analytics, identity and support tools routinely purge deprovisioned orgs. Inside a deletion window, pull 18 months of history first.
3. Ask tappably, in one batch. Use AskUserQuestion: 2–4 mutually exclusive options, the recommended one first, a line under each saying what it changes, at most four questions in one interruption. Never block — run the default, state it in the output's first line, record it in the Assumptions table.

4. Ask for the as-of date of every export; never assume a file is complete or current. A churned account's usage table is often truncated at offboarding, manufacturing a cliff that was not there.
5. Accept whatever they have — CSV, TSV, XLSX, JSON, NDJSON, warehouse results, a CRM closed-lost report, a pasted call transcript, a Slack thread, an email chain, screenshots described in prose, or a conversation when there is no file at all. Run ../cs-context/scripts/ingest.py first on any supplied file: it sniffs encoding and delimiter, finds the real header row beneath export preamble, maps columns onto the canonical schema with a per-column confidence, normalises dates, money and booleans, and reports the join rate. Confirm any mapping below 0.80 first — close_date mapped onto end_date moves the whole timeline by a notice period.
6. Degrade, never refuse. Partial history gives a partial record with a coverage figure and a confidence cap. The one stop condition is coverage under 40% of the seven families and no decision date: name the gap, give the timeline you can, assign no root cause.

How This Skill Works

Output mode — Brief by default

Brief is the answer written first — root cause, detection lag, savability, the one fix with an owner and a date — not a summary written after Full. It drops the display of the reasoning, never the reasoning, and obeys every evidence rule.

The rules this skill enforces

Named rules from ../cs-context/references/operating-rules.md, enforced in the output rather than mentioned. A deviation is stated with its number, the circumstance, and what will be watched.

Four modes, one record. Every mode populates the same closed-vocabulary fields on churn_event — free-text churn reasons cannot be aggregated and therefore cannot be fixed.

Two rules govern every mode: the record is facilitated by someone other than the account owner (a losing CSM writing their own post-mortem produces a defence, not an analysis), and attribution names a function and a mechanism, never a person. Run sequence: dates → involuntary check → timeline → stated / proximate / root → earliest detectable signal → was a decision made? → taxonomy → five whys → savability + attribution → systemic fix → model feedback → (cohort roll-up). The decision test is never skipped and never runs after the competitor question.

Step 1 — Fix the dates, and label on the decision date

Five dates, sometimes six months apart. Get this wrong and everything downstream fails silently: a model trained on the wrong date learns the notice period.

Inferring the decision date (state the rule, label it Inferred): the earliest of — auto-renew switched off by the customer [C1], a termination-terms or data-portability request [R12], a competitor named by an economic buyer [R13], procurement re-engaged outside the renewal window [R11], a bulk admin export [T6], or the meeting where they said it. Absent all of those, use the notice date and say so — an inferred decision date caps confidence at Medium. Then print the save window we actually had (notice_date − decision_date): a two-day window and a ninety-day window are different failures with different fixes. Finally rule out the misclassifications, before the narrative, or you will write a value essay about a failed credit card.

Step 2 — Reconstruct the timeline from every family

One dated event stream, T−540 → T−0, T being the decision date. Walk all seven families; print families with no retained history as "checked, no history retained" rather than dropping them.

Two disciplines separate a timeline from a chronology: tag every event Observed or Inferred with its rule, and known-at-the-time or known-only-now. Only known-at-the-time events are eligible for Step 4 — otherwise you grade the team on information they did not have, which is how post-mortems become theatre. Extraction per source: references/timeline-reconstruction.md.

Step 3 — Separate stated reason, proximate cause and root cause

Three rows. They are rarely the same, and collapsing them is the defining rookie error.

Only the third changes next quarter. Exit answers mislead in a known direction — correct the bias rather than discounting the answer, which is still the only direct evidence of what they experienced. Counter-questions for each: references/root-cause-taxonomy.md.

Triangulate three sources, per Murphy's method [P]: the external reason (what they said), the internal reason (what the data shows), and the context clues (what they did). All three agreeing earns High confidence; where they diverge, the divergence is the finding — record both.

Step 4 — Earliest detectable signal, and the detection lag

The core forensic exercise. Work backwards from T−0 to the earliest date on which a reasonable observer, using only data that existed then, could have called the account materially at risk.

detection_lag_days   = decision_date − earliest_detectable_date      ← what we could have had
recognition_lag_days = first_flagged_date − earliest_detectable_date ← lost to detection
realised_lead_time   = decision_date − first_flagged_date            ← what we actually had
action_lag_days      = first_intervention_date − first_flagged_date  ← lost to routing and capacity
                       detection_lag = recognition_lag + realised_lead_time   (identity — check it)

Record earliest_detectable_signal (an ID from ../cs-context/references/signal-library.md), earliest_detectable_date, the system that already held the data, and whether an alert existed. Then classify the failure mode — each has a different owner and fix:

Then run the model's report card: was this account Green at T−90? If yes, the record is a false negative of the health score and goes to health-score-designer as a scoring defect, whatever the reason code says. Method, aggregates and backtest: references/detection-lag.md; beyond about six records, scripts/detection_lag.py.

Step 5 — Was a decision made at all? Then classify

Most renewals are lost to inertia, a reorg, a spend freeze or a champion who left with nobody inheriting the file — not to a rival. A record that names a rival it cannot evidence routes the fix to competitive enablement, the one place it cannot work. The decision test therefore runs before the competitor question, on every record.

5a · Score both axes. Neither substitutes for the other, and both are printed.

decision_owner_vacancy_days = decision_date − the last dated interaction with anyone holding renewal decision authority. Computed on every record, never left to memory. UNKNOWN is itself the finding: it means we never knew who decided.

5b · Three refusals, applied before a code is written.

5c · The closed taxonomy. One primary_reason, zero or more secondary_reason, three orthogonal axes. Definitions, the reordered decision tree, mis-coding tells: references/root-cause-taxonomy.md.

Two governance rules: other above 15% of records means the taxonomy needs a new category, not that reality is messy; and a reason is coded only from timeline evidence — where the timeline disagrees with the stated reason, code the timeline and record the disagreement.

Step 6 — Five whys, on the vendor-side chain

Asking "why did the customer leave?" five times produces five restatements of the churn reason. Ask "why did we not prevent it?" Every answer must be a fact from the timeline, not a theory.

1. Stop when you reach a cause you own and can change. That is the root.
2. Stop before "we should hire more CSMs." That is a budget argument, not a root cause.
3. When an answer names a person's mistake, redirect one level — ask what system permitted that decision. Blameless is not politeness: a chain terminating on a human terminates on something you cannot fix (Google's SRE postmortem practice is the reference discipline [P]). Worked chain and a bank of terminations: references/systemic-fixes.md.

Step 7 — "Was it savable?" and cross-functional attribution

Four verdicts with required sub-codes, assigned by the facilitator, not the account owner.

The honesty check. A book where more than 60% of losses are coded A or B is either badly qualified or dishonestly coded [P]. Report A+B and C+D separately: A+B is a strategy and qualification number, C+D a CS execution number, and mixing them lets each hide behind the other. Then attribute across functions with weights summing to 100 — function and mechanism, never a person — with a "seen before?" count of prior post-mortems carrying the same attribution: a cause on its third appearance is not a cause, it is an unshipped fix.

Step 8 — One systemic fix, and the model feedback

Exactly one primary fix per loss — a list of eight fixes is a list of none.

Never re-weight on N=1 (R22). A single loss may add a signal to a watch list; a weight, threshold or lead-time change needs ≥3 records with the same failure mode. Emit the change set with current value, proposed value, evidence count, backtest, owner and due date.

Step 9 — Cohort mode: find the pattern, not N stories

Each record compresses to one row and the artifact becomes the ten-table pattern report in assets/cohort-rollup.md, whose first table is the decision-process/competitive split. Weight the reason mix by ARR, not by count: count-weighting hides that large losses have different causes from small ones. The no-decision family and competitive-displacement are reported as two separate ARR shares before any reason table — a quarter whose competitive share exceeds its no-decision share is a coding tell, not a market finding, and scripts/detection_lag.py computes and flags the split. Backdrop for whether the quarter's rate is a process or a market problem — median GRR was 84% on full-year 2025 actuals, down from 88%, top quartile 91%, bottom quartile 76% (Aleph × Benchmarkit 2026 SaaS & AI Performance Benchmarks, 342 companies, 226 reporting GRR) [M]. The repeat-cause register is read first.

Output Template

Brief — the default

**<Account> · decided <date> · $<X>k ARR lost · `<primary_reason>`**

**Root cause:** <one clause, vendor-side, something we own.>
**Decision-process <n>/5 · competitive <n>/5.** <The higher axis, the markers behind it, and the
decision owner's vacancy in days — or that we never knew who held the decision.>
**Detection lag: <N> days.** <Signal> was visible in <system> on <date>; first flagged <date>.
Failure mode: <mode>.
**Savable:** <A/B/C/D> — <one sentence, including what a save would have cost.>
**Fix:** <owner> — <action> — by <date>. Validation: <backtest>.
<Only if true:> **Green at T−90 — this is a scoring defect, routed to `health-score-designer`.**

Confidence: <level> (<n>/7 families, history retained to <date>).
*Full record, timeline, attribution and coverage ledger on request.*

Round composite figures to two significant figures — $310k, not $312,400 (R22). The two scores appear in Brief as well as Full: dropping them is how a lapse gets written up as a price loss.

Full — on request

Emit assets/loss-review-record.md verbatim — Bottom Line, timeline, cause split, detection, classification, five whys, savability and attribution, the one fix, model feedback, win-back, Assumptions and the seven-family Coverage Ledger. Cohort runs emit assets/cohort-rollup.md instead, keeping the Assumptions table and the Coverage Ledger. Every field is populated or written UNKNOWN — requires <source>; no row is dropped for having no data.

These fields have no valid empty value and no valid default. A record missing one is not returned:

The Bottom Line block is emitted before any timeline, and carries these rows verbatim:

An exit interview is emitted below the divider, formatted for an email client, with no unfilled placeholders — rules in ../cs-context/references/customer-voice.md. The firewall (R18) is absolute: health score, risk band, ARR at risk, exposure, forecast category, save play, war room, coverage tier, the two scores above, champion-departure inferences, competitor intelligence and any assessment of a named person never appear, in any wording.

════════════════════════════════════════════════════════════
CUSTOMER-FACING — copy the block below and send as written.
Everything above this line is internal. Do not forward it.
════════════════════════════════════════════════════════════

```text
Subject: 20 minutes on what we got wrong at Northwind

Hi Dana,

Northwind came off the platform on 31 August, and I'd like to understand
that decision properly rather than guess at it. I run customer success
operations here, so this isn't a save attempt — the contract is closed.

The thing I want to get right: the intercompany reconciliation work you
raised in March never got finished. I want to know whether that decided it
or whether it was already decided by then.

Twenty minutes, no recording unless you'd prefer one. Thursday 11 September
or Friday 12th — and if you'd rather not, that's completely fine, with no
follow-up either way.

Thank you for three years, and for pushing us on the audit log — that
shipped because of you.

Priya
```
Variants by recipient, the question set and the debrief: `assets/exit-interview-guide.md`.

Quality Bar

• All five dates recorded; labelled on the decision date, with the inference rule stated where inferred; opt-out deadline printed and the save window computed
• Involuntary churn, quasi-churn and re-papering ruled out before any narrative was written; timeline covers T−540 → T−0 across all seven families, unretained families printed as such, every event tagged Observed/Inferred and known-at-the-time/known-only-now
• Stated reason, proximate cause and root cause are three separate rows; the stated reason is verbatim, attributed to a named role, with the date and how it was asked
• earliest_detectable_signal, earliest_detectable_date, the holding system and alert status all recorded; detection, recognition, realised-lead and action lags computed, and the identity holds
• Failure mode assigned from the six-value list and the fix matches the mode; "Green at T−90?" answered, and a Yes routed as a scoring defect whatever the reason code
• C16 — decision-process and competitive scores both printed, 0–5, each with its dated markers, in Brief as well as Full; decision_owner_vacancy_days computed; the decision test ran before any competitor was named
• C16 — where the timeline holds no decision event the record is coded no-decision, deprioritised, budget-freeze, orphaned-renewal or budget-loss, never other and never failure mode undetectable; competitive-displacement carries a replacement confirmed by two independent sources and a competitive score ≥3, or it is stored as competitor_claimed
• No competitive fix (battlecard, enablement, price response) proposed where decision-process ≥3 and competitive ≤1; the fix names a decision owner, a calendar gate or an approval path instead
• Taxonomy populated from the closed vocabulary; origin stage coded separately from where it surfaced; five whys terminate on a cause we own, with the stop rule named
• Savability assigned by someone other than the account owner; A+B and C+D shares reported separately, and attribution weights sum to 100 naming functions and mechanisms, never individuals
• Exactly one primary fix, with owner, date ≤90 days, a backtest and a "not doing" line; no weight or threshold change on fewer than 3 corroborating records
• Brief emitted by default; Full only on request; composite dollar figures rounded to two significant figures
• Every number carries a provenance tag with a date or window, and every inference states its rule
• Assumptions table present with a concrete consequence per row; Coverage Ledger carries history-retention depth per family and confidence ≤ the cap
• Customer-facing text, where present, sits in a fenced block below the divider, with no placeholders and no internal language

Anti-Patterns

Related Skills

Going Deeper

…(truncated)