The Offer That Overrode the Message
An airline sends a booking-confirmation email that includes a personalized upgrade offer. The email template has a hard-coded fallback offer ("20% off seat upgrades") and also calls a decision policy to fetch a personalized offer. During a peak sale, the decisioning service is slow and sometimes returns no eligible offer for a profile. In those cases, customers see the fallback - but the fallback is the same 20% offer for everyone, and some customers who already purchased an upgrade receive it again, generating complaints. The team considers removing the fallback entirely so the email only shows an offer when decisioning succeeds.
1. Evaluate the proposal to remove the fallback offer. What are the risks, and what should determine the fallback behavior?
Read the worked answer
Removing the fallback is the wrong fix for the actual problem. The complaints come from a bad fallback (undifferentiated, and not eligibility-aware), not from the existence of a fallback.
Risks of removing it:
- Broken/empty content. When decisioning is slow or returns nothing, the offer block renders empty or breaks layout - a worse customer experience than a generic offer.
- No graceful degradation. Peak-time decisioning latency is exactly when volume is highest; removing the fallback makes the failure mode visible to the most customers.
- Doesn't solve eligibility. A customer who already bought an upgrade would still be eligible for the personalized offer unless eligibility rules exclude them.
The fallback should be governed by the same eligibility logic as personalized offers:
- Suppress the offer block entirely for profiles who are ineligible (e.g., already upgraded) - a conditional suppression, not a blanket removal.
- Use a safe, low-risk generic fallback for eligible profiles when decisioning fails.
- Set a decisioning timeout so slow responses degrade to fallback quickly rather than delaying the email.
2. A colleague says 'just make the decision policy faster.' Why is that insufficient, and what two controls would you add?
Read the worked answer
Speed alone doesn't address correctness. Even a fast decision policy can legitimately return no eligible offer (all offers exhausted, eligibility rules exclude the profile, frequency caps hit). "Faster" reduces timeouts but not empty results - and empty results are the case that generated complaints.
Add two controls:
- Eligibility/suppression rules at the offer level. Encode "already purchased upgrade" as a rule that excludes the profile from both the personalized and fallback offer. This fixes the complaint root cause regardless of decisioning speed.
- A defined degradation contract. Specify what happens on timeout vs. no-eligible-offer vs. error: a decisioning timeout that triggers fallback, and a fallback that is itself eligibility-checked. Test each path explicitly.
The principle: decisioning failures are a content-governance problem, not just a latency problem. Design the empty and slow paths deliberately.