Building a Multi-Branch Retention Journey

Overview

A cancellation isn't one event — it's many different customers leaving for many different reasons, and each reason deserves a different response. The customer who finds you too expensive wants a discount. The one missing a feature wants to be heard (and maybe to pause). The one switching tools might stay on a lighter plan. Answering all of them with the same "Are you sure?" leaves money on the table.

A multi-branch retention journey turns your single Cancel Plan button into a smart, branching save flow: ask why, then route each reason down its own path with a tailored save offer — a discount, a pause, a downgrade, a human hand-off — and only complete the cancellation for the customers you genuinely can't keep. Every outcome is captured with its reason, so your CRM, your churn-risk flags, and your retention analytics all learn from it.

This guide builds one end to end, with a concrete example you can adapt.

The example we'll build

Northwind, a project-management SaaS, wants to fight churn at the moment of intent. When a customer clicks Cancel Plan, instead of a plain confirmation they enter a retention journey that branches on the cancellation reason:

Customer chooses…	Branch	Save offer
"It's too expensive"	Discount path	20% off for 3 months
"I'm missing a feature"	Listen-and-pause path	Capture the request + offer a 60-day pause
"I'm switching tools"	Downgrade path	Move to the cheaper Starter plan instead of leaving
"I'm not using it enough"	Pause path	Pause the subscription for 30/60/90 days
"Other" / anything else	Graceful cancel	Confirm and cancel, reason captured

Each save path lets the customer accept the offer and stay, or continue to cancel. Everyone who does cancel passes through one shared cancellation step that records why.

                       ┌── "Too expensive"   → Discount (20% / 3 mo) ──┐
   Cancel Plan         ├── "Missing feature" → Listen + 60-day pause ──┤
   ↓                   │                                               │
   Reason step  ───────┼── "Switching"       → Downgrade to Starter ───┼──► Cancel step
   (Reasons & routing) ├── "Not using it"    → Pause 30/60/90 ─────────┤   (cancel_order,
                       └── "Other"           → (straight to) ──────────┘    reason → CRM)
                                                                  ▲
                                          "No thanks, cancel" from any branch

Before you begin

• You have a Customer Self-Service journey to use as the cancellation flow (you'll set its Purpose to Cancellation so the portal's Cancel button resolves to it).

• Your save offers exist where the journey can apply them: a discount (through your offers / pricing setup), a lower-tier plan to downgrade into, and pause enabled in your billing configuration.

• A billing integration (for example Zuora) is connected so the discount, downgrade, pause, and cancellation actually take effect downstream.

1. Create the cancellation journey

1. Go to Content → Journeys and click + New Journey.

2. Set Type to Customer Self-Service and give it a clear internal name (for example Cancellation — Retention). The name is yours to change later; the binding is the purpose, not the name.

3. On the Settings tab, set Purpose to Cancellation. This is what makes the portal's Cancel Plan button resolve to this journey — by type and purpose (and the customer's cohort), not by name. You can rename it "Win-Back 2026" tomorrow and the button still works.

Why purpose, not name: the Cancel Plan entry point looks up the journey by type + purpose. Setting the purpose is the durable binding; matching on an exact name is only a legacy fallback.

2. Build the reason step and route by reason

The reason step is the fork in the road. Add a step early in the flow whose page asks "Why are you leaving?", then configure its routing:

1. In the journey builder, expand the cancellation-reason step and click Edit reasons & routing.

2. Manage the reasons the customer can pick — add, edit, enable, or disable each one. For our example: Too expensive, Missing a feature, Switching tools, Not using it enough, and Other.

3. Set each reason's stored value. For custom reasons you control the value independently of the customer-facing label. The value is what gets stamped onto your CRM and the order's custom fields (for example CancellationReason__c), so keep it stable and reporting-friendly — for example label "It's too expensive" → value too_expensive.

4. Route by reason. Choose each reason routes to its own downstream step (rather than all reasons funneling to one). This is what makes the journey multi-branch: "too expensive" can lead to the discount step while "missing a feature" leads somewhere else entirely.

3. Build the save-offer branches

Create one downstream step per branch, each backed by its own page, and point the matching reason at it. What each branch does is a commerce action on the step (expand the step → Commerce actions):

• Discount path — present the offer ("Stay for 20% off for the next 3 months"). On accept, apply the discount to the subscription. Discounts are drawn from your offers / pricing setup, so the journey can only offer what your policy allows (see Guardrails).

• Downgrade path — offer the lower-tier Starter plan. On accept, run an update_order action that amends the subscription to the cheaper plan instead of cancelling it.

• Pause path — offer to pause for 30/60/90 days. On accept, pause the subscription rather than ending it.

• Listen-and-pause path — capture the missing-feature detail to context (and on to your CRM), acknowledge it, and offer the pause as a soft landing.

Give every branch a clear "No thanks — cancel my plan" exit that continues to the shared cancellation step, so a customer is never trapped in a save offer.

4. The shared cancellation step

All "cancel anyway" paths converge on one final step that actually ends the subscription:

• It runs a cancel_order action, which cancels the subscription through the Orders API and maps the captured reason into the cancellation record (and your CRM) — so every completed cancellation carries its CancellationReason__c for reporting and win-back.

• Because cancellation is a step with a role, PeakCommerce's own internal writes (record the order outcome, keep the contact and organization current) come along locked (🔒) and run regardless of what the billing system returns — your records stay correct either way.

Routing everyone through one cancel step (rather than a cancel_order on each branch) keeps the actual cancellation logic in a single place.

5. Guardrails: keep save offers within policy

A retention flow shouldn't be able to give away the store. Because the discount and downgrade offers resolve from your offers / pricing and policy configuration rather than being typed into the journey, the journey can only extend offers your business has approved — the policy engine is the ceiling. Set your maximum save-discount once, centrally, and every retention branch honors it. (Manage these under Settings, reached from your user menu in the bottom-left corner.)

6. Decide who sees it, and publish

• Target cohorts with profile assignments. On the Settings tab, use Profile assignments to control who enters this journey. Because the Cancel button resolves by type

  • purpose + cohort, you can run different retention journeys for different segments — for example a more generous save flow for annual/high-value customers, and the standard one for everyone else, both carrying the Cancellation purpose.

• Cancellations always start fresh. Retention journeys don't resume a stale half-finished session — each cancellation attempt begins clean, so a customer never lands mid-flow on old data.

• Preview the whole tree — walk each reason and confirm it lands on the right branch, that accepting an offer retains the subscription, and that "cancel anyway" reaches the cancel step. Then Publish.

7. Measure and iterate

The journey feeds two surfaces that close the loop:

• Churn Risk (CSR). Every customer who starts a cancellation journey raises a Churn Risk signal — the CSR Accounts table flags Medium/High risk based on the count of active cancellation-journey sessions in a lookback window, so your team can reach out to the customers most likely to leave. Tune the thresholds under Settings → Churn Risk.

• Retention analytics. The Retention tab (in Analytics) shows the cancellation funnel: cancellation attempts, how many were saved (and the overall save rate), how many were saved via discount, and the reasons behind the cancellations that completed — exactly the data you need to decide which branch to make more (or less) generous next.

Get creative — more branches worth building

The same primitives — reason routing, save offers, and a shared cancel step — support far more than the five paths above:

• Concierge hand-off — for high-value accounts, branch "switching tools" to a "Talk to us first" step that books a call or opens a support conversation instead of an offer.

• Annual switch — offer monthly customers a discounted annual plan ("commit for the year, save 2 months") as the save instead of a percentage discount.

• Roadmap opt-in — on "missing a feature," let the customer subscribe to updates on that feature and flag them for win-back when it ships.

• Pause-by-default — lead with pause rather than discount for "not using it enough," so you protect revenue without discounting it away.

• Seasonal save offer — swap the discount branch's offer seasonally (a holiday "stay" offer) by changing the offer centrally — the journey picks it up.

Tips

• Build pages first. Each branch step renders a page from Content → Pages; the step can't render without one.

• Keep reason values stable. Labels are for customers; the stored value powers your reporting and CRM — renaming a label is fine, but don't churn the value.

• Always offer an exit. Every save branch needs a clear path to cancel, or you'll frustrate customers who've truly decided.

• One cancel step. Converge all branches on a single cancel_order step so the cancellation logic and reason-mapping live in one place.

FAQ

How does the Cancel Plan button know to run this journey?

By the journey's type and purpose — a Customer Self-Service journey with Purpose = Cancellation — plus the customer's cohort via profile assignments. The journey's name doesn't matter, so you can rename it freely.

Can a save offer be larger than our policy allows?

No. Discounts and downgrade offers resolve from your central offers / policy configuration, so the journey can only present what's approved. The policy engine is the discount ceiling.

Do CSRs get the same retention flow?

Yes — build a CSR Self-Service cancellation journey with the same purpose so reps running a cancellation on a customer's behalf get the same branches and save offers. Use profile assignments to point the customer portal and the CSR portal at the right journeys.

Where do I see whether it's working?

The Retention analytics tab (save rate, saved via discount, completed cancellations, and the reasons behind them) and the Churn Risk flags on the CSR Accounts table.