Implementation worksheet · 5 min read
A Churn-Risk Cohort Eligibility Specification
A churn-risk cohort needs four written rules before any journey touches it: the risk signal (which behaviors over which window — e.g. core-action frequency down 50% across 14 days vs the prior 28), the exclusions (new accounts still onboarding, accounts in open support escalations, already-cancelled), the cooldown (an account exiting the cohort can't re-enter for 30 days, and can't receive the same play twice in a quarter), and the exit condition (what behavior change removes them). Write these as a table the whole team signs; every retention argument later is one of these four cells, and the spec is what makes a churn play testable instead of vibes.
Churn plays fail at definition more often than at messaging: the cohort quietly includes trial users who were never going to convert, or re-captures the same account monthly until unsubscribe. Eligibility is a specification problem — and it's the spec an agentic system needs verbatim.
Put it into practice
1. Define the risk signal against a baseline, not a threshold
'Logged in under 3 times' misfires across personas. Relative decline — core-action frequency down X% vs the account's own prior period — tracks actual disengagement. Pick the core action first; if you can't name it, that's the real project.
2. Write the exclusion list before the first send
Accounts under 30 days old (that's activation's job, different play), open escalations (a retention email during an angry ticket reads as tone-deaf automation), scheduled cancellations, and any account a human owns (CS-managed accounts get humans, not sequences).
3. Set cooldowns per account AND per play
30 days out of the cohort after exit; the same play at most twice a quarter per account. Without both rules, an oscillating account gets the same 'we miss you' email monthly — the fastest route from at-risk to unsubscribed.
4. Define the exit as behavior, not sends-completed
The account leaves the cohort when the core action recovers to baseline — not when the sequence finishes. A completed sequence with no recovery means the play failed for that account; log it as such.
5. Reconcile the cohort weekly against outcomes
Cohort size, entries, exits by reason (recovered / churned / cooldown), and play performance measured on recovery rate — not opens. This one table is the churn program's actual dashboard.
Eligibility spec template
Copy this structure into your review document and record your observed result for each row.
| Rule | Definition | Owner sign-off |
|---|---|---|
| Risk signal | core action down ≥50% over 14d vs prior 28d | |
| Exclusions | <30d old; open escalation; cancelling; CS-owned | |
| Cooldown | 30d re-entry block; same play ≤2/quarter | |
| Exit condition | core action back to ≥80% of baseline | |
| Review cadence | weekly reconciliation vs outcomes |
A failure worth checking
The re-entry trap: an account dips, gets the play, marginally recovers, dips again next month — and re-qualifies forever. Without cooldown and per-play caps, your most ambivalent users receive the most automation, converting soft churn risk into hard unsubscribes. The cohort's churn rate then looks worse than doing nothing, because the play manufactured annoyance.
Common questions
Should churn-risk detection be a score or a rule?
Start with a rule — it's debuggable, explainable, and forces the team to name the core action. Graduate to a model when you have outcome data proving the rule's misses. A score nobody can explain produces cohorts nobody trusts, and the play dies in review.
Who should own this spec?
Whoever owns the retention number — with product, CS and lifecycle marketing signing the exclusions. The spec is a contract between teams; unsigned specs get relitigated in the first bad week.
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.