The Journey That Wouldn't Stop
A travel company runs an omnichannel booking journey: a browse-abandon email at 1 hour, an SMS at 24 hours if no booking, a push notification at 72 hours, and a 'final reminder' email at 7 days. Entry is triggered whenever a customer views a destination page without booking. A customer service lead reports that some customers received the full sequence twice in one week after browsing two different destinations, and a few received SMS and push after they had already booked. The journey has no exit criteria other than 'booking recorded,' and booking data syncs from the reservation system every 12 hours. SMS opt-in is 31%; push is enabled on 44% of devices. The team wants to add a 10% off code at day 7 to improve conversion.
1. Diagnose why customers receive duplicate and post-booking messages, and identify the missing journey controls.
Read the worked answer
Two distinct failures:
- Duplicate sequences: entry is per browse event, not per customer. Browsing two destinations creates two journey instances, and nothing deduplicates them, so the same person gets the full sequence twice. Missing control: customer-level journey deduplication / one active instance per customer, with re-entry rules (e.g., allow re-entry only after the prior instance completes or after a cooldown).
- Post-booking messages: the only exit is 'booking recorded,' but booking data syncs every 12 hours. Between booking and sync, the 24-hour SMS and 72-hour push can fire. Missing controls: near-real-time booking suppression (or a pre-send re-check against the reservation system), plus an exit on booking event that removes the customer from all pending steps, not just future ones.
Also missing: channel eligibility checks at send time (SMS opt-in 31%, push 44%) so unreachable customers aren't counted as reached, and a global contact cap across the journey.
2. Recommend the fixes, including how to evaluate the proposed day-7 discount.
Read the worked answer
Fixes (in priority order):
- Deduplicate at the customer level - one active journey instance per customer; new browses update the existing instance rather than starting a new one; define a re-entry cooldown.
- Real-time exit on booking - subscribe the journey to the booking event and remove the customer from all pending steps immediately; as a backstop, re-check reservation status at send time (especially for the 24h/72h/7d steps that fall inside the 12-hour sync lag).
- Send-time eligibility - check SMS opt-in and push enablement before each step; route to email fallback where appropriate.
- Frequency cap across the journey and across campaigns.
Evaluating the day-7 discount:
- Run it as a holdout test (randomized no-discount control) rather than adding it to everyone, because the day-7 audience is already the least-converting group and may be deal-seekers.
- Measure incremental bookings and margin, net of discount cost, not raw conversion.
- Confirm the journey's exit and dedup fixes are live before the test, otherwise duplicated sequences will contaminate the read and the discount will be sent to people who already booked.