Customer Exit Interviews: Find the Job Your SaaS Stopped Doing
Use a practical customer exit interview script, distinguish reason codes from evidence, and turn small samples into focused SaaS product decisions.
A customer exit interview should reconstruct the job your product stopped doing for a departing customer. Ask what happened, what they tried, and what they use now. Treat the conversation as research, with cancellation already respected, rather than a disguised sales call or a demand that they justify leaving.
For a small SaaS founder, this is more actionable than collecting a chart full of “too expensive” responses. That phrase might mean the customer lost a budget, stopped needing the job, could not finish setup, or found a better alternative. Each explanation calls for a different decision.
Contents
Who should you invite to an exit interview?
Start with a defined group of recent, voluntary cancellations whose intended customer job you understand. Separate payment failures and administrative closures before interpreting departures as product rejection.
Choose a window you can explain, such as accounts that canceled during the previous calendar month. Record who was eligible, who was invited, who answered, and who declined. A convenient set of friendly respondents is useful for learning, but it does not represent every customer who left.
Thematic’s guidance on churned-customer feedback highlights a practical gap: current-customer surveys omit many people who already departed. Historical support conversations can provide additional context when those people do not respond.
For your first pass, include different departure situations: someone who never completed the main task, someone who used it successfully and later stopped, and someone who moved to another solution. Do not force those journeys into a single explanation merely because they ended with the same cancel button.

How can you ask without obstructing cancellation?
Make the research invitation optional and separate from the customer’s ability to leave. State the time requested, purpose, and whether you intend to record the conversation.
Here is an original invitation template you can adapt:
Your cancellation is confirmed. I’m trying to understand where our product stopped being useful. If you are open to a twenty-minute conversation about the task you were using it for, I would appreciate your perspective. There is no need to reconsider your cancellation, and declining will not affect your account.
Do not promise a reward you have not approved or imply that answering is required. Ask permission before recording, and keep the resulting notes limited to the research purpose.
Stripe’s customer-portal documentation describes collecting a cancellation reason after a customer cancels. It lists options such as price, missing features, alternatives, and no longer needing the service. These are useful starting categories, not complete explanations of the decision.
If a customer only wants a short text reply, accept that. The goal is understanding, not maximizing the number of calls on your calendar.
What should a twenty-minute interview cover?
Use a timeline that moves from the original task to the replacement. The schedule below is an editorial template, not a tested claim that twenty minutes is optimal.
| Time | Focus | Evidence you want |
|---|---|---|
| First 2 minutes | Permission and context | Customer’s own description of the job |
| Next 10 minutes | Last real attempts | Actions, obstacles, and when the decision changed |
| Next 5 minutes | Replacement | What happens to the job after cancellation |
| Final 3 minutes | Correction and close | Customer confirms or corrects your understanding |
Use these six questions in a natural conversation:
- 1.What were you trying to accomplish when you first chose the product?
- 2.Walk me through the last time you tried to do that task.
- 3.Where did the process become difficult, unnecessary, or less useful?
- 4.What did you try before deciding to stop?
- 5.How are you handling the task now?
- 6.What have I misunderstood about your decision?
Ask for a concrete recent episode when an answer stays abstract. “It was confusing” becomes more useful when the customer can identify the screen, missing input, or handoff that failed.
Avoid leading questions such as whether your planned feature would have saved the account. Churnkey’s follow-up-question documentation illustrates how a broad cancellation category can be followed by a more specific answer. Your interview should pursue that specificity without turning a hypothesis into a suggested response.
How do you turn a reason into evidence?
Keep the customer’s statement, the observed sequence, and your interpretation in separate fields. A reason code becomes useful when it connects to an actual task and an actionable uncertainty.
For example, a fictional customer selects “too expensive” but describes spending an hour repairing an export before sharing it with a client. The evidence is their account of the repair and the affected task. “We need a cheaper plan” is only one possible interpretation; “the export failed to deliver the promised value” is another.
Use a note like this:
| Field | Fictional example |
|---|---|
| Original job | Send a usable weekly client report |
| Last attempt | Export required manual repair |
| Stated reason | Too expensive |
| Replacement | Existing spreadsheet |
| Evidence to inspect | Export settings and the related support ticket |
| Unresolved question | Whether the same problem affects retained users |
Thematic’s cohort guidance recommends comparing departed and retained customers rather than analyzing complaints in isolation. If both groups mention the same issue, additional context is needed before declaring it the cause of cancellation.

What can a small sample actually tell you?
It can reveal plausible failure modes and language worth investigating. It usually cannot establish how common a cause is across all customers or prove that a proposed fix will reduce churn.
Consider a hypothetical month with twenty cancellations. You invite eight customers, interview four, and three describe a difficult handoff. That is three of four interviewees, or 75% of the interview sample. It is not evidence that 75% of all canceled customers had the problem; sixteen did not participate in the interviews.
Preserve those denominators in the report. Nonresponse is unknown information, not agreement with the people who answered. Also record the selection rule: interviewing only large accounts, for example, changes the population your findings describe.
The SuperX project record links to a founder interview mentioning churn near 30% alongside a payment-platform migration. The excerpt does not define a clean cohort or period. It provides a question to investigate, not a benchmark to compare directly with your own cancellation rate or proof of a specific retention problem.
How should the findings change your product?
Choose one concrete change supported by the evidence, then define the next observation that would test it. Do not turn every requested feature into a promise or every cancellation into a discount.
For the fictional export problem, a reasonable next step is to reproduce the export with permission using non-sensitive material, repair the specific failure, and observe whether comparable customers complete the handoff. The success measure is successful delivery of the job, not simply fewer people selecting a reason code.
The Baremetrics record describes cancellation insights as a distinct workflow alongside subscription analytics. Its creator walkthrough is not proof that installing a tool improves retention. You still need a person responsible for investigating evidence and following through on a change.
Connect findings to your existing customer-support process, and use time to value when the problem occurs before the first useful outcome. If the remedy adds substantial human work, check the delivery-cost worksheet before promising it indefinitely.
Keep a simple decision log: finding, evidence, action, owner, and next check. A successful interview ends with a clearer operating decision. It does not require persuading the departing customer to return.
Frequently asked questions
When should I invite a departing customer?
Soon enough that the task and decision are still memorable, after making the account’s cancellation status clear. The invitation should be optional and easy to decline.
How many interviews are enough?
There is no universal number established here. Start with a defined cohort, disclose participation, and look for concrete problems to investigate. Do not turn a small convenience sample into a population percentage.
Should I offer a discount during the interview?
Keep research separate from retention selling. First understand the task and departure. A discount does not solve a broken workflow or a customer who no longer needs the service.
Should failed payments be included?
Track them separately. A payment failure does not necessarily indicate a deliberate decision to leave, so combining it with voluntary cancellations can distort the research question.