> ## Documentation Index > Fetch the complete documentation index at: https://juo.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Designing a cancellation flow that saves subscribers > Why subscribers cancel, which alternative fits each reason, and how to tell whether your flow saves subscriptions or only delays churn. | | | | - | - | | **Who it's for** | Any subscription brand that lets subscribers cancel online | | **Goal** | Understand why subscribers cancel and keep the ones you can serve better on different terms | | **Primary metric** | Save rate: the share of cancellation attempts that end with the subscription kept | | **Supporting metrics** | Cancellation reasons, retention of saved subscriptions 2–3 cycles later, cost per save | > [!TIP] > > **Start from a blueprint.** The **Cancel flow** blueprint sets up this flow as a ready-made workflow. In Juo, go to **Workflows**, create a workflow and choose **Cancel flow**, complete its to-dos and publish. To give subscribers a way to delay from the renewal email, add the **Delay order from email** blueprint too. See [Blueprints](https://juo.io/docs/workflows/blueprints.md). ## Why it matters Many cancellations are not a rejection of the product. Subscribers leave because they have too much stock, the price feels high this month, the timing is wrong, or they never built the habit. Each of these has a better answer than canceling: a delay, a different frequency, a different product, or a one-off incentive. A cancellation flow matches the answer to the reason. It also records the reason for every attempt, which shows where your product, pricing, or delivery cadence is losing subscribers. The revenue effect is direct. Each saved subscription adds at least one more paid cycle, and subscribers who move to a frequency or product that fits them tend to stay longer than those kept with a discount alone. ## The strategy A good cancellation flow has four steps: 1. **Remind them of the value.** Show what the subscription gives them: savings, convenience, results. Keep it short. 2. **Ask for the reason.** Offer four to six options. Each reason gets its own response. 3. **Offer the alternative that fits the reason.** 4. **Confirm the outcome.** Confirm the change for saved subscriptions. If every offer is declined, cancel the subscription. ### Match the offer to the reason | Reason | First offer | If declined | | - | - | - | | Too much product | Delay the next order | Change the delivery frequency | | Too expensive | A limited discount, if they haven't had one | A pause | | Not seeing results or not using it | Usage guidance | A product swap | | Other | Ask for open feedback | Cancel | ### Decisions to make * **Which reasons to list.** Use the reasons your support team hears most. Long lists lower completion. Review the "Other" answers monthly and promote recurring ones to their own option. * **How big the discount is.** Start with a modest discount limited to one or two orders. A permanent discount saves the subscription but lowers the value of every future order. * **New vs long-term subscribers.** New subscribers usually need help using the product. Long-term subscribers more often need a different cadence. Give each group its own path. * **Product-specific paths.** A flagship or newly launched product can have its own content and questions. ### Guardrails * **One discount per customer.** Otherwise subscribers learn to start a cancellation to collect a discount. * **No more than two offers per reason.** More feels like an obstacle and leads to complaints and chargebacks. * **Always allow cancellation.** Every path ends with a way out. Hiding it hurts trust and can conflict with consumer protection rules in your markets. ## Examples * **Coffee or consumables.** "Too much product" is usually the top reason. A delay or a lower frequency saves most of these without any discount. * **Supplements or skincare.** "Not seeing results" is common in the first orders. Usage guidance and a swap to a different product work better than a discount. * **Boxes and curated subscriptions.** "Too expensive" and "didn't like the last box" dominate. Offer a skip or a pause before a discount. ## How to measure it * **Save rate**, overall and per reason. A reason with a low save rate needs a different offer. * **Retention of saved subscriptions** two to three cycles later. If most saved subscriptions cancel at the next renewal, the offer delays churn instead of preventing it. * **Cost per save**: the discount value and free products given, compared with the revenue from the extra orders. * **Test before you roll out.** Compare two offers on a share of subscribers before you give one to everyone. ## How to do this in Juo 1. **Create the workflow.** Start from the **Cancel flow** blueprint, or build your own workflow with the **Subscription cancellation requested** trigger. Only one workflow per trigger can be published, so extend an existing cancellation workflow instead of adding a second one. 2. **Match it to your store.** Replace the value reminder with your own benefits, keep four to six reasons and set a small discount limited to one or two orders. 3. **Branch where it helps.** Give new subscribers their own path with `subscription.cycle_count`, or a flagship product its own content. See [Conditions](https://juo.io/docs/workflows/conditions.md). 4. **Test it.** Open the Customer Portal as a test subscriber, select **Cancel** and go through every reason. Each path should end with a way to cancel. 5. **Publish and measure.** A published cancellation workflow replaces the legacy cancellation poll in [Retention settings](https://juo.io/docs/retention-flow.md#cancellation-flow). Review reasons in [Analytics](https://juo.io/docs/analytics.md), and compare offers with an [experiment](https://juo.io/docs/workflows/experiments.md). ## Related guides * [Fight new subscriber churn](https://juo.io/docs/new-subscriber-churn.md) * [Win back canceled subscribers](https://juo.io/docs/win-back.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.