cancel_flow_design v1.0.0

name: "cancel_flow_design" description: "Design a subscription cancel flow that saves the right customers and lets the rest leave cleanly: an exit survey that separates price, fit, and timing reasons, a save offer ladder matched to the reason, pause and downgrade paths before the final cancel, failed payment recovery, and save rate measured at 90 days without dark patterns. Use when building, fixing, or auditing a cancellation, pause, downgrade, or dunning flow for a SaaS, media, or physical subscription."

Cancel Flow Design

Purpose

Build a cancel flow that does two jobs at once: fix the fixable reason for the people who would stay if it were fixed, and let everyone else leave in a few clicks with a clear confirmation. A flow that only does the first job becomes a maze. A flow that only does the second job gives up revenue that a skip, a pause, or a smaller plan would have kept honestly.

Separate the three kinds of leaving before designing anything. Price means the value is there but the cost is not. Fit means the product does not do what the person needs, or they never got it working. Timing means the product fits and the price is fine, but not right now: too much on hand, a break, a life change, a seasonal pattern. Each kind gets a different fix. A discount offered for a timing problem pays margin for no reason and teaches people to start a cancel when they want a deal. A pause offered for a fit problem delays a cancel by a month and returns an angrier customer.

Voluntary and involuntary leaving are separate systems. This skill covers the voluntary cancel flow in full and the failed payment flow, called dunning, as its own track. Never mix them: a person whose card failed did not choose to leave, and a person choosing to leave should never be routed into a payment retry sequence.

Workflow

1. Start with the legal floor and write it into the spec. For online subscriptions in the US, ROSCA (Restore Online Shoppers Confidence Act, 15 USC 8403) requires clear disclosure of material terms before billing, express informed consent, and a simple mechanism to stop recurring charges. The FTC reads simple as at least as easy as signup and through the same medium, per its 2021 negative option enforcement policy. The 2024 Click to Cancel rule was vacated by the Eighth Circuit on July 8, 2025 on procedural grounds, so do not cite it as live law. State automatic renewal laws add their own consent, reminder, and online cancel rules, and FTC Act Section 5 still bars deceptive design. Practical floor for the build: cancel is findable from account settings in 2 to 3 clicks, works in the same medium as signup with no required call or chat, takes effect with no further charges after the stated end date, and sends a confirmation the person can keep. Get the product counsel to confirm the jurisdictions in scope before launch.

1. Map the flow before writing copy. The full map has six stops, and a person can reach cancel from every one of them:

• Entry: a plainly labeled Cancel subscription control in account settings, with pause, skip, and plan change visible as separate controls, not hidden inside the cancel path.
• Benefits reminder: one screen showing plan, price, next charge date, end of access date if they cancel today, and the account specific things that would be lost. One click to continue.
• Exit survey: one required question, the reason list in step 3.
• Matched offer: one offer screen for the chosen reason, or no offer screen at all for reasons with no honest fix. Rules in step 4.
• Confirmation: a plain summary and two buttons of equal weight, Keep and Yes, cancel it.
• Done: on screen confirmation plus an email, with end date, no further charges statement, data and export facts, and a reactivation path. Count the clicks from entry to done for the no offer path and publish that count in the spec. If it is longer than the signup click count by more than the survey and confirmation, cut screens.

1. Build the exit survey to separate price, fit, and timing. Use 5 to 8 single select reasons, ordered by the product own cancel data, plus an optional free text field. The default set, with its bucket:

• It costs too much (price)
• I am not using it enough (fit or timing, the offer screen splits it with pause and help)
• I have too much of it or it comes too often (timing)
• I only needed it for a while or I need a break (timing)
• It is missing something I need (fit)
• Something is broken or quality dropped (fit, support)
• I switched to something else (fit, usually no save)
• Something else (read the free text weekly and promote repeated answers into reasons) Review the split monthly. Reason data is product data: a spike in price after a price rise, in too often after a cadence change, or in missing something after a competitor launch is a finding for the product team, not only a flow input. Send the reason counts, with tenure and plan, to whoever owns pricing and roadmap.

1. Match one offer to the reason, cheapest honest fix first. The ladder in references/offer-ladder.md runs from action changes with no margin cost (skip, cadence change, swap), then pause, then help, then downgrade, then a bounded discount last. Apply it like this:

• Too much or too often: skip the next cycle or slow the cadence. State the new charge amount and date.
• Need a break, not using it, life change: pause 1 to 3 months with a fixed resume date, or a setup or support offer for the not using it group.
• Costs too much: downgrade to a cheaper tier or smaller pack first, with kept and dropped features listed. Offer a bounded discount only under the gates in the ladder reference: one per account per 12 months, set size and set number of charges, full price and return date stated up front, and positive math from step 6.
• Missing something: give the honest status, shipped, in progress with no date promised, or not planned, plus a real workaround if one exists. If it is not planned, show no offer screen.
• Broken or quality: route to support from inside the flow, keep cancel available on the same screen, and credit the account only when the issue actually hit that account.
• Switched, business closed, moved, or other with no fixable reason: no offer screen. Go to confirmation. One offer screen per attempt, at most two choices on it (one action change, one price change). If the person declines, the next screen is confirmation, never a bigger offer in the same session.

1. Build pause and downgrade as real paths, not flow decorations. Pause policy, written before launch: max length, a resume date set at pause time, access during pause stated honestly (full, read only, or none, with export always available), zero billing while paused, the first charge after resume including any proration or expiring coupon, and a reminder 3 to 7 days before resume with price, date, and a cancel path. Downgrade takes effect at the point the copy states, with proration handled the way the billing system actually handles it, and no loss of the person data or history unless that loss is stated on the downgrade screen before they accept. In Stripe, test which pause the setup uses (paused subscription versus paused payment collection) because invoicing and access behave differently.

1. Run the margin math before any discount or downgrade ships. Use the bundled CLI in bin/cancel_math.py in two modes. The ladder mode compares expected contribution for stay, discount, downgrade, pause, half cadence, and cancel over an assumed retained period. The scenario mode turns a cohort read into gross save rate, durable save rate, and net value. If value per durable save is not positive, shrink the offer, narrow it to the price reason only, or drop the discount rung and keep the action changes. Record the inputs with the decision: price, gross margin, retained months assumed, offer cost per save, and where each number came from.

1. Build the failed payment track separately. Dunning, in order:

• Prevent: turn on the card account updater or network token service the processor offers, and send one pre expiry notice about 30 days before a stored card expires, with a direct update link.
• Split declines: soft declines (insufficient funds, temporary issuer problems) get timed retries, hard declines (expired card, closed account) get customer outreach first, because retrying a dead card does nothing.
• Retry on a spaced schedule instead of rapid repeats, for example 1 to 3 days after failure, then 3 to 5 days later, then 5 to 7 days after that, inside card network retry limits. Treat the spacing as a starting point to test.
• Notify in parallel: email within hours of the failure, in app notice for active users, with what happened, the grace end date, and one update link. Use the copy in references/flow-copy.md. The tone is practical, because the person did nothing wrong.
• Grace and cutoff: keep access through a stated grace period, move to read only before a hard cutoff where the product allows it, confirm restoration in writing when payment succeeds, and close with a clean paused or canceled for failed payment state plus a reactivation link. Report dunning recovery on its own line: failed payments recovered divided by failed payments, split by soft and hard declines. Never add recovered payments into the cancel flow save rate.

1. Measure durable saves, not applause metrics. Lock the definitions in references/offer-ladder.md before launch: attempt, save at 7 days, durable save at 90 days, gross save rate, durable save rate as the headline, fake save share, and pause resume rate. Run bin/cancel_math.py on a fixed cadence, weekly for high volume and monthly otherwise, segmented by reason, tenure, and plan. If volume allows, keep a 10 percent holdout on a survey only direct cancel path and compare durable saves, so the flow gets credit only for saves it caused. Pre write kill and shrink rules: a discount rung with high take up and near zero durable saves comes out, a rise in repeat cancel attempts per account after discounts means the gates are too loose, and any rise in complaints or time to cancel triggers a flow simplification before any new test.

1. Test the finished flow like a customer who wants to leave. Complete a cancel on a test account on each plan and each platform the product sells on, time it, and check: the entry control is findable without search or support, every offer screen shows Continue to cancel at equal weight, confirmation states the end date and no further charges, the confirmation email arrives, billing actually stops, access ends or continues exactly as stated, reactivation works, and a pause resumes on its date with its reminder sent. Then test the unhappy paths: declining every offer, canceling during a pause, downgrading then canceling, and a failed payment during a pause. Log defects against the step that owns them and retest after the fix.

Output Contract

A completed build or audit delivers:

• A flow map: every screen from entry to done, the click count for the no offer path, which reasons get an offer screen and which go straight to confirmation, and where pause, downgrade, and support sit as standalone account controls.
• The survey: the exact reason list with its price, fit, and timing bucket for each reason, the ordering source (the product own data), and where reason counts are reported and how often.
• The offer ladder sheet: the matched offer per reason, eligibility gates for any discount including the per account frequency cap, pause policy in full, and the bin/cancel_math.py output that justifies each paid offer.
• The copy set: one written screen per step, following references/flow-copy.md, with exact prices, dates, and access consequences filled in for the real plans, plus the done email and the dunning sequence.
• A measurement plan: locked definitions, holdout design if used, reporting cadence, segment cuts, guardrail metrics, and kill or shrink criteria written in advance.

Operating Rules

• No dark patterns, ever. A dark pattern is design that deceives, steers, or manipulates a person into behavior that profits the service against their intent. In a cancel flow that means, specifically: no hidden or renamed cancel control, no required call or chat when signup needed none, no guilt or shame copy, no confirmshaming button labels, no pre selected Keep option, no unequal button weight that buries cancel, no fake urgency or fake expiring offers, no second larger discount after a no in the same session, and no cancel path that restarts or loops. The FTC roach motel cases, easy in and hard out, are the failure mode this list exists to prevent.
• Cancel stays available on every screen, including offer and support screens. An offer is an option next to cancel, never a gate in front of it.
• Every price, date, and consequence in the flow must be true and enforced by the billing system: discount size and duration, full price return date, pause resume date, end of access date, and what data is kept or deleted. If the system cannot enforce it, the copy cannot promise it.
• Never invent a roadmap date, a retention statistic, a review count, or a scarcity claim to hold an account. For a missing feature, not planned is an acceptable answer and it ends the pitch.
• Paused is not saved. Count a pause as retained only after it resumes and pays once, and report pause take up and resume rate separately.
• Keep the confirmation. Every completed cancel gets an on screen confirmation and an email with the end date and the no further charges statement, whether or not an offer was shown.
• Report results honestly, including flat durable save rates and high fake save shares. A flow that delays churn without fixing reasons gets simplified and its discount rung cut, not expanded with more screens.