A churn interview is a consent-based reconstruction of what happened before and after cancellation. Recruit without pressure, separate research from a rescue offer, ask permission before recording, and capture the incident sequence rather than pushing the customer through a generic question list.
Invite the customer without creating an obligation
Choose accounts because their cancellation context can answer a research question: an activation failure, a reliability incident, a role change, a package decision, or an unknown replacement. Do not contact people merely to fill an interview quota. Check any communication preferences and internal obligations that apply to your business before reaching out.
The invitation should make three things clear: participation is optional, the cancellation remains unaffected, and the customer can choose a call or a short written reply.
Do not promise anonymity, deletion, incentives, or confidentiality terms unless you can actually operate them. If you offer compensation, state it before the customer agrees and do not make payment depend on a positive review or a return to the product.
Open with a consent check
Before the interview begins, restate the purpose and boundaries. A practical opening is:
“I want to understand the sequence around the cancellation so we can learn from it. I’m not going to ask you to reverse the decision. I’ll take notes. Is that okay? If I want to record, I’ll ask separately, and we can continue without recording.”
If the person declines recording, do not record. If they do not want to discuss a topic, move on. Avoid requesting sensitive customer, employee, financial, health, or credential data that is unnecessary for the research question. Keep the interview focused and optional. If your company has separate requirements for recording, research, or customer data, check them before the interview.
Reconstruct one real incident
Begin with the last specific job, not an opinion about the product as a whole. Follow the customer’s sequence and ask for concrete states, artifacts, and handoffs where appropriate.
| Stage | Prompt | Listen for |
|---|---|---|
| Last successful job | “Walk me through the last time the product helped you complete the job.” | The retained promise, input, output, owner, and surrounding workflow. |
| Next trigger | “What happened the next time you needed to do that work?” | Whether the job recurred, changed, or disappeared. |
| Break point | “Where did the process become slower, uncertain, or impossible?” | An activation step, missing state, reliability failure, permission, handoff, or support dependency. |
| Response | “What did you try after that?” | Retries, support contact, manual work, delay, abandonment, or escalation. |
| Replacement | “How is that job handled now?” | A spreadsheet, another product, a person, a service, a reduced scope, or no replacement. |
| Cancellation trigger | “What made cancellation happen at that point rather than earlier or later?” | Renewal, budget review, incident, role change, low frequency, procurement, or unresolved friction. |
| Counterfactual boundary | “What would have needed to be different before that moment for staying to remain an option?” | A condition grounded in the incident, not a speculative feature wishlist. |
Follow an answer with “What happened next?” or “What did you see?” rather than explaining how the feature was supposed to work. If the customer names several problems, return to the timeline and locate the first point where the required job stopped.
Illustrative excerpt: preserve the sequence
Illustrative interview excerpt — fictional dialogue, not a customer transcript. Assumptions: the product sends recurring client reports; the participant cancelled after an internal role change; no recording is made.
Interviewer: What happened the next time the report was due?
Participant: The person who set it up had left. I could see the dashboard, but I did not know which data source fed the report.
Interviewer: What did you do then?
Participant: I exported the source data and rebuilt the report in our spreadsheet. I cancelled when the renewal email arrived.
Interviewer: What would have needed to be different before that renewal?
Participant: A handover note showing the data connection and report owner would have helped. I cannot say whether we would have stayed.
The useful evidence is not “customer wanted documentation.” The sequence is role change → ownership became unclear → report could not be trusted → spreadsheet replacement → renewal triggered cancellation. The final sentence also preserves uncertainty rather than inventing a save.
Synthesize incidents without flattening them
Complete one record per interview before grouping themes. Keep the customer’s words beside your interpretation so another reviewer can challenge the code.
| Field | What to capture |
|---|---|
| Research consent | Call or written reply; note-taking agreed; recording agreed or declined; any requested limits. |
| Account context | Buyer role, operator role, package, relevant integration, expected job rhythm, and known constraints. |
| Last successful job | Date or relative point, input, output, and evidence that the result was useful. |
| Incident sequence | Trigger → attempted action → break → response → support or workaround → consequence. |
| Cancellation trigger | The event that caused cancellation to happen when it did. |
| Replacement | Product, spreadsheet, manual work, service, reduced process, or nothing. |
| Customer language | Short verbatim phrases, separated from the researcher’s cause label. |
| Cause hypotheses | Fit, activation, reliability, support/workflow friction, price/value, payment, role change, or unknown; allow competing codes. |
| Contradicting evidence | Facts that weaken the leading interpretation. |
| Confidence and gaps | What is observed, what is recalled, what is inferred, and what data is missing. |
Move from interviews to a theme table
Group records by the same workflow break, not by broad sentiment. “Too expensive,” “not needed,” and “hard to use” are cancellation language; they may point to different sequences. A useful theme row includes the eligible account context, repeated break point, replacement behavior, supporting artifacts, contradictions, and the decision the evidence could inform.
Keep the interview separate from remediation
- Do not turn the call into a feature demo or a defence of past decisions.
- Do not treat one vivid account as a prevalence estimate.
- Do not merge the participant’s words with your cause code.
- Do not promise that feedback will produce a feature or that the customer will be contacted again.
- Do not conclude that the product caused the cancellation when the evidence only shows timing or correlation.
The interview output is a consent record, an incident reconstruction, and a coded synthesis entry. The decision about which churn intervention to run belongs in a separate diagnosis that also checks product events, tickets, billing, and comparable accounts.