How to interview churned customers: start long before they canceled
Interview churned customers about what changed before they canceled. A timeline separates setup problems, changed needs, the final trigger and what they do now.
To interview churned customers well, ask what changed between choosing your product and no longer using it. The day they canceled is one event in that sequence. The experience that made the product less useful often happened earlier, or the customer's circumstances changed entirely.
Treat billing status, product activity and the customer's own account as different evidence. Someone can stop doing meaningful work while the subscription stays active; someone else can cancel and keep doing the task another way.
The worksheet below organizes the conversation as a timeline. It uses a made-up project-handoff tool to show the method; the example is not a report about a real customer or product.
1. Decide which "churned" you mean
"Churned customers" can mean former paying accounts, people who canceled during a trial, organizations with no recent activity, or individual users who left an otherwise active account. Pick the group that matches your decision and describe it precisely.
If the question is about recurring value, someone who never finished setup had a different experience from someone who used the product for a year. Both may matter, but mixing them too early can hide the problem you need to find.
Record the period, the account context and the person's role. Check that contacting them fits their communication preferences. A research request does not erase an earlier request to stop contact.
2. Start with why they signed up
Ask what was happening when they first considered the product. What job did they hope to do? What did they use before? What changed when they started?
GOV.UK's user-needs guidance focuses on what people are trying to achieve and how they do it now (the user-needs guidance). Apply that to the customer's original task before you get to your feature list.
Don't read the original sales promise back to them as if it were their goal. If their account differs from the onboarding notes, keep both and find out why.
3. Fill in a lifecycle ledger
Build this ledger during the conversation or right after it. Exact dates help when you have them, but an approximate order beats an invented date.
| Stage | Evidence to record | Question to explore |
|---|---|---|
| Initial task | Work the person wanted to accomplish | "What did you need to get done?" |
| First attempt | Setup and earliest real use | "Walk me through the first time you tried." |
| Useful period | An instance when the product served the task | "When did it work well for you?" |
| Change | A new constraint, problem, or different priority | "What started to change?" |
| Last meaningful use | Final task completed or attempted | "What were you doing that last time?" |
| Cancellation | Administrative action and decision owner | "How did ending the subscription happen?" |
| Present approach | What now happens to the original work | "How is that task handled today?" |
Not every customer had a useful period. If they never completed the task, mark that and spend more time on the first attempt.
4. Separate the trigger from the underlying problem
A cancellation email might mention price. The person may describe a different sequence: a team reorganization reduced usage, the owner stopped checking the product, and a renewal notice prompted the final decision.
That is one possible sequence, not a theory of churn. Ask what happened in this case and who experienced each step.
When someone says the product was too expensive, ask what value they were getting at that point and what alternatives they considered. Don't turn the interview into a price negotiation. You want to understand the decision, not teach them that "too expensive" earns a discount.
5. Ask about a time it worked, too
A memorable failure can take over the conversation. If the product was once useful, ask about one specific successful task and compare its circumstances with the last abandoned one.
Did the same people take part? Was the work similar? Had the team's tools, volume, responsibilities or requirements changed? These comparisons show where the product's usefulness ran out. A discussion guide can hold these questions while leaving room to follow the person's story, which fits GOV.UK's guidance for in-depth interviews (the interview guidance).
The example: an agency that brought its work in-house
Here is a made-up example. An agency adopted a project-handoff tool when several freelancers worked on each client project. Later it brought the work in-house. Handoffs continued, but a daily internal meeting now covered them. The subscription was canceled during an expense review.
"Cost" describes the final review. The changed team structure helps explain why the product had stopped being useful, and a new handoff feature might not change that.
The useful next question is whether the product still fits agencies with distributed contributors, or whether another job is left unsolved once work moves in-house. One interview can't answer either question across the market.
6. Check the story against your records, gently
If you have permission and the right access, compare the timeline with product events, support requests and billing dates. Use the records to clarify the order of events, not to cross-examine the person.
An event log shows that something happened, but maybe not why, or whether it was useful. An interview supplies context but relies on imperfect memory. Keep both limits in view.
When records disagree, note the gap and ask a neutral clarifying question if they agreed to further contact. Don't quietly overwrite their explanation with a guess from activity data.
Let the ledger choose the follow-up
Use the ledger to find where the uncertainty sits. A failed first attempt calls for watching someone set up. A once-useful workflow calls for studying what responsibilities changed. A move to another approach calls for understanding that new workflow. A cancellation caused by a closed business may not point to a product problem at all.
Write each action next to its evidence and the strongest alternative explanation. Keep any attempt to win the customer back separate from research follow-up.
A good churn interview tells you where usefulness ended and what evidence would justify a change, which one cancellation reason in a spreadsheet never will.
Follow usefulness through the customer lifecycle
- 1
Original task
Why did the person start?
- 2
Useful period
When did the product serve that task?
- 3
Change
What conditions or experiences shifted?
- 4
Exit
Separate last meaningful use from cancellation.
- 5
Present approach
What happens to the work now?