Multi-step journeys with real waits and exits

A multi-step journey is a flow that a user enters from a trigger, moves through one step at a time by alternating sends and waits, and exits the moment they no longer belong in it. It is a real runtime, not just a diagram: the waits are real delays and the exits are real conditions checked at every step.

Most tools can draw a sequence of messages. The harder and more important part is what happens between the messages: how long a user waits, and when they should be let out early. A journey that keeps emailing someone who already converted is worse than no journey at all, so the runtime is built around the wait and the exit, not just the send.

How a user moves through a journey

A journey begins with an event trigger that drops a user into step one. From there the flow alternates sends and waits. A send goes out, a push or an email, and a wait holds the user for a set delay before the next step is evaluated. Steps run in order, so a welcome can be followed by a two-day pause, then a nudge, then another pause, for as many steps as the journey needs.

Because the wait is a first-class step, timing is something you design rather than approximate. You are spacing real messages over real hours and days, and the runtime holds each user exactly as long as you specified before moving them to the next step. Nothing is sent early to catch up, and nothing is left hanging past its delay.

Real exits, not just a finish line

The defining feature of the runtime is that a user exits the moment any exit criterion matches, not only when they reach the last step. A journey can let someone out because they:

• convert on the goal the journey was driving toward,
• enter another segment that should take priority over this flow,
• unsubscribe from the channel the journey sends on, or
• time out after a maximum duration you set.

Those criteria are checked as the user moves through, so the flow stops chasing anyone who has already done what you wanted, moved on to a different play, or asked to hear less. That is what keeps a long journey feeling considerate instead of robotic, and it is the part most sequence builders leave out.

A good journey is defined by when it lets people leave, not only by what it sends while they stay.

In-flight counts on every step

Every step shows a live in-flight count of how many users are sitting on it right now. The whole flow is visualized end to end, so you can see the shape of the population moving through it: how many are waiting, how many advanced, and how many exited and why. Nothing stalls silently, because a pile-up on one step is visible the moment it starts to form.

That visibility is what makes a long-running journey safe to leave on. You are not trusting that it works out of sight; you are watching it work. If a step is holding more people than it should, or an exit is firing more than you expected, you see it and can adjust before it becomes a problem.

A worked example

Say Fernwood Kitchen, a weeknight recipe app, wants to onboard new members. The journey welcomes them on entry, waits two days, then nudges anyone who has not finished setting up. The exit criterion is simple: completing setup removes a member immediately, so the nudge only ever reaches people who still need it.

Build a new-member onboarding journey for Fernwood Kitchen:
1. Send the welcome push on entry
2. Wait 2 days
3. Send a setup nudge by email
Exit anyone the moment they complete setup.

That short description becomes a running flow. New members enter from the trigger, the runtime spaces the two messages across two days, and the sends go out on push and email, while setup completion quietly empties the journey of everyone who is already done. What you designed as four lines runs as a living, self-clearing flow.