Designing Lifecycle Journeys Around Customer State
How to build lifecycle journeys that respond to customer state, use current data and stop when the message is no longer relevant.
Max Rozmetov
CRM Systems & Automation Specialist
A lifecycle journey should respond to what is true for the customer now. Too many programmes are built around a marketing calendar, then continue sending after the customer's product, intent or eligibility has changed.
State-based design starts with observable conditions. It defines when a person enters, what can change while they wait and exactly when communication must stop.
Define states before messages
Map the business states that matter to the journey: eligible, evaluating, active, at risk, renewed, closed or ineligible.
A state needs a source, owner and timestamp. If it cannot be observed reliably, it cannot safely control messaging.
Write the allowed transitions between states. This exposes impossible combinations and clarifies whether the journey should react to an event, a current attribute or both.
Choose the right entry contract
Entry should represent a meaningful change, not simply the presence of a record in a refreshed table. Define the triggering event, required fields, duplicate handling and maximum event age.
Salesforce Journey Builder supports no re-entry, re-entry at any time and re-entry only after exit. The choice persists at journey-version level and has direct consequences for frequency and duplicate experiences.
Re-check truth after every wait
Wait activities create risk because customer state can change while the journey is paused. Before each material message, re-evaluate eligibility, consent, product state and recent actions using current contact data.
Do not assume that journey-entry data remains correct. Salesforce distinguishes journey data captured at entry from contact data that can be refreshed. Use the source that matches the decision being made.
Use exit criteria as customer protection
Exit rules should cover success, ineligibility, objection and conflicting service states. A renewal journey should stop after renewal. An acquisition journey should stop after purchase.
A cross-sell journey should stop when the customer becomes unsuitable for the offer.
Test when the platform evaluates exit criteria. In Journey Builder, exit checks occur when a contact leaves a wait activity. That timing must be reflected in the design.
Measure transitions, not message activity
The primary outcome is movement between customer states. Opens and clicks can diagnose engagement, but they do not prove that the journey changed behaviour or commercial value.
Report entry volume, state transitions, exits by reason, time to outcome and an appropriate control comparison. This makes journey optimisation about customer progress rather than adding more messages.
The standard for release
State-based journeys stay relevant because they continually test whether the customer still belongs in the experience. Their logic is explicit, their exits are deliberate and their measurement follows outcomes.
Start with the state model and transition rules. Only then decide what communication belongs between those transitions.
CRM pre-send QA questions
What is a customer lifecycle state?
It is an observable business condition that affects what the customer needs or is eligible to receive, such as evaluating, active, at risk, renewed or closed.
Should journeys use entry data or current contact data?
Use entry data for facts that must remain fixed for that journey instance. Use current contact data for decisions that should respond to changes after entry.
When should a contact exit a lifecycle journey?
Exit when the objective is achieved, eligibility ends, consent changes, a conflicting state appears or continued communication would no longer be relevant.
Related project
Anveal: pre-send governance for regulated CRM teams
See how I turned this operating problem into a working governance workflow with deterministic checks, model-assisted review and a retained report.
Read the Anveal case study →