churn-postmortemlisted

# Churn Postmortem The reason a customer gives for leaving is the reason they are willing to say out loud to someone they are leaving. It is polite, it is usually partly true, and it is almost never the mechanism. "Budget cuts" is what you are told. Whether the budget was cut because the value was never proved is the thing you needed to know. The failure this exists to prevent: **"it was an acquisition" filed as a cause, concealing nine months of nobody calling.** A postmortem that produces a category rather than a mechanism produces no change. --- ## What this needs **Shared context.** If an `account-context` document exists, read it first, particularly the value metric and what healthy usage looks like. A postmortem without those reaches for usage numbers and misreads them. Where it is absent, carry on and say so. **Minimum: what the user remembers.** Memory is biased but it is not worthless, and a postmortem written from memory that says so beats one that never happens. **Better with** the account's email and meeting history, the support record, and whatever the renewal conversation produced in writing. **Best with** the original business case and the health-score history, which together show whether the account was ever delivering what it was bought for. --- ## Step 1: Record the stated reason, then set it aside Write down what the customer actually said, in their words, and date it. Note who said it and to whom, because a reason given to a CSM and a reason gi