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 _predict (will_return) with _estimate (recoverable_revenue) and a cost model. The system computes per customer per day: predicted probability of return × predicted lifetime value if returned − outreach cost. When the value exceeds the cost at >70% confidence on the win-back probability, the trigger fires and the customer enters the outreach queue.
Mature deployments tune the threshold by outreach type. Low-cost outreach (email) fires at a lower confidence threshold than high-cost outreach (call from senior rep, discount offer). The same conditional probability machinery drives both decisions; the threshold is application-level configuration.
{
"from": "customers",
"where": {
"status": "lapsed",
"days_since_last_purchase": { "$range": [30, 180] }
},
"predict": "will_return",
"select": ["$p", "customer_id", "predicted_recoverable_revenue"],
"where": { "$p": { "$gte": 0.70 } },
"limit": 500
}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. Source is on GitHub under Apache 2.0.
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.
