> 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/guides/feature-guides/retain-and-manage/guide-building-a-multi-branch-retention-journey.md). # 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. --- # 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/guides/feature-guides/retain-and-manage/guide-building-a-multi-branch-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.