RescueChurn post-mortemHuman review required

Churn Post-Mortem

Turn a lost account into a blameless, specific debrief your team can learn from, not a blame memo or a shrug.

A churn post-mortem earns its keep only if it is blameless and specific. The version that teaches something dates the real decisive moment, separates root cause from symptom, marks what was outside your control, and proposes a systemic change instead of a promise to try harder.

The template

Copy it, swap the {{marked}} variables for your account, and run it.

prompt.txt

Write a blameless churn post-mortem for an account we lost. The goal is a
lesson the team can act on, not a story that assigns blame or shrugs.

Account: {{account_name}}
ARR: {{arr}}
What they told us about leaving: {{loss_summary}}
Facts from the record (dates, tickets, changes): {{timeline_facts}}
My read on what actually happened: {{our_read}}
What we tried: {{what_we_tried}}

Produce:
1. A timeline of the decisive moments: when the loss actually became likely,
   not just the cancellation date.
2. Root cause, separated clearly from the symptoms.
3. What was in our control versus what was not.
4. One or two systemic changes that would catch this class of loss earlier.

Rules:
- Separate root cause from symptom. Usage decline is a symptom, not a cause.
- Distinguish what we controlled from what we did not. Be honest about both.
- No individual blame. Name the process gap, not a person.
- Use only facts from the record. Mark every inference as an inference.
- Propose systemic fixes. "Try harder" is not a finding.

Variables

{{account_name}}: Account namee.g. Corian Foods
{{arr}}: Annual recurring revenuee.g. $90,000
{{loss_summary}}: What they told us about leavinge.g. went with a competitor; cited 'missing integrations' and 'slow support'
{{timeline_facts}}: Facts from the recorde.g. sponsor changed in March; P1 integration ticket open 5 weeks in Q2; usage down 40% by June; non-renewal notice in July
{{our_read}}: Your read on what happenede.g. we never built a relationship past the original sponsor
{{what_we_tried}}: What you triede.g. two save calls in June, an eng escalation, a discount offer

Worked example

An account has churned and leadership wants a debrief. The CSM has seen these turn into either a blame memo or a vague "they picked a competitor" that teaches nobody anything. She wants a post-mortem that names the real cause and changes how the team catches the next one.

filled-prompt.txt

Account: Corian Foods
ARR: $90,000
What they told us about leaving: went with a competitor; cited "missing integrations" and "slow support"
Facts from the record (dates, tickets, changes): sponsor changed in March; P1 integration ticket open 5 weeks in Q2; usage down 40% by June; non-renewal notice in July
My read on what actually happened: we never built a relationship past the original sponsor
What we tried: two save calls in June, an eng escalation, a discount offer

Good output vs bad output

GOODDates the real decisive moment instead of the cancellation, separates the root cause from the symptoms, splits controllable from not, labels the one inference as an inference, and proposes two systemic fixes rather than more effort.

DECISIVE MOMENT: The loss became likely in March, when the sponsor changed,
not in July when the notice came. We treated March as routine and kept selling
to a champion who was already gone.

ROOT CAUSE: Single-threaded relationship. Value lived with one sponsor and was
never built into the team or a second stakeholder.
SYMPTOMS (not the cause): the 40% usage drop and the open P1 were real, but
they were downstream of having no one left who cared to escalate internally.

IN OUR CONTROL: multithreading past the sponsor; catching the March change as
a risk; the P1 sitting open 5 weeks.
NOT IN OUR CONTROL: the sponsor leaving; the competitor's timing. [INFERENCE:
we believe a competitor was in before the P1; the record does not confirm it.]

SYSTEMIC FIXES:
1. Make a sponsor change a health-score trigger, so a March event opens a save
   motion instead of passing unnoticed.
2. Require a named second stakeholder by day 90 of onboarding. An account with
   only one relationship is not "healthy," whatever the usage number says.

BADLooks fine at a glance. Here is why it fails.

Corian Foods churned because the competitor undercut us on price by about 30%
and they were probably always going to leave once the new VP came in, since
that VP had a relationship with the other vendor. Honestly the account was a
lost cause from Q1. Our AE also should have caught this sooner. Lesson learned:
we need to be more proactive and provide better support going forward. We will
do better next time.

Hallucinated specificsInvents a "30% price undercut" and a VP relationship with the competitor, neither of which is anywhere in the record; it manufactures a tidy story.
Unverified claim"Probably always going to leave" and "lost cause from Q1" are stated as fact, the hindsight certainty that stops a team from finding the real, fixable cause.
Wrong registerNames and blames the AE ("our AE should have caught this"), which guarantees people hide the real causes in the next debrief.
No next step"Be more proactive" and "we will do better next time" are effort, not a systemic change; nothing about how the team works actually changes.

Guardrails

When NOT to use this

Do not run a post-mortem while the account might still be saved; a retrospective on a live deal demoralizes the team and distracts from the save.
Do not use it as an input to a performance review; the moment blameless becomes evidence against someone, the honesty dies.

Responsible use

Keep it blameless and process-focused, or people will quietly hide the real causes to protect themselves next quarter.
Label every inference as an inference. Lost-deal stories harden into false certainty within a week, and the wrong lesson costs you the next account.

A human must review the output before it reaches the customer.

Model + settings

Model: Claude Sonnet for most debriefs, Opus when the loss is strategic and the readout goes to leadership.
Temperature: 0.2 (low, you want it anchored to the record, not a narrative)
Settings: Give it only facts from the record and label your own reads as inferences, or it will confidently invent a clean story.
Ask explicitly for systemic fixes. If the output is "try harder" or "be more proactive," send it back; that is not a finding.

Back to all prompts