Channel Orchestration
Cross-channel lifecycle orchestration
Coordinate lifecycle responses across email, in-app and SMS with current customer evidence, shared stop rules and checks across sending systems.
Cross-channel lifecycle orchestration coordinates a customer's next response across email, in-app and SMS. Start with what the customer needs now: decide whether to respond, where they can act, and what change would make the response unnecessary. Every sending system must follow that decision.
Make the decision before choosing a channel
For each journey step, record the customer task, the evidence for the current state, the useful response and the stop condition. A response might be a message, a change in the product experience, a handover to a person or no action.
| Decision | Question to answer |
|---|---|
| Need | What can the customer do or resolve now? |
| Evidence | Which current record supports that need? |
| Response | Would contact help, and what should it enable? |
| Channel | Where can the customer act, and is that route appropriate and available? |
| Stop condition | What action, correction or new issue makes the response stale? |
Consider a customer arranging a service appointment. Guidance beside the booking choice may help while they are in the product; a preparation list may be more useful by email after a booking is confirmed. If the appointment changes, waiting preparation messages need review. Sending the same instruction by SMS simply because a number is available adds no value.
In Customer.io, conditions can be attached to messages, data blocks and delays, and are checked before the action starts. A condition can use a person’s attributes, event or message data, segment membership or journey attributes. This checks the state relevant to a particular response rather than treating every step as eligible by default.
For event data stored in JSON, Customer.io conditions can use dot notation to inspect nested properties and array items. An array index can target the first item, while an empty index can represent any item in the array.
Give sending systems a shared state
Decide whether each rule applies to a person, an account or a particular task. One account member's action does not always settle another member's need. Before a send, check the relevant task state, earlier messages, channel eligibility and any human handover.
Keep the time an event occurred separate from the time the messaging system received it. A late completion can invalidate a queued reminder. If the record cannot establish the state, hold a claim that depends on it or use wording that does not assert success or failure.
A useful decision record identifies the journey step, recipient or account, purpose, supporting event, expiry, chosen response and the reason for sending, skipping or replacing it. Fields can differ by organisation; the point is to make the decision traceable across systems.
Check what an event condition actually means before using it to justify a response. In Customer.io, “Event has been performed” checks whether the person has ever performed the event, including before entering the current automation; it is not limited to events recorded during that journey.
Coordinate channels and queues
In-app messages wait in a queue until the person next opens the app or website. Customer.io delivers one on the first device or browser they visit after it is sent; after receipt, it will not appear in another device or browser session unless the person re-enters the automation or the message is rebroadcast.
Email can carry instructions worth revisiting, while SMS may suit a brief, timely update. Reassess the need before switching channels: a completed task does not need its reminder resent elsewhere.
Check applicable ACMA guidance before sending commercial email or SMS.
Contact limits are a separate safeguard; see the supporting article for details. They do not determine whether two eligible messages contradict each other.
Review scheduled campaigns and sales or service queues when customer state changes. A condition that skips one workflow action does not clear a separate queue. Recheck relevant conditions close to dispatch, particularly after a delay, and decide whether a skipped step should continue, branch or end the path.
Channel Suitability for Customer Journey Stages
- In-app messagesBest during active product use; ideal for real-time guidance or prompts.
- EmailSuitable for detailed instructions or revisitable content; useful post-booking or after confirmation.
- SMSEffective for brief, time-sensitive updates; avoid if the same message has already been sent.
Review the customer path
Before release, inspect the configured systems against histories that include immediate completion, a late event, an opt-out, two active journeys and an in-app message that is never viewed. Record which response should send, expire or be handed over in each case.
After launch, review eligible customers, sends, skips, stale messages and the actions each step was meant to support. A platform's attributed conversion count does not, by itself, show that the journey caused progress. The useful measure is whether each response still had a sound reason to exist when the customer encountered it.
If a journey uses email opens or clicks to determine eligibility, Customer.io lets the condition distinguish human engagement from human and machine engagement. Choose and document the interpretation that fits the decision, so an engagement signal is not treated as a customer action without review.
Using Engagement Signals to Trigger Journeys: Pros and Cons
- Pros
- Allows timely follow-ups based on actual user interaction; improves relevance.
- Cons
- Risk of misinterpreting bot or machine engagement as genuine customer action.
In this guide
- Choosing between email, in-app and SMS for a journey stepChoose email, in-app or SMS for one lifecycle step using the customer's task, timing, permission, display conditions and fallback.
- Applying contact limits across several messaging channelsDefine shared contact limits across channels, check platform exclusions and time windows, and handle blocked or retried messages safely.
- Preventing conflicting messages from different lifecycle journeysFind contradictory lifecycle messages across journeys, recheck their assumptions at send time and resolve collisions across separate queues.
