Cancellation reasons: the six buckets and where they route#

Nearly every cancellation lands in one of six buckets: price, time and usage, product fit, competitor, life event, or involuntary. Per Churnkey's State of Retention 2025, built on 3 million cancellation sessions, budget limitations (32.97%) and infrequent usage (30.6%) alone cover almost two thirds of stated reasons. Each bucket is evidence of a different problem, so each routes to a different save offer - and two of the six should get no offer at all.

We have already written about which offer beats which (pause vs discount) and how many questions to ask (one, per the one-question rule). This post is the layer between those two: the taxonomy itself. What buckets exist, what a customer picking each bucket is actually telling you, and where the routing logic should send them.

Why the taxonomy comes before the offers#

The reason bucket decides everything downstream, so getting the buckets right matters more than tuning any single offer. A save flow is a router: the customer declares a problem, the flow responds with the one offer that addresses that problem. If your buckets are vague ("Not satisfied"), overlapping ("Too expensive" and "Not worth the money" as separate options), or missing, the router misfires no matter how good the offers are.

The good news is that the space of reasons is small and stable. Churnkey's dataset, Recurly's research, and every exit-survey vendor's default list converge on roughly the same handful of categories. You are not designing a taxonomy from scratch; you are adapting a known one to your store.

The six buckets and what the public data says#

The best public reason-mix data comes from Churnkey's State of Retention 2025, which aggregated 3 million cancellation sessions across 15 million subscriptions. Their labels map onto the six buckets like this:

Two caveats before you copy this table. First, Churnkey's data leans SaaS and Stripe; WooCommerce-specific reason mixes are not published anywhere we can find (our WooCommerce churn benchmarks post covers what does exist at the category level), and the early ChurnStop install cohort is far too small to fill that gap. Second, "technical issues" (4.69% in the same dataset) is a real category that routes out of the save flow entirely - to support, not to an offer. The reasoning is in the pause vs discount post, so we will not repeat it here.

Price: the bucket that lies#

A price answer is only evidence of a price problem when the customer's behavior corroborates it. Churnkey's report is blunt about this: after analyzing freeform follow-up responses at scale, they found that "budget limitations" frequently works as a repository for product frustration, disillusionment, or bad experiences. Price is the easiest thing to say. It requires no explanation, assigns no blame, and ends the conversation.

The corroboration test is usage. A customer who used the product heavily last month and picks "too expensive" is having a genuine price moment - route them to a discount or tier-down. A customer who has not logged an order, a login, or a download in eight weeks and picks "too expensive" is a fit or usage cancel wearing the price label. A discount saves that customer for a cycle or two at best.

This is why the price bucket, despite being the largest, should not automatically get the largest share of your offer budget. A third of your cancels claim price; a meaningfully smaller share mean it.

Time and usage: the most recoverable bucket#

The time bucket is the one where the customer's problem genuinely resolves on its own, which makes it the most saveable. "Too busy" and "not using it enough" describe a situation, not a verdict on the product. The subscriber still believes in the thing; the moment is wrong.

That is why this bucket routes to pause or skip-next-renewal and never to a discount. A price concession does not address a time problem, and customers notice when the response ignores what they just told you. The save-rate data behind that claim - and the sizing bands for pauses - are covered in the pause vs discount post.

One taxonomy note: keep "too busy" and "not using enough" as a single bucket. They route identically, and splitting them buys you nothing but a longer radio list.

Product fit: stop selling, start learning#

When a customer says the product did not meet expectations, the correct response is a clean cancel and a short feedback ask, not an offer. This is the counterintuitive bucket. Fit accounts for roughly one in ten stated reasons in Churnkey's data (8.63% expectations, 0.98% usability), and it is the bucket where a save offer does the most damage relative to its benefit.

Think through what a discount does here. The product already failed the customer's test. Paying 25% less for a thing that does not do the job is not a better deal; it is a smaller waste. Customers who accept anyway tend to leave within a cycle or two, now mildly annoyed that you bargained instead of listening. Meanwhile the thing you actually needed - a plain sentence about what was missing - goes uncollected.

Route fit cancels to an optional open-text field and let them go. The information is worth more than the save.

Competitor: small, and mostly a price story#

The competitor bucket is much smaller than most merchants guess: 4.28% of stated reasons in Churnkey's 3 million sessions. Merchants overestimate it because competitor losses are vivid and memorable, while "I got busy" losses are forgettable.

When it does appear, the routing question is what the competitor won on. If the free text names a cheaper alternative, this is the price bucket with a destination attached - tier-down or a targeted discount can genuinely compete. If the free text names a feature, no offer in your flow fixes that; the answer is a clean cancel and a note in your roadmap file. An optional "which one, if you don't mind?" follow-up costs nothing (it is optional, so completion is unaffected) and turns this bucket into free competitive research.

Life event: the bucket taxonomies forget#

Life events - moving house, income change, the season ending, a baby arriving - are real, common in ecommerce subscriptions, and almost invisible in public data because most reason lists do not offer the option. Churnkey's 17.85% "Other" share is the shadow this bucket casts: when a sixth of respondents pick "none of the above," part of your taxonomy is missing. We could not find a named public source that quantifies life-event cancels separately, so treat this section as reasoning rather than benchmark.

For subscription boxes and replenishment stores especially, the bucket earns its own radio option ("My situation changed"). It routes like the time bucket - pause, skip, or a frequency reduction - because the underlying problem is situational and often temporary. It should never route to a discount: the customer just told you the problem is not price, and the never-discount-a-time-problem rule applies with full force.

Involuntary: the bucket that never sees your survey#

Roughly a fifth to a third of total churn never clicks cancel at all - the card failed. Recurly's churn benchmarks (July 2026 network data) put median annual churn at 3.60%, of which 1.25 points - about a third - is involuntary. Churnkey's involuntary benchmarks, drawn from Stripe data, put the involuntary share at 23% for merchandise businesses, and as high as 35% for subscriptions under $10 a month.

None of these customers answer your exit survey, which has two consequences. First, the fix is mechanical, not persuasive: retries plus dunning email, which Churnkey's report pegs at a 42% average recovery rate for dunning campaigns. Second, your reason-mix analytics must exclude involuntary churn entirely. If your dashboard counts failed payments alongside cancels, every stated-reason percentage you compute is diluted by a population that was never asked.

Building the reason list from the taxonomy#

A WooCommerce reason list that covers the six buckets needs about seven options, one required question, and nothing else:

• Too expensive
• Not using it enough / too busy
• It wasn't what I expected
• Found a better alternative
• My situation changed
• Something is broken (routes to support)
• Other (with optional open text)

Wording matters more than it looks. Use the customer's phrasing ("Too expensive"), not accounting phrasing ("Pricing concerns"). Keep options mutually exclusive - if two options can be true at once, the data from both is mushy. And resist adding an eighth and ninth option; the one-question rule covers why every increment of survey friction costs saves. ChurnStop's default survey ships this list, with each option pre-wired to the routing below, but the taxonomy works in any flow tool.

The routing table#

The whole post compresses to one table. Print it, argue with it, then implement it:

Three checks before you ship it: your survey has exactly one required question; "something is broken" routes to a human, not an offer; and involuntary churn is measured in a separate lane from all of the above. Get the routing right and the offer-sizing debates get much smaller - most of the win is in sending the customer to the right conversation at all.