How to build a reason-first cancel flow

A reason-first cancel flow asks why the customer is leaving before it offers anything, then offers the lever that matches the reason: a pause, a lower tier, or a one-time credit where margin allows. Stripe can show you how many cancellations had no visible save attempt. This article shows how to size the gap and design the flow.

What is a reason-first cancel flow?

It is the screen or short sequence a customer sees between clicking cancel and actually leaving. Instead of a single "are you sure?" or an immediate discount, it asks one question first: why are you cancelling? The answer decides what comes next.

The order matters. A discount shown to everyone is a price cut for people who were never going to leave, and it teaches customers to click cancel for a coupon. A question first lets you spend an offer only where it fits.

How big is the gap in my own data?

Count your voluntary cancellations over the last 365 days, then count how many show a visible save attempt. In Stripe I treat a save as visible when a discount started or collection was paused within 45 days before the cancellation. The rest are cancellations with no visible save.

In my synthetic sample, for a fictional company, 233 voluntary cancellations were counted and 207 showed no discount or pause beforehand. Those are made-up numbers, but the shape is common to the method: a large share of cancellations leave without any recorded attempt.

A caveat I always give: Stripe cannot see saves made by email, in-app messages or your support team. So "no visible save" is an upper bound. Confirm with your team how many were saved some other way before you size the problem.

Which reasons should I offer?

Keep the list short, and map each reason to one lever:

• Not using it right now: offer a pause.
• Too expensive: offer a lower tier.
• Missing something: offer to tell them what is planned, or route to support.
• Other or no answer: let them go cleanly and ask how to come back.

A one-time credit is the lever I would use last, and only where margin allows it. Stripe records the cancellation feedback value on the subscription when your flow sets it, so keep the reason list stable. If you rename the choices every month, you cannot compare periods.

How do I make sure an offer is worth giving?

By pricing it against margin before it goes out. An offer that costs more than it can win back should not be sent. I apply that check to every offer in a pilot, and I describe the arithmetic in are discount save offers worth it.

Do the same on your own. Write down, for each reason, what the lever costs you and what a saved customer is worth over the period you can count. Without that, a high save rate can still lose money.

What about customers who do not answer?

Let them go. A forced question that blocks cancellation causes anger and complaints, and the people you retain that way tend to leave again. Make the question easy to skip. Treat a skip as data: a customer who says nothing is telling you something about how much they care.

Make sure the exit works on the first try, with a clear confirmation of the end date. A good ending is the start of a win-back, which I would write as a separate sequence.

How do I know it worked?

Not by comparing this quarter to last. Seasons, price changes and customer mix also move cancellations. Split customers at random, show the new flow to one group and the old one to the other, and compare how many in each group stayed. In my pilot the control group is 20% of customers and gets nothing new.

The metric I trust is net revenue per customer, after the cost of offers and after margin. A save rate alone can hide a flow that gives away more than it keeps. See what a holdout group is for how to set it up. With fewer than about 30 events in a group, all you have is an early signal.

What does a baseline look like?

In the synthetic sample, the save rate at cancel, as visible in Stripe, is 11.2%. I use that kind of figure as a baseline in the pilot plan, and it comes with the caveat above. Your starting point is whatever your own history shows, with no benchmark attached. I do not use industry averages in the report because I cannot source them.

Is the cancel flow the first thing to fix?

Only if voluntary cancellations are the bigger leak in your data. Compare in dollars: failed payments never recovered, voluntary cancellations without a visible save, and unconverted trials, discounting the trial figure because it is potential. Start with the largest realised number you can fix cheaply. The comparison is in voluntary vs involuntary churn.

What should the flow not do?

Hide the cancel button, require a phone call, or ask the same question twice. Those add friction without adding information, and the customer who finally gets out is unlikely to return. A reason-first flow should take under a minute and end with a plain confirmation of the date access stops.

I would also avoid promising anything on the page that your team cannot deliver. If a pause is offered, the pause must actually work in your billing setup and be visible in Stripe, because that is what lets you count the save later.

Can the report show me the gap?

Yes. It lists cancellations with no visible save in dollars per month, with the fix and its mechanism. It costs $490, comes within 48 hours of my having a restricted read-only key, and changes nothing in your account.