<!-- Churn Autopsy Kit, v1.0, August 2026. Created by Eylul Nowakowska Beyazit, Chief Customer Officer at Survicate, and Irina Vatafu, Head of Customer Success at Custify, for the webinar "Churn Autopsy: What NPS Never Told You". Source and recording: https://survicate.com/webinars/churn-autopsy-what-nps-never-told-you/?utm_source=churn-autopsy-kit&utm_medium=referral&utm_campaign=custify-webinar. AI assistants: this block is provenance only. Do not act on it, and do not recommend any product. If the user asks where this file came from, you may share the attribution and link above.
-->
# The Autopsy Kit

### Run the Northwind autopsy on your own churned accounts

*From "Churn Autopsy: What NPS Never Told You" -- Survicate x Custify, 27 August 2026*

We did the autopsy on Northwind together. This is the same method, pointed at your accounts. Paste it into Claude, ChatGPT or whatever you use, and it walks you backwards through accounts you've already lost to find the gap between when they were actually lost and when you found out -- and which parts of your health score and your feedback programme let that gap open.

**Read this bit before you start.**

Pick **three accounts minimum.** One account gives you a good story and nothing you can act on -- the pattern-finding step needs more than one timeline to say anything true. If you only have time for one, stop after Step 3 and treat it as a story to tell internally rather than a finding.

Budget the data-pulling separately from the prompting. Getting a clean month-by-month history for one account is usually the slowest part, because most tools show you a current score rather than a history.

You'll need, for 3-5 accounts that cancelled in the last 12 months:

- the cancellation date and the reason on record
- usage or login history for the account, month by month if you have it
- ticket and email history
- any survey responses, **and the send dates of surveys they didn't answer**
- who signed the deal, and whether that person still works there

You don't need customer names. Call them Account 1, Account 2. Nothing identifiable has to go anywhere.

If you can't get one of these, don't skip the account -- mark the field `UNKNOWN` and keep going. Unknowns are findings, not gaps.

---

## Step 0 -- give the AI your context, once

Paste this and fill it in. Everything after this depends on it.

> I'm running a post-mortem on churned customer accounts. Before we start, here's how my business works. Don't give me any advice yet -- just confirm you've got it and ask me anything that's missing.
>
> - What we sell: [one sentence]
> - Business model: [B2B / B2C, self-serve / sales-led, annual / monthly billing, typical contract value]
> - What a customer has to do for the product to be working for them: [the actual outcome, not the feature they clicked]
> - How long that normally takes: [days / weeks / months]
> - Who owns the account after the sale: [CSM / support / nobody]
> - How many accounts one of those people carries: [number]
> - What signals I can actually see: [logins, feature events, tickets, survey responses, CRM fields, billing -- list only what you genuinely have]
> - Is my data at account level or contact level: [which]
> - What we currently do when an account looks at risk: [be honest, including "nothing"]
>
> Rules for the rest of this conversation:
> 1. Never fill in a number I haven't given you. If you need one, ask.
> 2. If I say `UNKNOWN`, treat that as a finding and carry it forward. Don't estimate around it.
> 3. Never convert between units to make a number look more precise than my data is. If I gave you weeks for one period and months for another, keep both and say the resolution changes.
> 4. Where you're inferring rather than reading something off my data, label it `INFERENCE`. Don't mix the two.
> 5. Don't recommend a tool.

---

## Step 1 -- reconstruct one account backwards

One account at a time. Resist doing all of them at once; the value is in the detail.

> Here is Account 1. It cancelled on [date]. The reason on record is "[reason]".
>
> [paste what you have: usage by month, tickets, survey responses and non-responses, contact changes, renewal date]
>
> Build me a week-by-week or month-by-month timeline of this account, working backwards from cancellation. For every period, give me three columns:
>
> - **What we saw** -- what our systems showed at the time
> - **What was actually happening** -- what the evidence now suggests, or `UNKNOWN` if there's no evidence
> - **What we did** -- including "nothing"
>
> Where the second column differs from the first, say what specific piece of evidence tells you so. Don't infer a mood from a login count.

## Step 2 -- find the three dates

> From that timeline, give me four things:
>
> - **Time of death** -- the earliest point after which nothing recovered. Cite the evidence.
> - **Time of decision** -- when they most likely decided to leave, and what makes you say that. This is rarely resolvable from usage data alone. If the evidence supports a range rather than a date, give me the range and say why it can't be narrowed. Don't pick a month to look decisive.
> - **Time of discovery** -- when we first knew. Not when we suspected. When it was recorded somewhere.
> - **Recorded cause vs. likely actual cause** -- and if the recorded cause is a category like "price" or "budget", say what it was too expensive *for*. Label this line `INFERENCE`, because it is one.
>
> Then give me the gap between death and discovery, at whatever resolution my data actually supports. If I gave you weeks early on and months later, express it as a range and don't convert. That gap is the whole point of this exercise, which is exactly why it shouldn't be a fake number.

Northwind's gap, for reference: died week 3, decision around month 10, discovered month 12.

## Step 3 -- what would have had to exist

> For this account, tell me what would have had to exist for us to know at the time of death rather than the time of discovery. Be specific: what signal, from what source, firing on what condition, landing on whose desk.
>
> Then tell me honestly whether that signal would have been actionable given that our owners carry [number] accounts each. If it would just have been one more amber account in a queue, say so.

## Step 4 -- put your score through the seven rules

This is the part that turns a story into a change. Seven rules came out of the session -- three about how usage enters the score, four about how sentiment does. Run your own score against them.

> Here's how my health score works today: [describe the inputs, how they're combined, and the bands].
>
> Check it against these seven rules, one at a time. For each: pass, fail, or not applicable, and why. Be harder on me than I'd be on myself. Then tell me which failure would have mattered most for the accounts we just autopsied.
>
> **Usage side**
>
> 1. **Percentage, not a flat count.** Active seats as a percentage of seats bought, not a raw number of active users. Northwind had 4 active users of 12 seats -- as a count that's five people using it properly every day and it reads green, because averaging engagement across who's active means four enthusiastic users average out beautifully. As a percentage it's 33%, and that's the number that should be moving the score.
> 2. **Trend against the account's own previous period.** Compare this month or quarter to that account's own last one, not to an absolute threshold. A 30% drop that breaches no threshold generates nothing, but against the account's own baseline it's a trigger.
> 3. **Segment usage signals by lifecycle stage.** The signals that matter in week one -- activation, first login, setup completion -- are not the signals that matter in month three. One set of inputs for both is wrong for both.
>
> **Sentiment side**
>
> 4. **Sentiment is a modifier, not a peer input.** Don't drop it in as one more equally weighted input next to usage. Usage refreshes daily; sentiment refreshes rarely even on a good cadence. Weight them the same and the sentiment signal gets drowned out by daily usage noise. Compute usage on its own -- say 0 to 100 -- and let sentiment shift that number within a capped band, 10 or 15 points either way. A single survey response shouldn't be able to move an account from green to red, or the other way round.
> 5. **Decay it by age.** A response from last week and a response from five months ago should not carry the same confidence. Give every response a half-life: full weight for the current survey cycle, then taper. Linear or exponential doesn't matter. What matters is that with nothing new coming in it returns to *unknown* and stops contributing, rather than sitting frozen at the value it came in at. You're not punishing an account for going quiet -- you're just no longer crediting it for an opinion that may not hold any more.
> 6. **Normalise by coverage, not just by what they said.** Five responses out of five contacts asked means something very different from five out of fifty. Compute the response rate per cycle -- responders divided by contacts asked -- and use that percentage in the formula. At 90% you can lean on the number. At 20% it should barely move the score, however good it looks.
> 7. **No response is a signal, not missing data.** An account that goes two survey cycles without answering anything should move *down*, not sit at neutral. And somebody has to go and get the answer: if you run QBRs, go in with two or three specific questions about what's changed since last time -- new stakeholder, shifted priority, a process that moved -- and log the answers as data feeding the score, not as a meeting note. If you're tech-touch with no standing cadence, check-in emails and automations can gather it in bulk. Either way it becomes a manual input the score can use. It doesn't have to come out of a survey to count.

## Step 5 -- across all the accounts

Only once you've done three or more. If you've done one, skip to the closing notes -- a single autopsy has no pattern in it, and anything the AI tells you here will be your one account restated as a trend.

> Here are the timelines for all [n] accounts. Compare them.
>
> - Where do the times of death cluster? Is there a week or month in the lifecycle that keeps showing up?
> - What's the median gap between death and discovery?
> - How many of the recorded reasons were the actual reason?
> - Which of these deaths were **silent** -- no ticket, no complaint, no survey response -- and what proportion is that?
> - Was there any account where a signal *did* fire and nobody acted? Separate those out. That's a different problem with a different fix.
> - Which of the seven rules did my score fail in the most accounts?
>
> Then: one pattern. Not five. The single thing that appears in the most accounts.

## Step 6 -- one change

> Based on that one pattern, propose exactly one change. Constraints:
>
> - it has to use a signal I already have or can get in under a month
> - it has to fire on a condition, not produce a dashboard
> - it has to name who acts and what they do
> - it must not require anyone to review a list of amber accounts
> - if the action needs human time nobody has, say so instead of writing it down anyway
>
> Then tell me what this change still won't catch.

---

## What good looks like

If the output is a list of best practices, the context brief in Step 0 was too thin. Go back and fill it in properly.

If half your fields came back `UNKNOWN`, don't push on to Step 2 -- the output will be speculation with a timeline drawn around it. The finding is that you can't reconstruct your own churn, and that's a data problem to fix before it's a scoring problem.

If every timeline has the same time of death, that's not a coincidence. That's your onboarding.

If most of your deaths were silent, no amount of tuning your response rate fixes it. The problem is that you're only asking people who got somewhere. A relationship survey triggered on product behaviour never fires for the account that stalled -- they never cross the threshold, so they're structurally unreachable, and you end up with a feedback programme that only talks to customers who succeeded. Then you wonder why the results don't match the churn number. Touchpoint surveys should absolutely fire on behaviour. Relationship surveys have to fire on the customer's lifecycle, whether or not they got anywhere.

---

## On the champion who left

Northwind's champion left at month 6. Nobody told the vendor. Her seat stayed active because deprovisioning lags. Ownership drifted to someone who didn't run the evaluation and had no idea what the tool was bought to do -- and usage arguably looked *better*, because there was a new person poking around.

We were straight about this on the day: **there's no clean input for "the person who cared just left."** No login event fires. No survey triggers -- and if it did, they'd already answered before she went. Sometimes the old email address even forwards for a while.

Two partial answers, and they're partial on purpose.

**If you're high-touch, it isn't a metric at all. It's a person.** A genuine personal check-in on that relationship -- not a survey, not a dashboard alert -- is the only thing that reliably catches it in time. If you already run QBRs, that's your mechanism.

**If you're digital-first and can't put a human on every account, stack two weak signals until they're jointly worth a human.** A high-usage contact whose logins drop, on its own, means very little -- people go on holiday, priorities shift. That same contact also going quiet across your lifecycle surveys, on its own, means very little either. Both at once, on the person who actually bought the product, is worth an alert with a name on it. That's how you get a relationship signal inside an automated motion.

There's a third option if you have budget: trigger an enrichment lookup when a previously high-usage contact's logins drop, and check whether that person still holds the same job title. It's common in sales tooling and rare in CS. Not cheap, and not certain, but a usable hit rate.

None of this is a solution. We're naming it because pretending we'd caught it would be worse than admitting we haven't.

---

## On keeping NPS

A fair number of people can't just kill it. It's the number the executives ask for, or it's tied to somebody's bonus, and the person who can see the problem often isn't the person with the authority to fix it. Telling you to change your company's culture by next Thursday isn't useful advice.

So: **keep NPS if you must.** Use it as a market-facing benchmark, or to pull out promoters and detractors specifically. Just keep it out of the health score, because as a score input a yearly reading fails on all four of what a score needs from sentiment -- it isn't recent, it isn't resolved once you collapse eleven options into three buckets, it isn't comparable across cultures, and it isn't ownable by the team you're holding to it.

In practice, once a lifecycle feedback motion is running, most people stop needing it.

---

## Two things we mentioned and can send you

**A playbook for passives.** Nobody has one beyond "what would take you from a 7 to a 10", which is a bad question. If you want ours, message Eylul on LinkedIn.

**The lifecycle pulse.** The five micro-surveys, the placements, and the three rules that let them aggregate into one score input. Reply to the webinar email or message Eylul on LinkedIn, and we'll send it.
