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.

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.

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

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

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.

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.

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

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.

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.

Next in this track: the support queue as a system, where many journeys end. For the consent checks every branch depends on, read consent architecture.