Cancellation Reason Taxonomy: Codes & Routing

Most cancellation data is useless because it was never coded. A subscriber picks "Other," types "too expensive I guess," and that answer gets filed next to someone who moved house, someone whose card failed three times, and someone who never wanted the subscription in the first place. You cannot route what you cannot name. This cancellation reason taxonomy gives you a fixed set of codes — fourteen of them — with a definition, the exact phrasing subscribers use, and a single route for each code: a save offer, a product fix, a billing fix, or a clean exit. Copy the table into your cancel flow, your exit survey, and your support tooling, and every cancellation from that day forward lands in a bucket you can act on.

Pair this taxonomy with a well-built question set. If you have not standardised your questions yet, start with our exit survey questions and map every answer option to one code below — never the other way round. The taxonomy comes first; the survey is just how you collect it.

How the routing works

Every code routes to exactly one of four destinations. That discipline is the whole point: if a code can route to two places, your team will argue about it while the subscriber leaves.

• Save offer. The subscriber has a fixable, time-bound problem and the right offer — Discount, Pause, or Service help — can keep them. Route to your offer logic, not to a generic discount.
• Product team. The reason is about the product itself: a missing feature, a quality problem, a fit problem. No offer fixes this today. Log it, tag it, and let the subscriber go cleanly so the data stays honest.
• Billing fix. The reason is about money movement, not value: a failed card, a confusing charge, a duplicate, a price they did not expect. Fix the payment path first. Discounting a billing problem teaches the wrong lesson.
• Clean exit. The need is gone or the circumstance is permanent. Do not pitch. Confirm the cancellation, state what happens to their data and access, and leave the door open for a later return.

Match the offer to the code using the cancel save offer matrix — that page holds the offer-by-reason grid. This page holds the codes themselves, so the two never drift apart.

The taxonomy: 14 reason codes

Use the code exactly as written in your CRM, helpdesk, and billing platform. One code, one spelling, everywhere.

Code	Definition	Example phrasing from the subscriber	Route
PRICE-VALUE	Price feels too high for the value received. They like the product; the maths does not work for them.	"It's just too expensive for what I get."	Save offer — Discount
PRICE-SHOCK	Price changed, renewed at a higher rate, or a trial converted at a price they did not expect.	"I didn't know it would renew at this price."	Billing fix, then Save offer if the charge itself was unclear
NOT-USING	They have access but barely use it. No complaint about quality — usage never became a habit.	"I never really got round to using it."	Save offer — Pause, or Service help to get set up
NEED-ENDED	The job the subscription did is finished: project done, season over, goal reached.	"I don't need this anymore, it did the job."	Clean exit
TIMING-LIFE	Temporary life pressure: moving, illness, job change, new baby, tight month. Value is not in dispute.	"Life is a bit much right now, maybe later."	Save offer — Pause
FEATURE-GAP	A specific missing feature or integration blocks their use case.	"If it connected to my other tool I'd stay."	Product team
QUALITY-BUG	Defects, outages, slow performance, or broken core flows drove the decision.	"It kept failing when I needed it."	Product team, plus Service help if the issue is still open
SERVICE-FAIL	Support was slow, unhelpful, or unreachable at a moment that mattered.	"Nobody got back to me for a week."	Save offer — Service recovery by a human, not a discount
SWITCHED	They moved to a competitor or an in-house alternative and name it, or describe its edge.	"We moved everything onto one other platform."	Product team (log the competitor and the stated reason)
DUPLICATE	They hold two subscriptions that overlap — two seats, two plans, or a household duplicate.	"Turns out we were paying for this twice."	Billing fix — merge or cancel the duplicate only
PAY-FAILED	They believe they cancelled, but the record shows repeated failed payments. This is involuntary churn wearing a voluntary label.	"My card kept declining so I just let it lapse."	Billing fix — card update first, never discount first
PAY-CONFUSION	They do not recognise the charge, the descriptor, or the billing date, and cancelled defensively.	"I didn't recognise this on my statement."	Billing fix — explain the descriptor and date in plain words
POLICY-TRUST	They object to terms, auto-renewal, cancellation friction, or how their data is handled.	"I don't like being locked into auto-renew."	Clean exit, and flag the policy wording to the product team
OTHER-CODED	Free text that does not fit any code above. Must be reviewed by a human weekly and re-coded or used to propose a new code.	Anything that does not match the rows above.	Clean exit by default until re-coded

Two codes deserve a warning. PAY-FAILED is the one most teams miss, because the subscriber often never sees a cancel flow — the subscription simply lapses. Recurly research estimates that 20–40% of subscriber churn is involuntary, and Churnkey analysis of Stripe data found insufficient funds alone accounts for 40.6% of failed payments across 5.4M failures. Without billing codes, that entire population gets mislabelled as people who did not want your product. And OTHER-CODED should stay small: if more than about one cancellation in ten lands there, your codes are missing something real — read the free text and fix the taxonomy.

Tagging rules your team can actually follow

1. One primary code per cancellation. A subscriber can mention price and a bug. Pick the reason they name first, or the one they say decided it. Secondary notes go in free text, never as a second code — double-coding destroys the rollup.
2. Code what they said, not what you think. If they say PRICE-VALUE, do not re-code it as NOT-USING because their login count was low. The taxonomy records the stated reason; usage data is a separate analysis.
3. The subscriber's own words are preserved. Store the verbatim phrase alongside the code. Codes give you counts; verbatims give you the next product decision.
4. Payment failures get checked before coding. Before any agent codes a cancellation, they check the payment history. Two or more failed attempts in the final cycle means PAY-FAILED or PAY-CONFUSION gets considered first.
5. Never coach the answer. Do not reorder options to push people toward a code with a better save offer — a gamed survey produces numbers that mean nothing.
6. New codes need a definition and a route. Propose a new code only with a written definition, three real example phrases, and its single route. One owner approves taxonomy changes, and the change is dated.

The monthly rollup format

Once a month, produce one page — not a dashboard dump — in this exact shape.

Rollup row	What to record	Decision it drives
Total cancellations by code	Count and share for each of the 14 codes	Where the month's losses actually came from
Save attempts and saves by code	Offers shown, offers accepted, still active 30 days later	Which offers earn their cost, code by code
Billing-fix outcomes	PAY-FAILED and PAY-CONFUSION cases where the card or explanation fixed it	Whether billing fixes beat discounts for the same people
Top 10 verbatims	The ten most repeated exact phrases, unedited	Product and copy priorities in the subscriber's own language
OTHER-CODED audit	Every OTHER-CODED entry, re-coded or flagged for a taxonomy change	Keeps the catch-all bucket from swallowing the signal
Movement vs last month	Codes up or down, with one sentence on why you believe it moved	Stops the team reacting to noise as if it were a trend

Before you act on the rollup, size the money. Run your volumes through the recovery calculator to put a revenue figure next to the billing codes, and compare your split against the failed payment recovery benchmarks to see whether your involuntary share is normal for your price point or a fixable outlier.

Where teams go wrong with taxonomies

Three failure modes repeat. Too many codes: thirty codes feels thorough and codes nothing — agents guess under time pressure and the same reason lands in four buckets. Boardroom labels: a subscriber choosing an answer needs their own words — "Too expensive," "I'm not using it," "My payment kept failing" — with the code sitting behind the label. No owner: without one owner and one change log, every team edits its own copy and within a quarter you have three taxonomies that cannot be merged.

The bottom line

A cancellation reason taxonomy is not paperwork. It is the routing layer between a subscriber saying they want to leave and your business doing the one right thing — the matched offer, the product fix, the billing fix, or a clean, respectful exit. Ship the fourteen codes, enforce one primary code per cancellation, check payment history before coding, and read the rollup monthly. The businesses that fix churn fastest are not the ones with the most exit data; they are the ones whose exit data is coded tightly enough to act on. If billing codes like PAY-FAILED are a visible share of your losses, the next step is to fix the recovery behind them — see how flat, all-in recovery pricing works on our pricing page.

Frequently asked questions

How many cancellation reason codes should we have?

Fourteen codes, as set out in this taxonomy, is a workable maximum for most subscription businesses. Fewer than about eight usually merges distinct problems that need different routes, such as price and payment failure. More than fifteen and subscribers and agents both start guessing, which quietly corrupts the data.

Should subscribers see the codes themselves?

No. Subscribers should see short labels in their own plain language, such as Too expensive or My payment kept failing. The code sits behind the label in your systems so reporting stays consistent even if you reword a label later.

What do we do when a subscriber gives two reasons?

Record one primary code — the reason they name first or say decided it — and keep the second reason in the free-text notes. One primary code per cancellation keeps the monthly rollup countable and stops the same cancellation being counted twice.

How is a payment failure different from a voluntary cancellation?

A voluntary cancellation is a decision: the subscriber chose to leave. A payment failure means the subscription lapsed because a charge did not go through, often without the subscriber deciding anything. Code those cases as PAY-FAILED so they route to a card update and billing fix rather than a discount or a product review.

How often should the taxonomy itself change?

Review it monthly through the OTHER-CODED audit, but change it rarely — ideally only when a repeated, real reason clearly fits no existing code. Every change needs a written definition, example phrasing, a single route, and a dated note so historical data can still be interpreted.