Onboarding Journeys
Part of Customer events and lifecycle segmentation
Handling customers who move backwards in a journey
Handle reversals and corrected events by preserving history, updating current state and reviewing queued journey messages.
When a customer appears to move backwards, determine whether their situation changed or the data was corrected. Preserve genuine history, update the current state and review messages waiting on the old state. A stage field that only moves forward can leave a customer receiving guidance that no longer fits.
Identify what changed
| Situation | Preserve | Reconsider |
|---|---|---|
| A completed task is reopened | Completion and reopening records | The customer's current need |
| An accepted order is cancelled | Order and cancellation records | Post-purchase messages |
| Recent use expires | Historical use events | The current-use label |
| A mistaken event is corrected | The correction and its reason | Any stage or message based on the invalid event |
An old milestone may remain true while the customer's current need changes. A mistaken event must no longer support a claim that the milestone was reached.
Recalculate current state from reliable evidence
Name the source of truth for each change. An event can occur before it reaches a messaging system, and a receipt timestamp does not guarantee the order in which actions happened. Device clocks or offline queues can also affect occurrence-related times. Do not let a late or duplicate event overwrite a newer state without a documented ordering and correction rule.
For example, a team completes its first task, then reopens it because the result is wrong. The first completion remains a historical milestone, while the current state may be needs revision. A message saying the work is finished would be misleading. If completion was recorded in error, invalidate that milestone and retain an auditable correction.
If identity is uncertain, hold a stage-specific claim for review. A task completed under another account should not silently change this customer's state.
Review messages waiting on the old state
List the scheduled journey messages, campaigns and other queues that rely on the previous state. Decide whether each message should be sent, skipped, replaced or held. Recheck relevant conditions near dispatch after a delay.
Workflow behaviour depends on configuration. Customer.io, for example, uses automation exit conditions to determine when a person leaves a journey. Its action conditions can instead skip one action and continue the journey. Behaviour in another sending system requires a separate check.
Decide how re-entry works. A customer returning to an earlier state may need renewed help, but an automatic restart may repeat an introduction already received. Use the task or account identifier and previous exit reason to distinguish a new task, a correction and a continuation.
If an unresolved service problem is present, route it to the appropriate care process before routine commercial prompts resume.
Check the rule against histories
Review a genuine reversal, a corrected event, a late arrival, a duplicate, a completed task followed by a new task and a customer with messages in two systems. For each, write down the expected current state, historical record, queued-message action and re-entry decision. Inspect how the actual configured tools handle those cases.
After launch, examine messages sent after reversals and customers left without appropriate help. Event and send times can help locate a data, state-rule, sync or queue problem.
