> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/customer-self-service/subscription-management/customer-retention-journey.md). # Customer Retention Journey When a customer starts a cancellation in the portal, you can present a **retention experience** instead of a plain cancel: ask why they're leaving (capturing the reason — for example to Salesforce) and offer save options such as a discount, pause, or downgrade before the cancellation completes. The customer can still choose to cancel. This is built as a **Customer Self-Service** cancellation [journey](/product/journeys-and-pages/journey-basics/journeys-overview.md): the cancel path routes through a reason step, retention/save-offer steps, and finally the cancellation. See [What you can build with journeys](/product/journeys-and-pages/journey-basics/journey-use-cases.md). ## Reasons & routing The reason step is configured with a dedicated **Reasons & routing** editor. In the journey builder, expand the cancellation-reason step and click **Edit reasons & routing**. There you can: * **Manage the reasons** customers can choose — add, edit, enable, or disable each one. * **Set each reason's value** — for custom (author-added) reasons you control the stored **value** separately from the label shown to the customer. The value is what gets stamped to your CRM and order custom fields (for example `CancellationReason__c`), so keep it stable and reporting-friendly. * **Route by reason** — choose whether **all reasons go to one step** (a single retention path) or each reason routes to its **own downstream step**, so "too expensive" can lead to a discount offer while "missing a feature" leads somewhere else. ## Save offers and discounts A retention journey can present a **discount save-offer step** — an offer card that shows the customer what they'd save by staying, with **Accept** applying the discount to their subscription on the spot. The offer itself is not hard-coded in the journey. It comes from the central **Offers catalog** (**Commerce → Offers**): the journey step references a subscription-discount offer, and the offer defines the discount's value, duration, guardrails, and the billing instrument it executes through. That separation means the team that owns pricing can tune the offer — change the percentage, tighten the caps, retarget the audience — without touching the journey, and the same offer can back several journeys. See [Offers & Discounts](/product/using-peakcommerce/products-and-bundles/offers-and-discounts.md) for how offers are defined. The offer's guardrails are enforced **at accept time, against live billing state** — not just when the card is shown: * **Per-customer usage caps** (with a lifetime or rolling-window cap basis) and **cooldowns** are checked server-side from the redemption ledger; a customer who has hit their cap sees the flow route past the offer. * **Conflict scope** re-reads the subscription's current discounts from the billing system in the last moment before the discount is written. Billing has many writers — finance, CPQ, other self-service surfaces — so this live check is what stops a second discount stacking on one that arrived between showing the offer and the customer accepting it. If the subscription can't be read, the apply fails closed rather than risking a stack. * The **re-offer window** lets the offer surface again shortly before a blocking discount is scheduled to end, so a customer nearing the end of a previous save discount can be saved again. **Trials are handled honestly.** If the customer accepts a discount while still in a free trial, the discount doesn't apply to the $0 trial period — it is parked and **activates automatically when the paid subscription begins**, and the flow shows the customer the price and the date the discount will start. The parked discount counts as active for conflict checks, so re-running the cancel flow during the trial can't stack another one. ## Allowing customers to revoke a scheduled cancellation Retention doesn't end when the customer clicks cancel. Because most cancellations take effect at a **future date**, there's a window — often the rest of the term — in which a customer who has second thoughts can simply un-cancel. Retention and cancellation journeys carry a setting for exactly this: **Allow revoking a scheduled cancellation** (**off by default**). Enabling it lights up a **Revoke Cancellation** strip on the subscription card wherever a future-dated cancellation is pending — on the **customer portal** *and* on the **agent console** subscription card, so a CSR taking a "please don't cancel me after all" call has the same one-click action the customer does. The customer-facing side of the flow (confirm dialog, eligibility checklist, blocked states) is described in [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management.md). What the setting buys you, and its built-in guardrails: * **The setting is only the first gate — a permission is the second.** Enabling the journey setting doesn't by itself put the button in front of anyone: the viewer's profile must also grant **Revoke Scheduled Cancellation** (on customer profiles) or **Revoke Customer's Scheduled Cancellation** (on CSR and sales profiles) — a three-level grant that **defaults to no access** on customer, CSR, and sales profiles alike. **View** level shows the cancellation-scheduled banner (including why a revoke is currently blocked); only **manage** level shows the Revoke button. See [portal action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions.md). * **Built-in precondition: every invoice paid.** Revoking is only offered when the account has no unpaid invoices; an outstanding balance blocks the action and shows the customer the amount due. If invoices can't be read, the action is withheld rather than guessed (fail-closed) — an unreadable billing state never counts as eligible. * **Executed in the billing system, recorded on the account.** The un-cancel is a real billing-system operation — it removes the scheduled cancellation so the subscription continues on its current terms, with **no new order and no charge** — and it is written to the account's **audit trail and timeline**, so there's always a record of who revoked what, and when. * **The window is enforced twice.** The strip only appears while the cancellation's effective date is in the future, and the billing system rejects a revoke of an already-effective cancellation at commit — so there's no race at the boundary. * **Only where supported.** The action is offered only when the billing integration supports un-cancelling; otherwise the card keeps its standard pending-cancellation banner, with or without the setting. The setting lives on the journey **bound to the cancellation purpose** — the same journey that produced the scheduled cancel — so the surface that scheduled the cancellation is the one that decides whether it can be revoked. ## Recording the cancellation When the customer does cancel, the journey's [commerce actions](/product/journeys-and-pages/journey-steps/commerce-actions.md) run a `cancel_order` action that cancels the subscription via the Orders API and **maps the captured reason into the cancellation record** (and your CRM), so every cancellation carries its reason for reporting and win-back. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/customer-self-service/subscription-management/customer-retention-journey.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.