# Playbook: RFM-Segmented Sending

**Deliverable type this produces:** the meta-layer segmentation deliverable underneath every other playbook — not a single send type from §8.1's list, but the Layer 1 segment definitions that every other playbook (`welcome-sequence`, `launch-sequence`, `ecom-flow-set`, `daily-email`, `reactivation-campaign`) must consult before it's allowed to fire. Verify this deliverable as a **segment-definition document**: named segments, the rule that defines each, and which downstream playbook each is routed to.
**Derives from:** RFM (Recency-Frequency-Monetary) segmentation is a direct-marketing-analytics standard, sharpened here by Perry Marshall's 80/20 recursive power-law framing (*80/20 Sales and Marketing*, 2013) — the list obeys a power law recursively; the top 20% contains its own top 20% (the 4%/64% and 1%/50% power curve) — and by Everett Rogers' adopter-tier sequencing (Diffusion of Innovations, 1962), which governs the *order* in which segments get mailed, not just which segment exists.
**Engine (the science):** Marshall's recursive 80/20 (behavioral, not demographic, prediction of value concentration) plus Rogers' S-curve diffusion (behavior predicts adoption far better than demographics — segment by RFM behavior, then sequence by adopter tier).

## When to use it

- Always — before any cadence decision. Per §5.1 of the manual: "Never choose a style before choosing a segment." This is the first gate every other playbook must pass through.
- Any time the list has enough size/history to meaningfully differentiate recency, frequency, and monetary value — for 19Keys, immediately applicable to the 4,591-buyer CRM list.
- Before every bulk send of any kind, as the re-check that determines who is even eligible to receive it (engagement suppression).

## When NOT to use it

- Never skip it — but note it has a *dependency*: RFM segmentation requires the underlying CRM data model and enrichment, which is `crm-automation`'s domain, not this master's. This playbook consumes segments; it does not build the schema (§1 "what this master does NOT own"). If the CRM data isn't clean/available, escalate to `crm-automation` first rather than approximating with guesswork.
- Don't use RFM segmentation as an excuse to over-engineer before shipping the first send — five clean buckets (VIP/Hot/Warm/Cold/Dead) are sufficient to start; deeper recursive slicing (Marshall's 4%/1% whale cuts) is a refinement layered in once the basic five are live.

## The step-by-step build

1. **Pull Recency, Frequency, Monetary values per contact** from the CRM (confirm the live Supabase project ref with `crm-automation` first — do not assume table names, per §9.1).
2. **Define the five behavioral buckets** exactly as specified in §5.1 of the manual:
   - **VIP/whale** — top ~1-4% by Monetary + recent Recency. Marshall's power-curve cut (~46-900 accounts out of 4,591 per the manual's own estimate).
   - **Hot** — opened/clicked in the last 30 days.
   - **Warm** — engagement in the 30-90 day window.
   - **Cold** — 90-180 days, no engagement.
   - **Dead** — no response even to a reactivation attempt.
3. **Route each bucket to its owning playbook**, per §5.1:
   - VIP/whale → `plf-launch-sequence` first (Rogers' Innovators — mail launches to them first, harvest proof).
   - Hot → safe for `daily-email` + launches (Furey/Settle).
   - Warm → `soap-opera-sequence`/newsletter nurture cadence, not a direct launch ask.
   - Cold → `nine-word-reactivation` only — never a launch blast.
   - Dead → sunset/suppress. Mailing them poisons deliverability (§8.2 #6 adjacent risk) and should never receive any campaign.
4. **Cross-check the awareness gate (§5.2)** alongside RFM — a VIP/whale contact who is nonetheless Problem-Aware (rare but possible, e.g., a whale buyer of an unrelated past product) should get the SOS nurture treatment before a direct launch ask, even though RFM alone would route them to launch. RFM and awareness are two independent axes; both must agree before jumping straight to a launch.
5. **Save segments as living views/queries**, not one-off exports — Layer 4 instrumentation feeds re-segmentation back into Layer 1 continuously (engagement data from actual sends updates who counts as Hot/Warm/Cold going forward).
6. **Apply the segment gate before every send of any kind**, regardless of playbook — this is the veto-adjacent check that runs alongside §5.5's compliance veto. A perfectly-built launch sequence aimed at the Dead segment still fails review.
7. **Re-run the recursive cut periodically** (Marshall) — the whale segment is not static; recency decays and monetary value accrues with new purchases, so the top 1-4% shifts over time.

## Worked mini-example (19Keys / 4,591-buyer CRM)

| Segment | Rule | Approx. size (illustrative, from manual's own 80/20 estimate) | Routed playbook |
|---|---|---|---|
| VIP/whale | Top ~1% Monetary, Recency < 180d | ~46 accounts | `plf-launch-sequence` (first wave) |
| Hot | Open/click in last 30d | subset of engaged buyers | `daily-email`, launches |
| Warm | Engagement 30-90d | mid-tier of the list | `soap-opera-sequence` nurture / newsletter |
| Cold | 90-180d no engagement | long tail | `nine-word-reactivation` |
| Dead | No response to reactivation | remainder after reactivation arc completes | sunset/suppress — no further campaign sends |

Note per the house "no cherry-picked numbers" rule: the ~46 and 4,591 figures above are the manual's own illustrative power-curve estimate, not a measured result — label them as an estimate, not a verified count, until the actual RFM pull confirms real numbers.

## How the verify gate applies

This deliverable doesn't map to a single §8.1 rubric directly — it is checked as the **prerequisite gate** for every other rubric:
- Any `welcome-sequence`, `launch-sequence`, `ecom-flow-set`, `daily-email`, or `reactivation-campaign` deliverable that doesn't state which RFM segment(s) it targets should be sent back — per §5.1, style choice without a prior segment choice is out of order.
- Verify the five buckets are each defined by an **explicit, checkable rule** (not "engaged people" but "opened/clicked in 30 days") — this mirrors the explicit-inactivity-rule requirement inside the `reactivation-campaign` rubric (§8.1) and should be held to the same standard here.
- Verify the Dead segment is genuinely excluded from all active campaign sends — this is the check that most directly protects against §8.2 #5 (blasting the whole list identically) and #6 (skipping Layer 0/segment hygiene, poisoning deliverability).
- Verify segment source data traces back to a confirmed CRM project ref (§9.1) rather than an assumed/guessed table — an unverified data source undermines every downstream deliverable regardless of how well those deliverables are built.