How to Analyze Cancellation Interviews Without Jumping to a Fix

Start with the decision, not a cancellation label

A cancellation interview becomes useful when you can follow a clear chain: what happened before the customer left, the words and context that support an explanation, evidence that challenges it, and the next check that could change a product decision. “Too expensive” is a topic to investigate, not yet a finding that the price should fall.

This guide uses an invented subscription-tool example. Its participants, quotations and proposed actions are hypothetical. It does not report ScribeFlash customer results or promise a reduction in churn.

1. Define which departure you are studying

Write a decision question before recruiting: “What should we investigate before changing the export experience for small research teams?” Record the relevant plan, user role, cancellation date, last useful task and available account history. Distinguish a voluntary cancellation from a failed payment, an ended project or a company-wide spending freeze.

Interview material can explain a person's experience. It cannot by itself establish the overall rate or cause of churn. If you need commercial context, compare the qualitative account with permitted billing or usage records outside the interview, keeping those sources clearly identified.

Use the cancellation interview option in the research templates to begin with research questions rather than an empty project. The interview planning guide helps define the study boundary.

2. Reconstruct the last real attempt

Ask about an episode the participant can describe, rather than an imagined rescue offer:

• “What were you trying to finish the last time you used the product?”
• “What happened when you tried to export the result?”
• “What did you do next, and who else was involved?”
• “When did you decide not to renew?”
• “What would still have made you leave if exporting had worked?”

A request for a cheaper plan can sit alongside a blocked task. Do not force the participant to choose one cause too early. Ask what the cost was being compared with and whether the alternative actually solved the same job. Avoid “Would this new feature make you stay?” as the main evidence for a roadmap commitment.

3. Keep a quote, a reading and a boundary apart

Suppose fictional participant C1 says at 12:40: “I wish it weren't so hard to export data. That's the main reason I didn't renew.” Save those exact words, the participant code, timestamp, preceding question and the task being attempted.

A researcher note could say: “Export friction appears to have contributed to this cancellation.” That is an interpretation. “Fixing export will recover this customer” goes beyond the quote: the participant has not demonstrated a return, and other barriers may remain.

The GOV.UK research analysis guidance distinguishes observations from findings and actions. Apply that separation to your own notes, rather than rewriting an interpretation as if the customer said it.

In ScribeFlash, review meaning-changing errors in the transcript editor, then save the relevant passage as evidence. Keep your explanation in the researcher note.

4. Give counter-evidence a place in the finding

Now add fictional C2: “Exporting was fine. Our project ended, so we no longer needed a subscription.” C2 challenges a universal explanation, even though it does not erase C1's difficulty.

Compare cases by the job, point of failure, workaround, reason for leaving and remaining uncertainty. Separate “could not complete the handoff” from “did not have another project.” Do not merge them into a single “low value” tag and lose the distinction.

A bounded candidate finding is: “Export friction contributed to C1's departure while preparing a research handoff; C2 left after the work ended.” Include both source references. A mention count describes this material; it is not a population estimate or proof of which problem caused the most lost revenue.

5. Turn the finding into a checkable next step

Create a small validation note with five fields:

1. Hypothesis: people preparing a research handoff cannot find a suitable export.
2. Evidence: C1's quote and task context; C2's differing departure reason.
3. Unknown: whether the obstacle is discoverability, file contents, permissions or a missing format.
4. Next check: observe a relevant user attempt the handoff in the current product before designing a solution.
5. Decision rule: choose a change only if the observed failure supports it; change the hypothesis if the handoff works and another obstacle explains the departure.

Assign an owner and a review date. These are proposed follow-up tasks for your team, not outcomes already established by the interviews. If a prototype is tested later, record that new evidence separately.

6. Deliver a decision record with limits

The report should state the research question, who was interviewed, the relevant episodes, supporting and contradictory quotations, the scope of each finding, and the next validation task. Keep suggested actions separate from facts. Note missing groups, unclear chronology and sources you could not verify.

Before confirming a finding, ask another reviewer to inspect the source and its counter-evidence. “Confirmed” records a human review decision in the workflow; it does not establish statistical certainty. Use the report guide to carry confirmed findings into an editable report and inspect quotations before exporting it.

Try the chain with a clearly labelled example

The sample project includes downloadable English and Chinese reports plus bilingual synthetic source data. Use it to inspect how evidence and findings are connected, then start your own study from the research templates. The sample uses invented excerpts and does not demonstrate a live transcription or a real customer's cancellation.