Build the next step around what the customer does.
24 building blocks a business team uses without engineering. Every run explained afterwards.
A journey listens before it speaks again.
A drip sequence sends message two because message one went out. A journey sends message two because of what the customer did with message one, or didn't.
Every node either acts, waits, asks or decides. The graph is the whole logic. Nothing is hidden in code, and nothing needs a release to change.
Three ways to start
A behavioural event as it happens. Membership of a segment. Or an API call from your own system, so a decision that lives in core banking or a fraud model can start a journey it never has to see.
- An event, the moment it arrives
- Entering or leaving a segment
- A call from a system that keeps its own rule
Listen for the customer, and plan for silence
Wait for a WhatsApp button tap, an SMS reply, a keypad press on a call, or a message being read. A branch per response, a deadline per branch, and an explicit path for no response at all.
A journey that handles only the customer who replies will strand everyone who doesn't.
- Four kinds of response, one wait
- A deadline on every wait
- Silence is a branch, not a gap
Wait for the right moment. Branch on what actually happened.
Wait a fixed period, or hold until a date your data supplies: a payment due date, a document expiry, a resume time a core system returned. Ask whether the customer converted within a window, matched by order, session or user, before crediting the message. Split up to five ways and compare inside the journey.
Check before you continue
Call any system with a REST API mid-journey: check a balance before offering a top-up, read a risk score before releasing a confirmation, write the outcome back. The rule stays in the system that owns it.
- If it speaks HTTP and accepts one of four common authentication schemes, it works on day one
- Branch on any field in the response
- Timeouts and failures are branches too
Build large journeys from small ones
Call one journey from another. Identity verification built once and used in onboarding, high-value transactions and password resets. A rule change lands everywhere at once.
Check and record per-channel opt-in as journey steps, where a reviewer can see them.
- Sub-journeys return a result the parent branches on
- Per-channel opt-in read and written in the graph
- 24 node types; no release to add a step
Every step knows what the journey has already learned.
A journey isn’t a list of messages. It carries a memory. The event that started it, who the customer is, the key they pressed, the button they tapped, the answer your own system gave: each becomes something every later step can use. A message three steps in can quote the balance your system returned at step one. A wait can last exactly until the due date your system supplied. A branch can decide on what the customer actually said, not on a timer. And when a journey starts from a session, it begins knowing what the customer was doing, not just that something happened.
Why did this customer receive this?
Every run is recorded node by node, with the values each decision was made on. A journey paused on a reply or an API response is visibly waiting, not silently absent.
- The value at every branch, as it was at the time
- Waiting runs are listed, with what they wait for
- Answerable by support, without engineering