01
Why the reason field lies
Open the churn report in most CRMs and the reasons read like a menu. Budget. Went with a competitor. Product fit. Changed priorities.
They are not false. They are the last true thing the customer said, picked because it ends the conversation fastest. Nobody leaving a vendor wants a forty-minute debrief about the integration that was promised for Q2 and shipped in Q4, so they say budget, and everyone moves on.
A CS lead on r/CustomerSuccess described their own company this way: churn reasons were surface level and not documented well. A reply in the same thread went further. If a customer leaves and nobody noticed anything in the six months before, the problem was how the account was being managed, long before the notice arrived.
That gap is what this playbook is built to find.
02
Decide first: good churn or bad churn
Within 5 business days of the notice · Owner: CS lead
Not every lost account deserves three hours. Sort it first.
Good churn is an account that was never going to work: bought outside your ideal customer profile, got acquired, ran out of money, shut the team down. You learn something about sales targeting and move on. Bad churn is an account that could have got the value and did not. That is the one worth the work, because it failed in some specific way that can be fixed.
Be strict. Teams love filing bad churn as good churn, because "they were never a fit" is a sentence nobody gets blamed for. If sales qualified them, you onboarded them, and they paid you for a year, they were a fit.
03
Rebuild the timeline of promises, in both directions
Owner: CSM, with CS ops
This is the expensive step, and it is the one that changes the answer.
Pull everything since signature: call recordings, the handoff notes, email threads, support tickets, QBR decks. Build one dated list of every commitment made in either direction. What you said you would do, and by when. What they said they would do, and by when. Then mark each one kept, late or never. If you ran a proper sales to CS handoff, the first rows are already written.
Most teams have never seen this list for a single account, and it is usually where the post-mortem stops being a debate. An account marked "budget" that turns out to have four missed promises on it, the oldest seven months old, did not leave over budget.
The customer's side of the list matters as much as yours. An account that promised to assign an internal admin and never did, or promised a second-team rollout that stalled, was telling you something long before it gave notice.
Date Direction Commitment Owner Due Status
2026-02-11 Us to them SSO live before team rollout Eng lead 2026-03-31 Late, shipped 06-02
2026-02-11 Them to us Assign an internal admin Their COO 2026-02-28 Never
2026-04-09 Us to them Custom usage report for the VP CSM 2026-04-30 Never
2026-05-14 Them to us Roll out to the support team Their VP CS 2026-06-30 Stalled04
Mark the first moment it was still savable
Owner: CS lead
Walk the timeline from the beginning and stop at the earliest point where a different action would plausibly have changed the outcome. Not the last touch before the notice. The first one.
It is almost never the renewal call, because by then the decision has been made. Look earlier, at the usual suspects: a missed promise nobody escalated, a champion who changed jobs and was never replaced, an onboarding that quietly stalled halfway.
Write that moment down in one sentence, with a date.
That sentence is the finding. Everything else in the post-mortem is evidence for it. If you want an early-warning version of this for live accounts, renewal risk flagging is the same idea run forwards instead of backwards.
05
One exit conversation, and do not try to save it
Owner: Someone other than the CSM
Ask the customer for twenty minutes, and send someone who was not their CSM: a CS leader, or the founder at a small company. The CSM is too close to it, and the customer knows that and will be kind to them.
Three questions, in this order. When did you first start thinking about leaving? Was there something we said we would do that did not happen? What would have had to be true for you to stay?
The first question dates the real decision, which is often well before the notice. The second checks your timeline against their memory, and where the two disagree, believe their memory. The third tells you whether this was ever fixable.
Do not pitch. Do not offer a discount. A save attempt inside an exit call turns a debrief into a negotiation, and you lose the one honest conversation you were going to get.
06
Record the stated reason and the root cause as two fields
Owner: RevOps
Add two picklists to the Account: Churn Reason (stated) and Churn Root Cause. Keep them separate on purpose. The stated reason is what the customer said. The root cause is what the timeline shows.
When they match, fine. When they do not, you have learned something, and the gap between those two columns is the most honest report your CS team will ever produce.
Keep the root-cause list short. Seven values at most, or it becomes a free-text field with extra steps.
Onboarding never finished
Champion left and was not replaced
Committed deliverable missed
Value never measured or shown
Pricing or packaging mismatch
Genuine product gap
Good churn (never a fit, acquired, shut down)07
Read them together, once a month
Monthly · Owner: CS lead and head of sales
One post-mortem is an anecdote. Ten of them read side by side are a map of where your customer lifecycle leaks.
Once a month, put the root-cause column in front of the CS lead and the head of sales, in the same room. The pattern tends to be obvious and uncomfortable. A root cause that keeps recurring at onboarding is a capacity problem. One that keeps recurring at "committed deliverable missed" is a sales problem wearing a CS badge.
Whether to share the post-mortem with the customer who left is something this playbook leaves open. Some teams send a short, honest summary on the theory that it leaves the door open. Others think it reads as self-serving. Both have a point.
"Budget" is the answer that ends the conversation. Find out what the account was waiting on before that, and make sure the next one is not waiting on the same thing.
FAQ
What is a churn post-mortem?
A structured review of a customer who left, run after the notice, that looks past the reason they gave and reconstructs what actually happened: every promise made in both directions, when the account became unsavable, and the root cause. It is recorded separately from the stated reason so the two can be compared.
What is the difference between good churn and bad churn?
Good churn is an account that was never going to succeed, because it bought outside your ideal customer profile, was acquired, or shut down. Bad churn is an account that could have got value and did not. Only bad churn needs a full post-mortem, and teams should be strict about not filing bad churn as good.
What questions should you ask a customer who is churning?
Three, in order: when did you first start thinking about leaving, was there something we said we would do that did not happen, and what would have had to be true for you to stay. Have someone other than their CSM ask them, and do not attempt a save or offer a discount in the same call.
How should churn reasons be recorded in the CRM?
As two separate picklists on the Account: the reason the customer stated, and the root cause your review found. Keep the root-cause list to about seven values so it stays usable, and review the two columns side by side each month.
Want this run for you instead of by you?
Mindlyft builds post-call workflows inside your own CRM, drafts every customer-facing action, and holds it for a human to approve. We engineer the first workflow free.
Apply for a slot