Skip to main content

Win-back lapsed customers with a multi-channel fallback journey

A win-back journey reactivates customers who have gone quiet. This guide builds one from a CDP segment, sends a timed sequence across email, SMS, and WhatsApp, attaches a unique incentive code, guards against duplicate enrollment, and measures whether the journey actually caused conversions. For segment mechanics see CDP audiences. For journey nodes and validation see Build a campaign journey. For the fallback engine behind the channel chain see Fallback chains and Smart-send fallback chains.

1. Define the win-back segment in CDP

Create a segment under Contacts → Segments or with the Segments API. The win-back gate is behavioral: the contact was a customer but has had no meaningful activity recently. Example filter — customers with no event or purchase in the last 90 days:
Key choices:
  • Auto-refresh must be on. A segment trigger only fires when the segment re-evaluates; without auto-refresh the journey never gains new enrollments.
  • Use a 24-hour refresh or longer. Daily re-evaluation is the right cadence for lifecycle segments. A shorter interval buys little and increases compute.
  • Preview the count. POST /api/v1/contacts/segments/preview returns the match count before you persist the segment.
If you already use churn-risk scoring, you can combine the inactivity rule with churn_risk > 0.7 for a higher-propensity cohort.

2. Pick the trigger type

Two trigger patterns are common for win-back: Both patterns use the same journey node. In the dashboard under Campaigns → Journey builder, add a Journey Trigger node and set Trigger Type to Segment entry or Segment exit. Pick the segment from section 1. If you use the API, the journeyTrigger node carries triggerType: "segment" and a segment_id. The campaign’s audience_type can be "all" because the trigger itself decides enrollment.

3. Compose the three-touch fallback chain

The journey sends one message per channel, spaced apart, so the next channel only reaches people who did not convert on the previous touch.
  1. Email on day 1 — the richest format for explaining the offer.
  2. SMS on day 3 — a short reminder with a tracked link to the incentive.
  3. WhatsApp on day 7 — the final fallback, useful where WhatsApp is the primary channel.
Wired as a journeyDefinition graph:
Save the graph on the campaign:
The exit_criteria here means a contact who purchases after the first email leaves the journey before the SMS or WhatsApp steps fire.

4. Attach a unique win-back incentive code

Use the incentives ledger to mint a unique code per recipient. A discount_code reward returns a code you can splice into the message template. For a campaign-level variable, issue one code per recipient before launch or use the journey’s {{coupon_code}} merge-tag, which derives a deterministic unique value from the recipient identity. To issue programmatically:
Response:
Pass the code into the campaign’s personalization context, or read it from GET /api/v1/incentives/issued?source_ref=winback-campaign-2026q4 before launching and load it into variables.per_contact_codes. If you prefer loyalty points instead of a discount, route the reward through the loyalty program redemption endpoint; the issued record still lands in the same incentives ledger.

5. Re-entry guard and suppression

Set two limits so the same customer is not repeatedly enrolled:
  1. Re-entry cooldown. The graph above uses "re_entry_policy": "after_cooldown_days" with "re_entry_cooldown_days": 90. A contact can re-enter only after 90 days outside the segment.
  2. Global enrollment cap. Add a campaign-level variable to cap total enrollments per contact. The recommended default for win-back is 3 lifetime enrollments:
For suppression rules and how they interact with consent, see Choose your suppression entry point. All opt-outs — CSV import, Consent API, or Preference Center — write into the same ledger that send gates read.

6. Measure uplift with a holdout

Reserve a control group so the conversion rate you see is causal, not just a count of people who would have come back anyway. Set a campaign-wide holdout before launch:
After the journey has run, read lift:
The response reports treatment versus control, absolute lift, relative lift, and a confidence interval. Treat the effect as unproven until is_significant is true. For the full interpretation see Holdouts and uplift measurement.

7. Compliance pre-flight

Run these checks before launch:
  • Quiet hours. The platform applies tenant-configured quiet-hours windows at send time. Review your window under Compliance → Quiet hours and check the quiet-hours configuration guide.
  • Marketing opt-out. Every marketing message must carry a clear opt-out. Email needs an unsubscribe link; SMS and WhatsApp need “Reply STOP to opt out” or a localized equivalent.
  • Unsubscribe footer. The email template in section 3 includes {{unsubscribe_url}}. Verify the link resolves to your hosted preference center or a working unsubscribe handler.
  • Country rules. If your audience spans markets, review the country rules directory. Country-specific consent, sender-ID, and marketing-hour rules are tenant-owned controls; configure them per market rather than relying on a platform default.
Compliance controls other than the US TCPA federal voice dialing-window guard are tenant-owned and default open. You decide what qualifies as consent, opt-out, and lawful sending; the platform enforces the gates you configure. This guide is not legal advice.

8. Launch the journey

Launch from the dashboard under Outbound → Campaigns or from Campaigns → Journey builder, or call the send endpoint:
After launch, monitor enrollments and conversions:
  • GET /api/v1/campaigns/cmp_winback01/journey-analytics — aggregate funnel.
  • GET /api/v1/campaigns/cmp_winback01/journey/node-analytics — per-node send, delivery, and exit counts.
  • GET /api/v1/campaigns/cmp_winback01/journey/goal/analytics — conversion rollup.
  • GET /api/v1/campaigns/cmp_winback01/journey/holdout-lift — causal lift versus the control group.

See also