The problem
Win-back campaigns are usually run as scheduled batches — once a quarter, send the lapsed-customer outreach to the whole list. The scheduling is convenient but it misses the win-back signal: customers lapse on different timelines, and the optimal outreach window is per-customer, not per-calendar.
The data shows when each customer becomes win-backable. The conditional probability of "will respond to outreach in the next 30 days" rises and falls per customer based on their pattern (recency of lapse, prior engagement, seasonality). Mature win-back triggers fire when that probability crosses a confidence threshold — not on the calendar.
How it works
Win-back triggers compose _recommend (which product to send), _predict (the chance the customer orders after an action, and after doing nothing) and _estimate (the order value) with a cost model. Per customer and action: (chance after it − chance after no action) × order value − its cost. When that is positive the action is worth firing; when every action comes out negative, "no action" is the best choice and nothing fires. In the demo, a €5 voucher comes out negative for the first listed customer.
Costs differ by outreach type. A discount or a voucher is paid on every order, including the ones that would have come anyway, while an email or an ad costs when sent; the demo prices both kinds. The same conditional probability machinery drives every decision; the cost model and any threshold are application-level configuration.
{
"from": "customer_actions",
"where": {
"recency_bucket": "0-90d",
"spend_band": "high",
"offer_buyer": "sometimes",
"open_issue": "none",
"email_history": "never_sent",
"tracking_consent": "yes",
"action_x_recency_bucket": "ad|0-90d",
"action_x_spend_band": "ad|high",
"action_x_offer_buyer": "ad|sometimes",
"action_x_open_issue": "ad|none",
"action_x_email_history": "ad|never_sent",
"action_x_tracking_consent": "ad|yes",
"action": "ad",
"discount_pct": "0",
"voucher_eur": "0"
},
"predict": "purchased_30d",
"limit": 2,
"select": [
"$p",
"feature"
]
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
Frequently asked
How is this different from win-back ranking?
Win-back ranking sorts the queue by predicted recoverable revenue for human-driven outreach. Win-back triggers fire automated outreach when the predicted value crosses a threshold. Ranking is for the retention team's call queue; triggers are for the marketing system's auto-send.
How frequently should the trigger evaluation run?
Daily for typical e-commerce; hourly for high-cadence categories (food delivery, consumables). The conditional probability updates with every customer signal; running the trigger evaluation on a faster cadence catches windows that close quickly.
Can different outreach types compete for the same customer?
Yes. Multiple triggers can fire for the same customer; the application picks the highest-value path. Most deployments prioritize: discount-offer trigger > email-only trigger > app-notification trigger, with cooldowns to prevent over-contact.
Does this work for B2B customer win-back (longer cycles, fewer customers)?
Yes. The probability calibration is per-domain — B2B win-back probabilities are lower (longer sales cycles, smaller pool of lapsed customers). The threshold tunes accordingly. Mature B2B deployments use win-back triggers to surface account-management calls, not automated emails.
How does the trigger handle customers who recently unsubscribed?
Unsubscribe is a hard exclusion at the application layer, not a soft input to the prediction. Unsubscribed customers do not appear in the trigger queue regardless of predicted recoverable revenue. The prediction respects channel preferences set at the application level.
