Cancellation flow best practices: save customers without tricks

In short: A good cancellation flow asks one question, shows one offer that answers that reason, and keeps the cancel button on screen the whole time. Pause, downgrade and help are the three offers worth building. Anything that hides, delays or shames the cancel is a deceptive pattern, and both the FTC and the app stores have written that down.

What is a cancellation flow for?

The cancel is the last conversation you will have with a paying merchant. It has two jobs. Learn why they are leaving, in their words. Offer one honest alternative, once. It does not have a third job. A flow built to stop people leaving will do that for a month and then show up in your reviews.

For a Shopify app, part of the flow is out of your hands. A merchant can uninstall from the Shopify admin without opening your app, and Shopify's own reason prompt is the only survey they see. I cover that path in the guide on reducing Shopify app uninstalls. What you control is the cancel or downgrade button on your app's plan page, which is where merchants who want to keep the app but stop paying will go. For a TikTok Shop seller tool or anything billed through Stripe, you own the whole thing.

What should the reason survey ask?

One question, six or seven options, one optional text box. That is the whole survey. For an e-commerce app the reasons look like this:

• Too expensive for what I get
• Not using it enough right now
• Missing a feature I need (which one?)
• Switching to another tool (which one?)
• Closing or pausing my store
• Something is not working
• Other

Three rules for the list. Put "Closing or pausing my store" on it, because seasonal merchants and closures are common in e-commerce and no save offer applies to them. Put a text box next to "missing a feature" and "switching", because those answers are useless without the detail. Randomise the order of everything except "Other", which stays last, so the top option does not win by position.

I would make the multiple choice required and the text optional. One click is a fair ask. A paragraph is not, and a required paragraph is the first step towards a trap.

One save offer per reason

The survey answer picks the offer. Each reason gets one, shown once, with the cancel button still on screen. If the merchant declines, the cancel completes. There is no second offer.

Reason	Offer	Why this one
Too expensive	Downgrade to a smaller plan that keeps their data and settings	A discount on the same plan teaches merchants that cancelling is how you get a discount
Not using it enough	Pause for one to three months, no charge, nothing deleted	Most "not using it" merchants are between seasons or campaigns, not done with you
Missing a feature	Check if it exists. If it does, show them where. If not, say so and offer to tell them when it ships	Half the time the feature exists under another name. The other half, a false promise costs more than the merchant
Something is not working	A named person replies within hours, with the ticket already open	Technical cancels are the most saveable and the most time-sensitive
Switching to another tool	No offer. Ask which tool, then let them go	They have decided. The answer is competitive research you would otherwise pay for
Closing or pausing my store	No offer. Tell them how long their data is kept and how to come back	The only right response to a store closing is to be easy to leave

Pause and downgrade do most of the work, and both need the product to support them. A pause is a free plan with data retained and billing stopped. A downgrade needs a smaller plan that is a real option, which is a pricing question as much as a cancel flow question, and I cover it in the guide on Shopify app pricing plans.

What counts as a dark pattern in a cancellation flow?

Nielsen Norman Group defines a deceptive pattern as a design pattern that prompts users to take an action that benefits the company employing it, by deceiving, misdirecting, shaming or obstructing the user. The same article names obstruction, making it difficult to make a choice that does not benefit the company, and confirmshaming, the decline button worded to make the user feel bad for saying no.

In a cancel flow, that looks like:

• A cancel button that is grey text, below the fold, or in a submenu while the offer is a large coloured button
• "Contact support to cancel", with support that takes two days
• A decline button that reads "No thanks, I don't want to save money"
• Three or more screens between the first click and the confirmation
• The save offer pre-selected, so a fast click accepts it
• A required reason list with no "Other"
• "Your cancellation will be processed within 5 business days"

Regulators and app stores have both drawn this line, though the legal position in the US has moved. The FTC announced its click-to-cancel rule on October 16, 2024, which would have required sellers to make it as easy for consumers to cancel as it was to sign up. The Eighth Circuit vacated that rule on July 8, 2025, in Custom Communications v. FTC, because the Commission skipped a required preliminary regulatory analysis. The court said it did "not endorse the use of unfair and deceptive practices in negative option marketing" and vacated on procedure, not on the merits. The FTC's Negative Option Rule page now lists an advance notice of proposed rulemaking dated March 13, 2026 seeking comment on amendments, so a new version is in progress. I am not a lawyer, so check with one before relying on any of this. But the design standard the FTC described, cancel as easily as you signed up, is the one to build to whatever the rule says this year.

On the app store side, Shopify's Built for Shopify requirements state that "Deceptive or manipulative practices erode merchant trust in your app and in Shopify", and that the design of your app "should not result in merchants feeling confused, stressed, or misled". A cancel flow that traps merchants is a cheap way to lose that status.

Keep the cancel button visible

The layout rule is simple. The cancel button appears on every screen of the flow, in the same position, at the same size as the offer button. The offer can have the colour. The cancel keeps its size, its label and its place. The label says "Cancel subscription", not "I'll pass".

The confirmation screen states three things: the date the plan ends, what happens to their data and when, and how to come back. Then one email saying the same. That is the whole flow. Two screens, three if the reason has a text box.

How do you measure save rate?

Instrument five events: flow started, reason selected, offer shown, offer accepted, cancel completed. Then compute two numbers.

Save rate is offers accepted divided by flows started. It is the number everyone reports and it flatters you, because a pause that turns into a cancel next month counted as a save.

Net save rate is offers accepted where the merchant is still paying 60 days later, divided by flows started. This is the number to run the flow on. If it sits far below the raw save rate, your offer is delaying cancels, not preventing them.

Alongside those, watch the reason mix month by month, the acceptance rate per reason (a downgrade nobody takes means the smaller plan is wrong), and the count of support tickets asking how to cancel. If that last number rises after a redesign, you hid the button. I do not have a save rate benchmark I would trust, so compare your own months.

What to do after the cancel

Send the confirmation email within a minute, with the end date, the data retention window and a one-click way back. Export their data if they ask, without a call. Do not start a discount drip.

Then read the free text every week, tag it, and send the counts to whoever owns the roadmap. The "missing a feature" answers are a list of merchants to email on the day that feature ships, which is the only win-back email with a decent chance of working. The guide on turning feature requests into a roadmap covers how to weigh those requests against usage data.

Where to start

1. Walk your current cancel path as a merchant and count the screens and clicks from the first click to the confirmation.
2. Write the reason list with six options and a text box on two of them, and ship it as a required single click.
3. Build pause and downgrade as real plan states that keep data, then map each reason to one offer.
4. Instrument the five events and set up a monthly report with raw and 60-day net save rate by reason.
5. Put the free text in front of the product team every week.