Churn Survey Questions: How to Turn Exit Feedback Into Product Decisions

Most "churn survey questions" posts are a list. Ask why they cancelled, offer a dropdown of reasons, count the most common one, then fix it. The list looks reasonable, and it is also how a product team ends up rebuilding a feature that two loud accounts mentioned, cutting price because "too expensive" was the top option, and shipping a win-back email to people who had already completed the job they signed up for.

A cancellation survey is a measurement instrument for a decision that is genuinely hard. Someone is leaving, usually for more than one reason, often while mildly annoyed, and seconds away from closing the tab. The question set is a compromise between what you want to know and what they will actually tell you. Whatever they tell you is a stated reason, the account of the decision they are willing to give at that moment. It is real evidence. It is not a diagnosis.

This page owns the churn and cancellation survey method itself: what to ask, how to ask it without steering the answer, how to read the responses without pretending they are prevalence or cause, and how to route what you learn into the next piece of evidence or the next Product decision. It does not own retention strategy, generic survey design, interview method, pricing decisions, roadmap triage or experiment design. Each of those is a separate job, and this page links out when the next step belongs to one of them.

A churn survey should capture the customer's stated trigger for leaving with as little bias and friction as possible. It is evidence, not proof.

A selected reason is a clue about the customer's current explanation, not a complete causal diagnosis. Product decisions should combine the response with usage, segment, account, billing and follow-up evidence before concluding what caused churn or what to build next.

Research value never justifies obstructing a legitimate cancellation. If the survey blocks exit, the friction has already corrupted the evidence you were trying to collect.

Table of contents

• The direct answer: treat exit feedback as bounded evidence
• Churn survey, cancellation survey and exit survey are not the same job
• Before the questions: the Churn Evidence Contract
• A churn reason is evidence, not root cause
• Cancellation must not be held hostage by research
• When to ask: the timing trade-off
• Design the primary question
• Question Repair Lab
• Response options: mutually useful, not MECE theater
• Single-select vs multi-select
• Open text should be optional and purposeful
• Voluntary vs involuntary churn
• Who is the respondent: user, account and logo churn
• B2B respondent routing: the canceller is not always the decision maker
• Join the response with context you already have
• Response bias and non-response bias
• The Reason-to-Evidence Matrix
• "Too expensive" is a hypothesis, not a price verdict
• "Missing feature" is not automatically roadmap input
• "No longer needed" is not always failure
• Code the open text without inventing precision
• Small-N churn data: counts before percentages
• Version the reason taxonomy
• The Churn Evidence Prioritization Ledger
• Prioritize fixes, not response counts
• Move to the next evidence method, not a reflex
• Exit feedback to evidence to decision
• The Cancellation Survey Template
• Worked case 1: B2B SaaS and missing integrations
• Worked case 2: a consumer subscription and too expensive
• Worked case 3: an episodic product and no longer needed
• Worked case 4: involuntary churn and a failed payment
• Worked case 5: the feature-request trap
• Response rate without benchmark theater
• Incentives for follow-up research
• Privacy and sensitive data in exit feedback
• AI-assisted churn coding
• Common failure modes
• Decision clinic: the situations teams actually bring
• Which owner to use next
• Frequently asked questions
• References and further reading

The direct answer: treat exit feedback as bounded evidence

A churn survey answers a narrow question well and a broad question badly. It is good at surfacing the candidate triggers, the language customers use, and the reasons a team had not thought to offer. It is bad at establishing prevalence, at proving cause, and at telling you what to build. The method that works runs the same sequence every time:

1. Name the decision the survey should inform. If no product, pricing, onboarding, support or retention decision could change based on the result, the survey is data collection theater.
2. Define the churn unit and the churn event. User churn, account churn, subscription cancellation, seat removal, downgrade and silent lapse are different events with different respondents.
3. Split voluntary from involuntary churn. A payment failure is a billing event, not a value verdict, and it does not belong in a chart of product churn reasons.
4. Ask one low-bias primary question, option to skip, plus one optional open prompt. Keep the flow non-blocking and short enough that finishing the survey is easier than abandoning it.
5. Join the response to context you already have. Plan, tenure, activation state, usage, support history, acquisition source and account size are already in your systems. Do not ask the customer to re-enter them.
6. Separate the stated reason from the mechanism. The answer is a hypothesis about why the unit left. Write down competing explanations before you act.
7. Choose the next evidence method. A cluster of "hard to use" in one platform points at a usability investigation; a cluster of "too expensive" in one plan points at a price/value question. Neither is a fix yet.
8. Prioritize on more than the response count. Prevalence, affected segment, exposure, severity, fixability, evidence quality and strategic fit decide what to do first.

The rest of this page is that sequence in detail, with the artifacts a team can copy and the failure modes to avoid. If the problem is the wider retention system and not a single evidence method, start with the retention strategy guide, which owns repeated-value definition and retention diagnosis. This page starts one step later, at the moment a unit actually leaves.

Churn survey, cancellation survey and exit survey are not the same job

The terms get used interchangeably, and the blur causes real design mistakes. The differences are about when the question fires and what you can still do with the answer.

Two traps follow from the blur. The first is treating a cancellation survey as a full churn-reason census: it only hears from the people who both cancelled and answered, which is a subset of a subset. The second is treating silent churn, the customer who simply stops using the product without cancelling, as if the cancellation survey covers it. It does not, because no cancellation event fired. Silent lapse is usually caught earlier by inactivity or engagement signals and handled by lifecycle and retention owners, not by a form that never appeared.

The practical rule:

A cancellation survey owns the stated trigger at exit. It does not own all churn reasons, and it does not replace behavioral detection of churn that never announces itself.

If you are designing an in-product survey that fires at a normal moment rather than at exit, the delivery, timing and frequency questions belong to the in-app survey owner, not here. This page is specifically about the exit/cancellation moment and how to interpret what comes out of it.

Before the questions: the Churn Evidence Contract

This is the primary artifact. A churn survey that cannot fill this in honestly usually means the decision is not yet defined, which is itself the finding. Fill it before you write a single question.

# Churn Evidence Contract

Decision this survey should inform:
[...]

Churn unit:
[User / Account / Workspace / Subscription / Logo / Other]

Churn event:
[Cancellation / Downgrade / Seat removal / Non-renewal / Silent lapse / Other]

Voluntary or involuntary (or split):
[...]

Eligible respondents:
[...]

Survey timing:
[In cancellation flow / Just after exit / Follow-up later / Other]

Primary question (one):
[...]

Response options:
- [...]

Other / open-text field:
[...]

Optional follow-up question:
[...]

Behavioral and account context joined later:
- [...]

Reason taxonomy owner:
[...]

Definition and version:
[...]

Response-quality limitations:
- [...]

Decision threshold:
[What evidence would actually change Product priority?]

Next evidence method:
[...]

Three fields do the most work. Churn unit forces the team to say whether they are surveying a person or the entity that pays. Voluntary or involuntary forces the payment-failure cases out of the product-reason chart before they contaminate it. Decision threshold forces the team to say, in advance, what would actually change. There is deliberately no confidence score, because a five-option dropdown and forty free-text replies cannot support one.

A churn reason is evidence, not root cause

Consider the single most common answer in almost every churn survey: "too expensive." The customer selected it honestly. The mistake is the inference that follows.

The selected reason is a clue about the customer's current explanation, not a complete causal diagnosis.

This does not invalidate the feedback. It tells you what kind of evidence you now hold: a candidate mechanism, in the customer's words, with a known tendency toward the socially easy answer. "Price" is easier to type than "I never got enough value to justify the cost," and both can be true at once. The method is to treat every stated reason as a hypothesis to test against behavior, segment, account and follow-up evidence, not as a verdict to implement.

This is exactly the boundary the retention strategy guide draws when it says a stated reason is evidence, not ground truth. This page owns the survey that produces that evidence; the retention owner owns what repeated value means and how to interpret loss in the wider system.

Cancellation must not be held hostage by research

The survey is only allowed to exist if it does not become a dark pattern. A cancellation flow that hides the cancel button, forces a phone call, requires a paragraph of feedback, or buries the real action under a misleading button hierarchy is not collecting better data. It is manufacturing fatigue, collecting angrier answers from the people who persist, and eroding the trust that makes any future relationship possible.

A short audit, run on your own flow:

• Can a legitimate cancellation be completed without answering anything?
• Is the cancel control visible, labelled, and free of a misleading visual hierarchy?
• Is any save offer clearly optional and clearly separable from completion?
• Does required feedback exist anywhere in the path? (If yes, remove it.)
• Would a reasonable person describe this flow as respectful?

Research value does not justify obstructing a legitimate cancellation.

Two product decisions follow. First, every survey question is optional by default; a required question increases both random answers and drop-offs, and it converts research into coercion. Second, if you run a save offer, understand that it changes what you are measuring. A discount shown before the reason question can move the reason itself, because the customer now knows a price objection may be rewarded. If learning is the goal, ask first and offer second, or split the flow deliberately and accept that you have chosen a retention tactic over a clean reading. Jurisdiction-specific cancellation rules exist and vary; follow your own legal review and do not treat this page as legal advice.

When to ask: the timing trade-off

There is no universal best moment. Each placement buys something and costs something.

A robust default for a subscription product is one optional question inside the flow, matching the moment, plus an optional follow-up invitation that the customer can accept or ignore. The follow-up is where richer context comes from; the in-flow question is where reach comes from. If your primary interest is reflective, relationship-level feedback rather than the immediate trigger, that is closer to an exit interview than a survey, and the customer interview workflow owns it.

Design the primary question

The primary question should capture a primary trigger with minimal steering. That usually means a short, neutral, single-select question with a clear "other" and a genuine opt-out.

Wording matters more than most teams expect. In a Pew Research Center experiment, when people were asked an open-ended version of "what issue mattered most in deciding your vote," 35% volunteered the economy; when the same issue was offered explicitly in a closed-ended version, 58% chose it. Offering a reason does not create it from nothing, but it reliably increases its share. That is a feature when you want comparability and a bug when you mistake the result for the public's unprompted priority.

The same body of research shows three habits worth copying:

• Order effects are real and direction-dependent. In self-administered surveys people disproportionately pick items near the top; in interviewer-administered surveys, near the end. Randomize where order carries no meaning.
• Avoid select-all-that-apply when you need a defensible primary reason. Pew's own testing found forced-choice questions tend to yield more accurate responses, especially on sensitive topics.
• Avoid agree-disagree framings. They invite acquiescence, and less-engaged respondents are more prone to agree with whatever statement is offered.

If you want the general question-writing discipline, balanced scales, double-barrelled questions, opt-outs, wording pitfalls, the survey design and bias guide owns it. This page only applies it to the exit moment, where the stakes are unusually high and the patience unusually low.

Question Repair Lab

Most bad churn questions are not badly written sentences. They embed an assumption about the answer. The repair is usually to remove the assumption and let the response options carry the structure instead.

Pricing

• Weak: "Was the product too expensive?"
• Bias risk: leads with a price frame and primes a yes; also forces a binary onto a value judgment.
• Repaired direction: "What best describes why you're cancelling today?" with price/value as one option among several.
• When open text helps: read the free-text replies to "too expensive" to hear whether it means cost, value, budget or a competitor.
• What the answer does not prove: that price is objectively too high, or that lowering it would have retained the customer.

Features

• Weak: "What feature were you missing?"
• Bias risk: assumes a capability gap caused the churn and invites a wish list.
• Repaired direction: offer "missing capability" as one reason, then ask an optional "what were you trying to accomplish?" prompt.
• When open text helps: a workflow description often reveals a discoverability or configuration problem rather than a missing feature.
• What the answer does not prove: that the feature would have retained the customer or that it is worth building.

Competitor

• Weak: "Which competitor did you choose instead?"
• Bias risk: assumes the customer switched at all, rather than stopping, pausing or finishing the job.
• Repaired direction: include "switched to another solution" as a reason, and make competitor naming an optional follow-up.
• When open text helps: competitor names and the reason for switching are a useful clue, not a strategic verdict from one response.
• What the answer does not prove: that the competitor's feature set is the cause, or that copying it would win the segment back.

Support

• Weak: "Was poor support the reason you left?"
• Bias risk: leading, and it invites blame without context.
• Repaired direction: offer "support or service issue" as a neutral option; join it later with ticket history and resolution time.
• When open text helps: a short description can separate a real service failure from a symptom of a deeper product problem.
• What the answer does not prove: that support caused the churn rather than failing to rescue it.

Usage

• Weak: "Why didn't you use the product more?"
• Bias risk: sounds accusatory and implies the customer is at fault; it also assumes low use preceded the decision.
• Repaired direction: do not ask this in the exit survey. Read usage from your own data instead.
• When open text helps: if you do ask, ask about the job: "What were you hoping to get done?"
• What the answer does not prove: that usage caused the churn; low usage can be a consequence of a problem, not the problem.

The pattern across all five: a good churn question describes the decision space neutrally, while the response options carry the taxonomy and the open prompt carries the unexpected. It never asks the customer to diagnose your product strategy.

Response options: mutually useful, not MECE theater

A churn-reason taxonomy should be understandable, reasonably exhaustive, and free of overlapping synonyms. It does not need to be philosophically perfect, and it will change as you learn. A workable starting set for a subscription product:

• I no longer need it
• I didn't get enough value from it
• It was too expensive for what I got
• It was missing something I needed
• It was difficult to use or set up
• It was unreliable or slow
• I switched to another solution
• My team, role or budget changed
• Support or service didn't meet my needs
• I'm pausing for now
• A billing or payment problem
• Privacy, security or compliance concern
• Other

Rules that keep the list useful:

• One option per idea. "Too expensive or missing features" is two reasons and destroys the count.
• Include "Other" with an open field, and treat a high "Other" share as a signal that the taxonomy is wrong, not that customers are unhelpful.
• Offer a genuine opt-out ("Prefer not to say") rather than forcing a choice.
• Do not force the customer to classify their own churn as avoidable or unavoidable. That is your analysis, not their job.
• Review the taxonomy against real free text every quarter. New reasons appear; old ones merge.

If you need a starting instrument and its scoring, the Survey Builder and Scorer includes a churn template and a quality lint; this page owns the research logic behind it, not the generic survey mechanics.

Single-select vs multi-select

Churn is usually multi-causal, which is why teams reach for multi-select. That instinct is half right and creates a different problem.

The last option is usually the best compromise, and it mirrors the survey-method evidence: forced-choice tends to be more accurate than select-all, and a single open prompt adds texture without making every reason look equally prevalent. If you do use multi-select, be explicit that the percentages describe mention rates, not the share of customers whose primary reason it was.

Open text should be optional and purposeful

Open text is where unexpected reasons, customer language, competitor names and workflow context appear. It is also where response burden, coding subjectivity and personal data all concentrate.

Pew's analysis of its own online panel is a useful calibration: closed-ended questions averaged roughly 1–2% item nonresponse, while open-ended questions averaged around 18%, ranging from about 3% to over 50%. Questions that asked for multiple sentences had higher nonresponse than questions asking for a word or phrase, and the pattern was strongest on mobile devices. That is not an argument against open text. It is an argument for keeping the ask small and not requiring it.

Practical rules:

• One broad optional prompt is usually enough: "Anything else you'd like us to know?"
• Prefer a phrase-sized prompt over a paragraph request when the survey is in the exit flow.
• Never make the open field required.
• Expect a mobile-heavy response mix and design for it.
• Follow privacy and minimisation rules (see below) because free text is where sensitive detail leaks in.

Voluntary vs involuntary churn

This split is mandatory, and it is where a lot of churn reporting quietly goes wrong.

A cancellation-reason survey is a tool for voluntary churn. Asking a customer whose card expired "why are you cancelling?" produces a meaningless answer or no answer, and mixing involuntary losses into a "top churn reasons" chart inflates product reasons with billing failures. Before any chart is built, split the populations. If a large share of loss is involuntary, the fastest lever is payment recovery, not a survey, and that recovery method is a billing operation, not a Product research job.

There is currently no dedicated CraftUp owner for involuntary-churn recovery mechanics; the diagnosis lives with the retention system and the distinction lives here. If your team owns the billing side, treat recovery as its own evidence problem. The one product-side action this page can endorse is making it easy and non-deceptive to update a payment method.

Who is the respondent: user, account and logo churn

In B2B, "churn" is not one event. A single user leaving, a champion leaving, an admin removing seats, a workspace downgrading, a company not renewing and a parent logo moving to a competitor are different events on different units.

Do not ask an end user to explain a company-level cancellation they do not have visibility into. They will guess, and their guess will enter your taxonomy as if it were a reason.

B2B respondent routing: the canceller is not always the decision maker

The person who clicks cancel is often an admin executing a decision made elsewhere. The survey should capture what that person actually knows, and then route to the right next conversation rather than pretending one respondent speaks for the account.

A reasonable approach:

• Ask the admin the primary reason and what changed at the account level.
• Keep the follow-up invitation optional and separate from cancellation completion.
• If the reason is ambiguous or high-value, route to an account conversation with the champion, buyer or finance contact, but do not spam every stakeholder.
• Join the response to account context (usage, seats, tenure, plan, support history) before drawing conclusions.

This is also why factor-heavy at-risk survey questions rarely belong in the cancellation flow. Questions such as "who else on your team relies on this" or "what would have to be true to renew" are relationship questions better asked earlier, or in a follow-up, than at the exit click.

Join the response with context you already have

The fastest way to turn a thin stated reason into usable evidence is to join it to what your systems already know. Do not ask the customer for information you can look up, that both annoys them and wastes the one question you are allowed.

Candidate context, where your privacy and data architecture allow it:

• plan and account size;
• tenure and contract dates;
• activation state and whether first value was reached;
• usage frequency and last meaningful value event;
• acquisition source and segment;
• geography and platform;
• support history and open issues;
• reliability or incident exposure;
• billing state and payment history;
• the cancel date and whether the cancellation actually completed;
• the respondent's role.

The point is not to build a dashboard. It is that "hard to use" joined to never-activated users, repeated setup errors and one platform is a much stronger signal than "hard to use" alone. It still is not causality, but it narrows the hypothesis space. Deep cross-source synthesis of several evidence streams belongs to the insight clustering owner and the triangulation method; this page joins one exit response to its own account context.

Response bias and non-response bias

The people who answer a churn survey are not a random sample of the people who churned. They are the subset who churned voluntarily, who did not bounce off the flow, and who chose to type something. That subset has a personality:

• Angrier customers may respond more, or may refuse entirely.
• Highly engaged customers often write longer comments.
• Enterprise admins answer more readily than casual users.
• Mobile users abandon long forms more often.

Survey percentages describe respondents, not automatically all churned customers.

Three practical discipline rules follow. First, always report the eligible churned population next to the response count, so nobody reads 12 answers as if they were 120. Second, where you can, compare respondents with non-respondents on the context you already hold, plan, tenure, usage, acquisition source. If they differ sharply, say so. Third, treat the response rate as context, not a target (see below), and never generalize a self-selected slice into a company-wide prevalence claim.

The Reason-to-Evidence Matrix

This is the second artifact. For each reason category, write down what would strengthen or weaken the interpretation before you act. All examples below are hypothetical.

The matrix is not a claim about universal causality. It is a forcing function: you cannot write the "evidence that would change my mind" column and still treat the survey answer as the answer.

"Too expensive" is a hypothesis, not a price verdict

Price feedback is the highest-risk misinterpretation in churn research, because the fix feels obvious and the evidence rarely supports the obvious fix alone.

"Too expensive" bundles at least four different situations: the price is genuinely misaligned with this segment; the customer never reached the value that would justify any price; the buyer changed and the new buyer has different priorities; or the customer found a cheaper alternative. Inspect usage and value received, segment, budget context, plan fit, competitor, contract timing and discount history before concluding anything. Where the mechanism is genuine price/value misalignment, the decision is a pricing decision and belongs to the pricing experiments owner; where the price is fine but the page or packaging is confusing, that is a pricing page question.

"Too expensive" is a price/value/context signal, not automatic proof that the price is objectively too high.

The wrong move is the blanket discount triggered by the top-line reason alone. It rewards the customers who least needed it, trains future customers to cancel for a discount, and leaves the actual value problem untouched.

"Missing feature" is not automatically roadmap input

A cancellation comment that says "need feature X" can represent a genuine workflow blocker, a workaround that finally broke, a discoverability problem, a sales-expectation mismatch, a procurement requirement, or one person's edge case. Before a product team commits, it should be able to answer:

• Which segment and how many accounts actually hit this?
• What is the consequence of the gap for them?
• What workaround do they use today, and what does it cost?
• How frequent is the need?
• Would the feature have retained them, or was the decision already made?
• What do non-churned users in the same segment say?

Exit feedback is a source of candidate problems, not a backlog. Route the concrete request into feature request triage with its segment and evidence attached, and keep the exit response as the provenance rather than the verdict.

"No longer needed" is not always failure

Some products solve episodic jobs. A tax product, a hiring tool, an event platform or a compliance workflow may be doing its job perfectly when the customer stops paying. "No longer needed" can mean the job completed, the season ended, the need was one-time, or the product genuinely failed, and those have very different responses.

The relevant question is not "how do we stop this churn?" It is "was this a successful completion, an expected interval, or a failure?" For successful completion, the right move may be a well-timed, non-nagging reactivation hook rather than a retention program. This connects directly to the natural-frequency and episodic-retention logic in the retention system. Turning a completed job into a retention target is a classic way to spend money making customers feel watched.

Code the open text without inventing precision

Free text is the richest and least disciplined part of the dataset. A lightweight coding workflow keeps it useful without pretending it is a statistic:

1. Read the raw responses before choosing categories; do not start from your taxonomy.
2. Create provisional codes, and allow more than one per response.
3. Keep the original quote and context attached to every code.
4. Let unexpected answers create new codes rather than forcing them into the nearest existing one.
5. Keep an explicit "unclear / insufficient detail" bucket.
6. Reconcile codes with a second reader on anything that will drive a decision; report disagreement rather than averaging it away.
7. Periodically review whether codes should merge or split, and version the change.

A theme with four mentions is four pieces of evidence, not 40% of churn. Report raw counts, keep the quotes, and reserve percentages for closed-ended questions with a known denominator.

If the volume is large and the decision is consequential, insight clustering is the owner for synthesising multiple qualitative sources with provenance and contradictions. This page's coding scheme is only as deep as the exit evidence needs to go.

Small-N churn data: counts before percentages

There is no universal minimum sample size for churn feedback, and any page that gives you one is guessing. What changes with sample size is not whether the evidence is useful but which claims it can support.

• Report raw counts alongside any percentage. "6 of 41 respondents" is more honest than "15%" once 41 becomes 12.
• Treat tiny samples as unstable, not meaningless. One enterprise logo can be economically decisive at N=1.
• Separate prevalence evidence from qualitative insight. A single vivid comment can be strategically important without telling you how common the pattern is.
• Note the segment size. "Half of churned enterprise accounts" and "half of all churned users" are different claims even when the percentage matches.

Do not wait for an arbitrary threshold before acting on a high-severity, high-exposure signal. Do not declare a pattern from three comments. Use the decision context, not a magic number.

Version the reason taxonomy

Reason codes change. Someone renames "too expensive" to "pricing/value," merges two options, or adds a new one. If that change is silent, the trend line becomes fiction, a "drop" caused by a category rename looks exactly like a product improvement.

Record, every time the taxonomy changes:

• the old taxonomy and the new one;
• the effective date;
• a mapping between old and new codes where possible;
• which historical comparisons remain valid and which do not.

The survey-method principle is blunt: if you want to measure change, do not change the measure. When a wording or option change is unavoidable, a split-ballot test, showing the old and new versions to different halves of the flow, can tell you whether the change itself shifted the answers. Without that discipline, a "missing integration" rise after an enterprise acquisition push may be a mix shift, not a product regression.

The Churn Evidence Prioritization Ledger

This is the third artifact. One row per theme, no numeric score, with the evidence state written down explicitly.

# Churn Evidence Prioritization Ledger

Theme / stated reason:
[...]

Respondent count:
[...]

Eligible churn population:
[...]

Segments concentrated:
- [...]

Revenue or strategic exposure:
[...]

Behavioral evidence:
[...]

Support or interview evidence:
[...]

Evidence quality:
[Direct / Corroborated / Mixed / Thin / Unknown]

Plausible mechanism:
[...]

Alternative explanations:
1. [...]
2. [...]

Current workaround:
[...]

Potential intervention:
[...]

Cost and reversibility:
[...]

Next evidence needed:
[...]

Decision:
[Investigate / Test / Fix / Monitor / Do not prioritize]

Revisit trigger:
[...]

The evidence quality field is the one teams skip and the one that matters most. "Thin" is a legitimate label, and a ledger full of thin rows is a map of where to research next, not a backlog of things to build. The ledger deliberately avoids a blended score, because weighting prevalence against exposure against fixability creates false precision while hiding the judgment that should be visible.

Prioritize fixes, not response counts

The most common churn response is not automatically the highest priority. It may be low-value, unavoidable, outside your target segment, involuntary, or caused by acquisition mismatch. The rarest reason may be concentrated in high-value accounts, a regulatory blocker, or a critical workflow failure.

Prioritize on the full picture:

• Prevalence among eligible churned respondents, with the denominator stated.
• Affected segment and whether it is a segment you intend to serve.
• Business and strategic exposure: revenue, logos, expansion potential.
• Severity: does it break a core workflow or merely annoy?
• Evidence quality: direct, corroborated, mixed, thin or unknown.
• Fixability: is this something the product can actually change?
• Strategic fit: does the fix serve the product you are trying to be?
• Cost and risk: including the reversibility of the intervention.

"Highest percentage wins" is not prioritization. It is counting with extra steps.

A frequent, unavoidable reason scores low on action even though it scores high on frequency. A thin, high-exposure signal scores high on investigation even though it scores low on confidence. The ledger makes both visible instead of collapsing them into one number.

Move to the next evidence method, not a reflex

The survey's job ends when it has narrowed the hypothesis space. What comes next depends on what the evidence actually shows.

Two failure modes live here: jumping to a tactic before the mechanism is named, and testing a vague hypothesis like "fix churn" with no defined population, mechanism or guardrail. A discount is a tactic; "price/value is concentrated in low-activation SMB trials" is a mechanism you can test.

Exit feedback to evidence to decision

The whole method fits in one chain. Read it left to right; each arrow is a place teams skip a step.

Cancellation event
        ↓
Concise stated reason            (one low-bias question, optional)
        ↓
Behaviour / segment / account context   (joined from systems you own)
        ↓
Competing explanations           (at least two, written down)
        ↓
Follow-up evidence               (interviews, cohorts, support data, pricing)
        ↓
Prioritization                   (prevalence x exposure x severity x evidence quality x fixability)
        ↓
Product / pricing / retention decision

Warning: the survey answer is evidence, not root cause.
The arrow from "stated reason" straight to "decision" is where churn programs fail.

The Cancellation Survey Template

Three questions is the ceiling, and two is often enough. Every field is optional; adapt the wording and options to your product rather than copying them as universal.

B2C subscription

• Primary reason (single-select, optional): "What best describes why you're cancelling today?" with the taxonomy above.
• Optional open prompt: "Anything else you'd like us to know?"
• Optional follow-up: "Would you be open to a short follow-up conversation? If so, leave an email, this is separate from the cancellation."

B2B account cancellation

• Primary reason (single-select, optional): "What best describes why the account is being cancelled today?"
• Optional context prompt: "What changed on your side, if anything?"
• Optional follow-up: "Would a short call with our team be useful? This will not affect your cancellation."

What not to do

• Do not make any field required.
• Do not add a long battery of diagnostic questions.
• Do not insert the save offer before the reason question if learning is the goal.
• Do not use the template for trial non-conversion. A trial user who never became a customer faces different questions, activation, fit and urgency, and the access-model decision framework is the closer owner for that choice.

Worked case 1: B2B SaaS and missing integrations

Situation (hypothetical). A B2B collaboration product uses a cancellation survey with "missing capability" as an option. Over a quarter, "missing integrations" becomes the top free-text theme, and leadership asks whether to build two new integrations.

Step 1, Separate the population. Split voluntary cancellations from payment failures and contract expiries. Only the voluntary set is in scope.

Step 2, Read the responses properly. The theme is chosen mostly by larger accounts. Coding shows two sub-themes: "we need integration with X to move data at all" and "we looked for X and could not find it."

Step 3, Join context. Usage data shows many of those accounts never connected any of the existing integrations, and support history shows setup blockers on the ones they tried.

Step 4, Competing explanations. (a) A genuine missing integration blocking a workflow; (b) a discoverability problem, the capability exists but is unfindable; (c) a setup failure on the existing connectors; (d) account-size mix, larger accounts simply have more integration needs.

Step 5, Follow-up evidence. Interview a handful of the larger accounts, inspect the integration setup funnel by account size, and check whether the requested connector exists under a different name.

Step 6, Decision. If discovery and setup explain most of it, the fix is onboarding and configuration, not two new connectors. If one specific integration genuinely blocks a workflow for a served segment, that becomes a candidate with real evidence behind it, routed through feature triage.

What not to conclude. That "missing integrations" is the cause of churn, or that any single free-text request is a roadmap commitment.

Worked case 2: a consumer subscription and too expensive

Situation (hypothetical). A consumer subscription sees "too expensive" as the top reason. Marketing proposes a permanent price cut; growth proposes a win-back discount.

Step 1, Split voluntary and involuntary. Exclude failed payments and refunds from the reason chart.

Step 2, Join context. The "too expensive" replies cluster in one-month-tenure users acquired through a discount channel, with low activation and low feature use. Refund requests are high in the same group.

Step 3, Competing explanations. (a) Genuine price/value misalignment; (b) an activation problem, the customer never reached the value that would justify the price; (c) wrong-channel acquisition promising more than the product delivers; (d) a seasonal or low-intent need.

Step 4, Follow-up evidence. Compare activation and retention by acquisition channel; interview a few low-activation cancellers; check whether the discount channel's cohorts ever activate at the normal rate.

Step 5, Decision. If the concentration is in a low-activation, discount-acquired cohort, the problem is acquisition and activation, not price level. A blanket discount would deepen the same pattern. A pricing change, if any, is a separate decision with its own evidence and belongs to the pricing owner.

What not to conclude. That the price is objectively too high, or that a discount would have retained the customer.

Worked case 3: an episodic product and no longer needed

Situation (hypothetical). A document and filing product's cancellation survey is dominated by "no longer needed."

Step 1, Check the unit and the cycle. For an annual-need product, monthly retention is the wrong lens, and a cancellation after the filing is a completion, not necessarily a failure.

Step 2, Join tenure and seasonality. The replies cluster at expected intervals, with high filing-completion rates and few support complaints.

Step 3, Competing explanations. (a) The job completed successfully; (b) a genuine product failure late in the workflow; (c) the customer migrated to another product; (d) price/value at renewal.

Step 4, Follow-up evidence. Prior-cycle return rate, filing completion and error rates, and a small set of interviews.

Step 5, Decision. If completion explains the pattern, the correct work is trust, data continuity and a useful next-cycle reminder, not a daily engagement program. Reactivation timing may matter more than retention here, and that lives with lifecycle owners rather than this page.

What not to conclude. That every cancellation is a preventable product failure.

Worked case 4: involuntary churn and a failed payment

Situation (hypothetical). Logo churn rises. The product team is asked to improve the value proposition. The cancellation-reason chart shows fewer responses than usual, and support tickets about failed payments have increased.

Step 1, Split the churn. Separate voluntary cancellations, card or payment failures, contract expiries and downgrades.

Step 2, Diagnose. Confirming a large involuntary share changes the entire plan. These are not value cancellations and a value survey cannot reach them.

Step 3, Evidence. Payment-failure records, dunning outcomes, card-update completion, and the usage profile of voluntary versus involuntary losses.

Step 4, Decision. Route the involuntary share to billing recovery and make card updates easy without dark patterns. Do not redesign the product to fix a payment problem, and do not read a recovered payment as proof of product value.

What not to conclude. That a "why did you cancel?" survey explains involuntary churn. It does not, because the customer did not choose to cancel.

Worked case 5: the feature-request trap

Situation (hypothetical). A single churned account writes "need CSV export" in the open field. The team adds it to the roadmap that week.

Step 1, Slow the reflex. One response is one piece of evidence. It may be a genuine workflow blocker or an edge case.

Step 2, Ask the six questions. Which segment and how many accounts hit this? What is the consequence? What workaround exists and what does it cost? How frequent is the need? Would the feature have retained them? What do non-churned users in the segment say?

Step 3, Look for corroboration. Search other churn comments, support tickets and feature requests for the same need. Check whether an export exists elsewhere in the product.

Step 4, Decision. If the pattern repeats in a served segment with real consequence, route it through feature request triage with the evidence attached. If it does not, record it and move on.

What not to conclude. That one churned account equals a roadmap commitment.

Response rate without benchmark theater

There is no universal "good" churn-survey response rate, and publishing one would be misleading. Response rates depend on placement, audience, whether the survey is required, channel, industry, sample and timing. Even where benchmarks exist, they describe contexts, not targets.

A lower response rate from a representative set of respondents is more useful than a higher rate skewed toward your most loyal users.

What matters is not hitting a number but knowing whether the respondents resemble the eligible churned population. Capture the eligible population and the response count every period. Compare respondents and non-respondents on the context you already hold. Where the difference is large, treat the percentages as descriptions of respondents and say so. Benchmarks, if you look at them at all, are context for a sanity check, never a target to chase with more friction.

Incentives for follow-up research

Incentives belong to follow-up interviews, not to the cancellation survey itself. An incentive attached to the exit form can raise response while shifting who responds and why, and it changes the meaning of the answer.

For a follow-up interview, an incentive is more defensible and has its own trade-offs: it can improve response among otherwise under-represented groups, but it can also attract participants motivated by the reward and introduce selection effects. Do not recommend incentives by default. If you use one, keep it clearly separate from the cancellation event, state what participation involves, and record it as a possible source of selection bias.

Privacy and sensitive data in exit feedback

Free text is where personal data, employer details, financial context and sometimes secrets appear, because customers write what they were not asked a clean question about.

Reasonable, non-legal guidance:

• Minimise what you collect; do not ask for sensitive detail you do not need.
• Avoid requesting details beyond the decision the survey serves.
• Control access to raw responses and the derived quotes.
• Follow your organisation's retention and privacy policy for research data.
• Treat anything shown to leadership or customers as potentially publishable, and get permission for verbatim quotes.

Do not make jurisdiction-specific legal claims here. If you need a compliance position, that is a legal and privacy decision, not a survey-design one. CraftUp's own account-deletion page is the operational owner of how account deletion differs from cancelling an app-store subscription; this page does not modify that policy.

AI-assisted churn coding

AI can help triage open-text churn responses at a scale a small team cannot read by hand: suggesting provisional codes, grouping similar comments, and flagging unusual ones. It can also create false confidence if treated as an authority.

If you use it:

• Keep the source text canonical; never let model output overwrite the customer's words.
• Require human review for any theme that will drive a decision.
• Keep the taxonomy stable and versioned; do not let the model invent and retire categories silently.
• Do not let a model assign a root cause or a "confidence" score to a customer's reason.
• Respect privacy and data-minimisation constraints; do not send sensitive text to a third party without a clear basis.

Used this way, AI is an assist to coding, not a replacement for judgment, and it does not turn a thin sample into a strong one.

Common failure modes

A diagnostic list for the moments churn-survey programs go wrong.

• Leading question. The survey tells the customer what the team wants to hear.
• Feature-request trap. Exit feedback becomes a roadmap ticket.
• Price-is-cause trap. "Too expensive" becomes an immediate blanket discount.
• Response-percentage theater. A tiny, self-selected set of respondents is generalized to all churn.
• Single-cause theater. One reason is forced onto a multi-factor decision.
• Cancellation dark pattern. Research obstructs a legitimate exit.
• Survey without context. No plan, segment, usage or account data is joined to the response.
• Taxonomy drift. Reason categories change silently and trends break.
• AI coding certainty. Model labels become ground truth.
• Tactic before mechanism. A save offer or fix launches before the mechanism is diagnosed.
• Involuntary mix. Payment failures inflate a product churn-reason chart.
• B2B actor confusion. End user, champion, buyer and admin are treated as one respondent.

Decision clinic: the situations teams actually bring

Short answers to the cases that come up most often. All examples are hypothetical.

1. "Too expensive is our top reason." Treat it as a price/value/context hypothesis. Check activation, plan fit, segment, budget and competitor before touching price. Route pricing decisions to the pricing owner.
2. "Three enterprise accounts miss a feature." Inspect workflow, account value, segment and workaround, then route through feature triage with the evidence. Do not build on three free-text lines alone.
3. "Fifteen percent chose Other." Code the free text. A high Other share usually means the taxonomy is missing a category or two.
4. "Eight responses out of 500 churned users." State the coverage limitation. Do not generalize percentages; use the responses as qualitative leads and consider a follow-up method.
5. "Our flow requires ten questions before cancelling." Fix the flow first. That is a dark pattern, and the answers are already contaminated.
6. "The cancellation reason was a failed payment." That is involuntary churn. Exclude it from the product-reason chart and route to billing recovery.
7. "One user left a workspace but the company stayed." That is user churn, not account churn. Do not read it as a lost customer.
8. "The admin says the team didn't use it." Join the statement to account usage and consider user-level follow-up. The admin may not see end-user pain.
9. "One response names competitor X." Useful clue, not a strategic verdict. Look for the pattern before reacting.
10. "A tax product keeps hearing 'no longer needed.'" Probably episodic completion. Check cyclicality before designing a retention program.
11. "The team wants multi-select for every reason." Explain the prevalence inflation. Prefer a primary reason plus an optional contributing factor.
12. "The team wants only open text." Richer context, higher burden and coding cost. Decide based on whether comparability over time matters.
13. "We want to show a discount before the survey." That may contaminate the reason. Either ask first or accept that you chose a retention tactic over a clean reading.
14. "We changed the taxonomy last month." Version it, map the old codes, and warn against comparing the new series to the old one.
15. "Hard to use is concentrated on Android." Segment and technical evidence before a generic onboarding fix.
16. "Comments contain sensitive personal detail." Minimise, restrict access, and follow your privacy policy.
17. "What response rate is good?" No universal target. Report eligible population and response count, and check whether respondents resemble non-respondents.
18. "We want AI to auto-label every reason." Keep source text canonical, validate the taxonomy, and require human review for consequential themes.

Which owner to use next

Each link below is a job transition, not a keyword. Choose the row that matches the evidence state.

• Repeated-value problem is broad, not survey-specific → retention strategy.
• You need deeper contextual narrative → customer interview questions and the full interview workflow.
• You need a runnable discussion guide → interview script generator.
• You need to synthesise themes across several sources → insight clustering helper and research triangulation.
• Feature complaints dominate → feature request triage.
• Price/value dominates → pricing experiments and the pricing page critique.
• A reason clusters in a cohort, plan or channel → cohort comparison method.
• A reason clusters at a funnel step → funnel and drop-off diagnosis.
• The data itself is untrustworthy → instrumentation and measurement contract.
• An intervention is defined and causality matters → experiment hypothesis generator and A/B test plan generator.
• The delivery and timing of a non-exit survey → in-app survey best practices.
• General question wording, scales and bias → survey design and bias.
• Broad growth orientation → the Growth topic hub and Early Stage Growth course.

Frequently asked questions

What questions should a churn survey ask?

Usually one low-bias primary-reason question, an optional open prompt, and an optional follow-up invitation. The primary question captures a comparable trigger; the open prompt captures what you did not anticipate. Everything is optional and the flow never blocks cancellation.

How many questions should a cancellation survey have?

As few as possible. One primary question is often enough; two or three is the practical ceiling. Completion beats completeness, and you can always email for more later.

Should a churn survey be required?

No. Required questions increase both random answers and drop-offs, and requiring feedback before cancellation turns research into coercion. Every field should be optional.

What churn reasons should I include?

A reasonably exhaustive, non-overlapping set covering need, value, price, capability, usability, reliability, competitor, organizational change, support, pause, billing and privacy, plus Other and a genuine opt-out. Adapt it to your product and review it against real free text every quarter.

Should churn surveys use single-select or multi-select?

Prefer a single primary reason for comparability, with an optional contributing factor and an open prompt. Multi-select captures contributing reasons but inflates every reason's apparent prevalence. Forced-choice also tends to be more accurate than select-all, especially on sensitive topics.

How do you analyze churn survey responses?

Split voluntary from involuntary churn, join each response to plan, tenure, activation, usage, segment and support context, code the open text with raw counts and quotes, write competing explanations, and take the theme into the next evidence method rather than straight to a fix.

How do you prioritize churn reasons?

On prevalence, affected segment, business and strategic exposure, severity, evidence quality, fixability, strategic fit, and cost or risk, never on the top-line percentage alone.

Is "too expensive" a pricing problem?

Not automatically. It is a price/value/context signal that may mean low value, a wrong segment, a budget change, a competitor or an activation failure. Investigate before changing price, and route pricing decisions to the pricing owner.

How do you handle open-text churn feedback?

Keep it optional and short, code it lightly with a second reader for consequential themes, preserve the source quotes, allow multiple codes, keep an unclear bucket, and never turn a handful of comments into a precise percentage.

What is the difference between voluntary and involuntary churn?

Voluntary churn is a customer choosing to leave. Involuntary churn is a payment or operational failure ending the subscription. Only voluntary churn belongs in a cancellation-reason survey, and the two should never share one churn-reason chart.

What response rate is good for a churn survey?

There is no universal target. What matters is whether respondents resemble the eligible churned population. Report the response count against the eligible population and compare respondents with non-respondents where you can.

Should I offer a discount during cancellation?

Only as a deliberate retention tactic, and be aware it can change what you measure. If learning is the goal, ask the reason first or keep the offer separate. Do not turn it into cancellation friction.

How do you survey B2B customers who churn?

Ask the person who actually knows: often the admin for the immediate reason and the champion, buyer or finance contact for the higher-level decision. Keep follow-up optional, join the response to account context, and do not ask an end user to explain a company-level decision.

References and further reading

• Pew Research Center, Writing Survey Questions. Used for open- vs closed-ended effects, response-option order effects, forced-choice vs select-all, acquiescence and social-desirability bias, and the "don't change the measure" principle.
• Pew Research Center, Why do some open-ended survey questions result in higher item nonresponse rates than others?. Used for open-ended item-nonresponse rates, requested answer length, cognitive burden and mobile effects.
• AAPOR, Best Practices for Survey Research. Used for questionnaire design, mutually exclusive and exhaustive options, option rotation, respondent burden, nonresponse risk and transparency in reporting.
• Nielsen Norman Group, Writing Good Survey Questions: 10 Best Practices. Used for question relevance, closed-ended focus, optional questions, balanced scales, opt-outs and the single optional open prompt at the end.
• Nielsen Norman Group, Deceptive Patterns in UX. Used for the cancellation-friction and dark-pattern guardrail.
• Paddle, How to build cancellation and exit surveys that reduce churn. Vendor practitioner reference used for cancellation-versus-exit timing and recovery guidance; its product claims were not reproduced as benchmarks.
• Responsly, Churn Survey: Cancellation & Exit Survey Questions. Vendor reference used for the cancellation/exit/silent-churn distinction and the "ask one question, not ten" completion principle; its conversion claims were not reproduced as benchmarks.

For the wider system this page routes into: retention strategy, cohort comparison, funnel diagnosis, instrumentation, pricing experiments, customer interviews, and the Survey Builder and Scorer.