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 identically whether the customer is delighted or furious.
Decision one: what ends it#
Before drawing anything, define the exit condition. Usually the outcome you wanted — booked, paid, replied, resolved.
A journey without an exit condition keeps messaging people who have already done the thing. Every recipient of a "complete your purchase" message after purchasing has met a journey whose author skipped this step.
Exits should also include negative ones: complained, unsubscribed, escalated to a human. These need to remove the person immediately and everywhere, including from steps already queued.
Decision two: what silence means#
Every wait needs two branches: it happened, or it did not. And "did not" is not one thing — no delivery, no read, read but no action are three different situations that deserve three different next steps.
Collapsing them into one "no response" branch is why re-engagement messages so often feel oblivious. The system that could not tell whether the message arrived is now asking why you did not reply.
Decision three: which channel each step uses#
Not the journey — each step. An initial notice and a final reminder can reasonably use different channels, because urgency changed, and because your evidence about which channel this person actually reads improved between the two.
Make the channel a property of the step, with a fallback that re-checks consent rather than assuming it.
Decision four: the frequency ceiling#
A global rule, above the journey, that caps how many messages a person receives in a period across all journeys.
This is the single control that prevents the most common failure in this field: three well-designed journeys, each individually reasonable, running at once on the same person. Nobody designed that experience, which is exactly why it happens.
Testing it#
Walk it as a person, not a diagram. Enrol yourself, on a real handset, and go through it slowly. Reply oddly. Reply late. Ignore one and answer the next.
Then test the exits. Convert halfway through and check the messages stop. Unsubscribe at step three and check step four never fires.
Journeys fail at the exits far more often than in the middle, and the middle is where all the review attention goes.
The organisational note#
Whoever owns the frequency ceiling has to sit above the teams that own individual journeys, or the ceiling is advisory. If every team can raise its own cap, there is no cap.
The four decisions, on one page#
Everything else in a journey is content. These four are structure, and getting any of them wrong produces a journey that works in the builder and fails in production.
What each decision protects you from
A journey with no exit is a subscription nobody agreed to. Success has to end it too, not just unsubscribe.
Silence is not consent to continue. Decide whether no reply means retry, branch or stop — before launch.
Set at the step, not at the journey. A reminder and a receipt do not belong on the same transport.
Across every journey a person is in, not within this one. This is the only one that needs a global view.
Silence is the branch everyone forgets#
Most journey builders make the happy path easy and the silent path implicit. So the silent path becomes "wait 48 hours, send the next thing", which is the behaviour of a broadcast schedule wearing a decision tree's clothes.
Silence carries information and it is rarely the information you want. It might mean not now, not this channel, not you, or I already did this elsewhere. A journey that treats all four identically will keep messaging the person who already bought.
The workable default: silence at step one branches to a different channel. Silence at step two branches to a different message. Silence at step three exits. Three strikes, then stop — and log the exit reason so somebody can count them later.
The frequency ceiling has to live outside the journey#
This is the failure that only appears once you have more than two journeys, which is to say once it is expensive to fix.
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. Fraud alert beats 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.
Testing a branch#
A journey cannot be tested by walking the happy path, because the happy path is the one case that was designed deliberately.
Test the silences. Test the person who replies with something unexpected in the middle. Test the person who unsubscribes at step two and is still in the queue for step three. Test the person in three journeys at once — that is the case the ceiling exists for, and it is the case nobody has data for until production.
Give every branch a name and count how many people take it. A branch nobody takes is either dead code or a bug, and both are worth knowing about.
What to take away#
Four structural decisions, made before any content is written. Give silence an explicit meaning, put the frequency ceiling outside every journey where it can see all of them, name and count your branches, and set an expiry date the day you launch.