Implementation worksheet · 5 min read
A Next-Best-Action Fallback Policy for Missing Data
Define a fallback ladder per decision input, ordered from best to worst, ending in an explicit do-nothing: use the live signal; if absent, use the most recent known value with an age limit; if that is stale, use the cohort default; if there is no cohort, send the neutral message; if even that does not apply, send nothing and log why. The rule that matters: never let a missing input silently become a default value, because a default is indistinguishable from real data downstream. And write down the suppression threshold — the confidence level below which the honest action is no action, since a confidently wrong recommendation costs more than an absent one.
Next-best-action systems are specified against complete profiles and deployed against real ones, where firmographics are blank, last-seen is six months old and the plan field never synced. The fallback ladder decides whether that degrades gracefully or produces nonsense with a personalised name on it.
Put it into practice
1. List the inputs each decision actually uses
Usually fewer than the model implies: plan, last active, a usage counter, maybe industry. For each, ask what fraction of live profiles have it populated — the answer is routinely worse than anyone expects.
2. Write the ladder per input, with an age limit
Live value, then last-known-within-N-days, then cohort default, then neutral. The age limit is the part teams skip: a last-known value from eight months ago is not data, it is a guess wearing data's clothes.
3. Make missing distinguishable from default
A profile with no industry and a profile defaulted to 'other' must be different values in storage, or you can never measure how much of your personalisation is real.
4. Set the do-nothing threshold
Below a stated confidence, the action is no action. Suppressing a recommendation is a legitimate outcome and should be logged as one, not treated as a system failure.
5. Report fallback rates weekly
What share of decisions ran on live data, last-known, cohort, neutral, or were suppressed. A rising fallback rate is a data-pipeline problem arriving before anyone notices the campaign got worse.
Fallback ladder (one row per input)
Copy this structure into your review document and record your observed result for each row.
| Input | Live | Last known (max age) | Cohort default | Neutral / suppress |
|---|---|---|---|---|
| Plan tier | billing system | 30 days | free-tier assumptions | generic |
| Last active | event stream | 7 days | cohort median | suppress |
| Industry | enrichment | 90 days | segment default | generic |
| Usage count | product events | 1 day | cohort median | suppress |
| Locale | profile | none — required | account country | English |
A failure worth checking
The confidently wrong recommendation: a blank plan field defaults to 'enterprise', and a hobbyist gets a sales-assist sequence about procurement and seat licensing. Nothing errored; every system reported success. Personalisation failures do not look like bugs — they look like contempt, which is why the do-nothing branch has to be a designed outcome rather than an oversight.
Common questions
Is sending nothing really acceptable?
It is often the highest-value action available. The cost of a wrong recommendation includes the unsubscribe and the credibility of every future message; suppression costs one impression.
How do I choose the max age per input?
By how fast the underlying fact changes. Plan tier moves monthly, last-active moves daily, industry barely moves at all. Pick ages that match reality rather than one global staleness rule.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.