---
title: "Designing a journey that actually branches"
summary: "Most 'journeys' are sequences with a delay between steps. Four decisions, made before any copy is written, turn one into something that responds to what the customer actually does."
canonical: https://cpaas.co/en/learn/designing-a-journey-that-branches
kind: use-case
depth: applied
origin: original
published: 2026-08-07T16:26:18.899Z
updated: 2026-10-14T16:26:19.510Z
topics: ["Omnichannel", "Customer Experience", "Conversational Marketing"]
language: en
---
# Designing a journey that actually branches

A journey builder makes it easy to draw a line of boxes with waits between them. That is a schedule, not a journey, and it behaves the same whether the customer is delighted, furious or already finished. The symptoms are familiar: "complete your purchase" after the purchase, a reminder after the cancellation, three teams' messages landing on one person in one afternoon. All of them come from four structural decisions that nobody made explicitly. Make them first; write the content afterwards.

## The four decisions, on one page

```diagram:matrix
# What each decision protects you from
What ends it | A journey with no exit is a subscription nobody agreed to. Success has to end it too, not just unsubscribe.
What silence means | Silence is not consent to continue. Decide whether no reply means retry, branch or stop — before launch.
Which channel per step | Set at the step, not at the journey. A reminder and a receipt do not belong on the same transport.
The frequency ceiling | Across every journey a person is in, not within this one. This is the only one that needs a global view.
> Three of these live inside the journey. The fourth cannot, and that is why it is the one that gets missed.
```

## Decision one: what ends it

Before drawing anything, define the exit conditions.

- **Positive exits:** the outcome you wanted — booked, paid, replied, resolved.
- **Negative exits:** complained, unsubscribed, asked for a human, marked as spam.
- **Neutral exits:** the journey's purpose expired (the appointment date passed, the offer ended).

Every exit must remove the person immediately and everywhere, including from steps already queued in a sending system. A journey without exits keeps messaging people who have already done the thing.

```diagram:decision
# Should this person still be in the journey?
Did they do the thing — book, pay, reply, resolve? | Positive exit |
Did they complain, unsubscribe, ask for a human, or mark it as spam? | Negative exit |
Has the journey's purpose expired — the date passed, the offer ended? | Neutral exit | Stay in, and take the next step
> Every exit removes them immediately and everywhere, including steps already queued in a sending system.
```

## Decision two: what silence means

Every wait needs at least two branches: it happened, or it did not. And "did not" is several situations:

| Silence type | What it may mean | Sensible next step |
|---|---|---|
| Not delivered | Wrong number, blocked, channel unavailable | Try another channel you hold consent for, or fix the data |
| Delivered, not read | Not now, or not this channel | Wait, then try a different channel |
| Read, no action | Not interested, or did it elsewhere | Check other systems for the outcome before sending more |

(Read receipts exist on WhatsApp and RCS, and users can switch them off; SMS has none, so "not read" is often unknowable there.)

A workable default: silence at step one changes the channel; silence at step two changes the message; silence at step three exits. Log the exit reason, so somebody can count them later.

```diagram:steps
# A workable default for silence
Silence at step one | Change the channel
Silence at step two | Change the message
Silence at step three | Exit — and log the reason, so somebody can count them
```

## Decision three: the channel for each step

The channel is a property of the step, not of the journey. A first notice and a final reminder can reasonably use different channels, because urgency changed and because you learned between them which channel this person reads. Any fallback re-checks consent for the new channel rather than assuming it — see [choosing a channel per message](/en/learn/choosing-a-channel-per-message).

## Decision four: the frequency ceiling

A rule above every journey that caps how many messages one person receives in a period, across *all* journeys and channels. It is the single control that prevents the most common failure in this field: three well-designed journeys, each reasonable alone, running on the same person at once.

```diagram:blocks
# What the ceiling needs to see
Contact record | The person, not the address. Two channels reaching the same human is still one human.
Every active journey | Including the ones another team owns. A ceiling that only sees your journeys is not a ceiling.
Sends in the window | Rolling, per person, across channels. Seven days is the usual unit and the usual argument.
Priority class | Which message wins when the ceiling is hit. A fraud alert beats a win-back, every time.
Suppression log | What was not sent, to whom, and why. Otherwise the ceiling is invisible and gets quietly raised.
Consent ledger | The ceiling is a courtesy; consent is a veto. They are different checks and both run.
> The ceiling is a shared service. Implemented inside one journey it protects nobody, because the second journey does not know about it.
```

Whoever owns the ceiling must sit above the teams that own individual journeys. If every team can raise its own cap, there is no cap. This holds whether journeys run in a dedicated journey platform, a marketing tool or your own code: whatever runs them, the ceiling must see all of them.

## A worked example

A clinic network sends appointment reminders.

1. **Step 1 (72 hours before):** WhatsApp utility template if WhatsApp consent exists, otherwise SMS. Buttons: Confirm / Reschedule.
2. **Branches:** *Confirmed* → exit (positive). *Reschedule* → hand to booking flow, exit this journey. *Not delivered* → SMS if consented. *No action after 24 hours* → step 2.
3. **Step 2 (24 hours before):** a shorter message on the other channel, if consent allows.
4. **Step 3:** none. Silence after two attempts exits with reason "no response"; the front desk sees a flag.
5. **Global rules:** a patient cancelling by phone triggers the cancellation exit through the booking system's event; the ceiling allows at most three non-urgent messages per patient per week; appointment reminders outrank marketing.

Before launch, the team set a review date three months out to check how many patients took each branch.

```diagram:timeline
# The clinic reminder, from first message to exit
72 hours before | Step 1 | WhatsApp utility template if WhatsApp consent exists, otherwise SMS — Confirm or Reschedule
24 hours later, no action | Branch | Not delivered goes to SMS if consented; no action moves to step 2
24 hours before | Step 2 | A shorter message on the other channel, if consent allows
After two attempts | Exit: "no response" | No third step; the front desk sees a flag
> Above it all: a cancellation by phone exits through the booking system's event, and no more than three non-urgent messages per patient per week.
```

## Testing it

The happy path is the one case that was designed deliberately, so it is the least useful to test.

- **Walk it as a person.** Enrol yourself on a real phone. Reply oddly, reply late, ignore one step and answer the next.
- **Test the exits.** Convert halfway and check messages stop. Unsubscribe at step two and check step three never fires.
- **Test overlap.** Put one test person in three journeys at once. That is the case the ceiling exists for.
- **Name and count every branch.** A branch nobody takes is either dead logic or a bug.

```diagram:checklist
# Tests the happy path will not run for you
[ ] Walk it as a person | A real phone; reply oddly, reply late, skip a step
[ ] Test the exits | Convert halfway; unsubscribe at step two and check step three never fires
[ ] Test overlap | One test person in three journeys at once — the case the ceiling exists for
[ ] Name and count every branch | A branch nobody takes is dead logic or a bug
```

## Give every journey an end date

Journeys outlive their reasons. Set a review or expiry date on launch day, with an owner. At review, look at branch counts, exit reasons and unsubscribes per step, and retire what no longer earns its sends.

## Where to go next

Next in this track: [the support queue as a system](/en/learn/the-support-queue-as-a-system), where many journeys end. For the consent checks every branch depends on, read [consent architecture](/en/learn/consent-architecture).

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.