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: the cancel path routes through a reason step, retention/save-offer steps, and finally the cancellation. See What you can build with journeys.

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 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.

Recording the cancellation

When the customer does cancel, the journey's commerce actions 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.