Churn Interview Script

Reconstruct the Exit

A cancellation tells you when the account ended, not why. The decisive moment may have come weeks earlier: an import failed, the first report disappointed a buyer, the team returned to a spreadsheet, or the problem simply stopped being urgent. Use this interview to reconstruct that path.

The conversation is not a rescue attempt. If the customer has to defend the decision or soften every criticism, you will learn how they manage an awkward vendor conversation rather than how the product lost its place in their work.

Reach out after a cancellation, non-renewal, failed pilot, stalled onboarding, or sustained fall in meaningful use. Do it while the sequence is still memorable, but not while an urgent support incident remains unresolved. Failure recovery comes first.

Prepare an Account Trace

Before the call, assemble a short account trace: the promise made, intended users and buyer, success criteria, onboarding events, meaningful usage, support history, plan and renewal dates, and any replacement the customer mentioned. Treat product telemetry as a memory aid, not a verdict. It can show that usage stopped; it cannot tell you what made stopping sensible.

Invite Candor

Hi [Name],

I saw that [account/team] [canceled/stopped using/did not renew] [product].
I am not asking you to reconsider. I would like to understand what happened
between deciding to try it and deciding it was no longer worth continuing.

Would you be open to a candid 15-minute conversation? Direct criticism is
useful, and there is nothing you need to prepare.

Open by making the boundary credible:

Thanks for taking the time. I am here to understand the decision, not defend
the product or make you sit through a save offer. I would like to walk through
what you expected, what happened in practice, and what you did instead.

Do not promise that every criticism will become a feature. You can be grateful and still leave the product decision open.

Walk the Timeline

Begin before the product entered the account. This establishes the job it was hired to do and the standard it had to beat.

What was happening when you first looked for a solution?
What were you doing before [product]?
What did you expect would become different after adopting it?
Who cared most about that result, and how would they have recognized success?

Then find the best point in the relationship. A customer who never reached value presents a different problem from one who received value and later lost it.

What is the most useful result you got from the product, if any?
Can you take me through the last time it worked well enough to matter?
If it never did, where did progress first stop?

Now slow down around the turn. Ask for an event, not a general rating.

When did you first suspect you might stop using it?
What happened on that occasion?
What did you try next?
Was there a person, workflow, piece of data, or approval the product could not accommodate?
After that, did anyone try to restore use? What happened?

If the customer says, “It was too expensive,” or “The team did not adopt it,” stay with the phrase until it describes conduct. Ask what the product was compared with, who stopped doing what, and what continuing would have required. Do not supply a diagnosis for them.

Follow the account out of the product:

What are you doing now instead?
What became easier after the switch? What became harder?
Who decided it was time to stop, and whose experience shaped that decision?
Was cancellation immediate once the decision was made, or did the account remain unused first?

The replacement is often the clearest measure of the lost job. A customer who returns to a spreadsheet is telling you something different from one who funds an enterprise platform, hires a person, or abandons the work altogether.

Only after the history is clear, ask the counterfactual:

What would have needed to be true for continuing to make sense?
Which part could the product realistically have changed, and which part belonged to your situation?
Who do you think the product is a better fit for?

Answers here are hypotheses, not a feature backlog. A requested integration may conceal weak urgency; a discount may not repair missing trust; an onboarding change cannot create a frequent problem where none exists.

Listen Without Abandoning the Facts

Do not correct minor inaccuracies during the story. When a factual disagreement changes the diagnosis, reflect it neutrally: “I had the export recorded as completed on Tuesday; what happened when you tried to use the file?” The aim is to recover the customer’s experience without pretending the account trace does not exist.

Avoid combining the learning interview with a discount, roadmap promise, or custom-support offer. If a genuine recovery path appears, ask whether the customer wants a separate conversation. Keeping it separate protects both the evidence and the customer’s freedom to decline.

Turn One Story into a Decision

Immediately afterward, write the account as a sequence: initial job, expected result, first value or first blockage, turning event, attempts to recover, final decision, and replacement. Mark what came from observed account history, what the customer stated, and what you inferred. Record whose perspective you heard; a user, buyer, and approver can leave for different reasons.

Then choose the smallest implication the evidence supports. Repair onboarding when qualified customers repeatedly stall before a first valuable outcome. Revisit product scope when the same necessary workflow breaks across well-matched accounts. Change positioning or sales qualification when the promise recruits customers whose job, authority, or operating conditions the product does not serve. Examine pricing when customers achieve and recognize the intended value but continuing still loses to a credible use of the same budget.

Do not treat every departure as preventable. Some work is seasonal, some customers outgrow a narrow product, and some low-frequency problems do not justify a subscription. For a solo founder, retaining a poor-fit account through manual accommodation can be worse than learning where the product should stop.

One interview can reveal a failure you can verify immediately. It rarely establishes a market pattern. Compare traces across accounts by segment, promised job, point of failure, and replacement; raw cancellation counts can hide those differences.

The interview has done its work when you can name the first consequential break, explain why recovery failed or never began, identify what replaced the product, and decide what evidence to collect next.