Reengagement Segmenter

Turn "the lapsed list" into distinct audiences with distinct reasons for silence, and treat the reason as the segment. The design rests on one argument: win-back blasts fail because they treat silence as one condition, when silence is the least informative signal a contact can send. A deal stalled at security review, a user who never reached value, and a buyer who signed with the incumbent all look identical in a recency report and need three different messages, or none.

The other half of the argument is the repo's standing one: the most valuable output of a reengagement pass is often the list of people you decide not to contact, documented.

What this consumes

The last row is the load-bearing one. A reengagement sequence exists because something changed: your product closed the gap that stalled them, their situation visibly shifted, or a trigger from the ICP fired. No change, no sequence; that cohort waits.

The workflow

Five phases. Show the user the segment map (end of Phase 3) before any drafting.

Phase 1: Assemble the evidence, not just the list

Pull the lapsed records with whatever evidence exists per record: last meaningful activity, lifecycle stage reached, stated reasons (closed-lost fields, cancellation surveys), and observed behavior (support tickets, usage before silence, emails). First-party evidence is messy and contradictory; that is expected and handled in Phase 3, not smoothed over.

Phase 2: Run the exclusions first

Before any blocker reasoning, apply the hard gates from references/blocker-taxonomy.md: unsubscribed or do-not-contact, complaint history, active competitor contracts, ICP disqualifiers, and the dormancy horizon. These records go to the leave-alone lane with reasons, which ships in the deliverable. Reengaging someone who opted out is not a growth motion, it is a compliance incident.

Phase 3: Assign blockers, honestly

Tag each surviving record with a blocker from the taxonomy, citing the evidence. Three rules:

• The evidence outranks the label. When the CRM says "price" but the thread shows a security stall, the record is flagged as a conflict and resolved by judgment, with the resolution written down. scripts/segment_audience.py detects these conflicts mechanically.
• Unknown stays unknown. A record with no blocker evidence goes to the diagnostic segment, whose sequence asks one honest question instead of assuming a reason.
• The script does the bookkeeping. Deterministic rules (exclusions, recency bands, tag precedence, conflict detection) run mechanically; the judgment calls are yours and get recorded.

Phase 4: Plan one motion per segment

Each blocker has its own sequence archetype in the taxonomy: the never-activated get the value they missed, the timing-stalled get a low-pressure trigger watch, the security-stalled get the specific thing that changed, the diagnostic segment gets one question. Two universal rules: reengagement sequences are shorter than cold ones (two to three touches), and every sequence opens with the why-now change, not with an apology for the silence.

Phase 5: Draft, gate, package

Draft in the brand voice and run every sequence through outbound-engine's sequence_gate.py: the freshness check applies to the why-now change, the slop list catches "just checking in" (the canonical reengagement failure), and the voice Avoid list holds. Package per references/output-template.md: the segment map with counts, the per-segment plans, the conflict log, and the leave-alone lane with reasons.

Scripts

Failure modes to avoid (the quality bar)

• One blast to the whole list. The disease this skill treats.
• "Just checking in." The outbound gate catches it mechanically; do not write it.
• Guessing the blocker. No evidence means the diagnostic segment, not your best story.
• Reengaging the excluded. Unsubscribes and complaints are permanent exits from this motion.
• Apologizing for the silence. Open with what changed, not with the gap.
• A hidden leave-alone lane. The records you chose not to contact, with reasons, are output.
• Trusting the CRM label over the thread. Stated reasons are hypotheses; conflicts get logged.

Bundled references

• references/blocker-taxonomy.md: the segments, the evidence each requires, the exclusion gates, and the sequence archetype per segment. Read at Phases 2-4.
• references/output-template.md: the audience.json schema the script consumes and the segment report format. Read at Phases 3-5.
• examples/cohere/: a dormant-pipeline pass in Cohere's voice on synthetic records (fictional counterparties, labeled, with real contradictions), the segment map, and a gated sequence for the security-stall segment.