agentsclimarketplace

Churn prevention

Skill event4u-app/agent-config/dist/agent-src/skills/churn-prevention

Use when designing churn defence — health-score signals, churn-cause split (involuntary / value / relationship / fit), early-warning loop. Triggers on 'why are accounts leaving'.From its SKILL.md

Install
npx -y skills add event4u-app/agent-config --skill churn-prevention

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.8 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it

churn-prevention

When to use

  • Net retention dropped and the team cannot name which of the four churn causes is dominant — defence-spending is uniform when it should be cause-specific.
  • A health score exists but does not predict — it tracks usage but misses relationship and fit signals — and CS plays are running on bad triggers.
  • A board ask names "are we losing customers we should have kept, or customers who never fit?" — the answer requires the four-way classification, not a single number.

Do NOT use to fix days 0–30 onboarding (route to onboarding-design), drive upsell or expansion (route to expansion-playbook), or build product-led retention loops (route to retention-loops).

Cognition cluster

  • Mental model 30 — Inversion. Do not ask "how do we keep this account?" — ask "name the reason this account will leave." The inversion forces a cause; the cause picks the move. See docs/contracts/mental-models.md § 30.
  • Mental model 16 — Leading vs. lagging indicators. Cancellation is lagging; usage-decay, relationship-decay, and fit-mismatch signals are leading. A health score built on lagging signals can only confirm churn after the cancel request lands. See mental-models.md § 16.
  • Mental model 3 — Pareto (80/20). ~20 % of accounts carry ~80 % of revenue risk. Uniform health-monitoring across the book is theatre; weighted monitoring is reasoning. See mental-models.md § 3.
  • Context-spine — product + customer-segment. Read the product slot for which capabilities the segment was sold (value-churn lives here when capability and pitch diverged), and the customer-segment slot for the segment's switch-event patterns — fit-churn shows up early in segments whose switch event differs from the ICP. See context-spine.

Procedure

Step 0: Inspect — classify the last 20 churn events

Inspect the most recent 20 cancellation events. Tag each as one of:

  1. Involuntary — payment failure, dunning, card expiry. Not a value problem; an ops problem.
  2. Value — capability shipped does not match what was sold or what the buyer needs now.
  3. Relationship — champion left, sponsor change, exec turnover; product still fits, relationship does not.
  4. Fit — buyer was never the ICP; usage and pain never matched.

A book with > 30 % involuntary is an ops fix, not a CS fix. A book with > 30 % fit is a marketing / qualification fix upstream, not a CS fix.

Step 1: Define health-score signals per cause

One leading signal per cause, falsifiable, computable from existing telemetry:

  1. Involuntary — payment-method age, dunning-retry depth.
  2. Value — feature-usage decay vs paid-tier ceiling (used / available), session length trend.
  3. Relationship — primary-contact response-latency, executive-meeting cadence vs contract baseline.
  4. Fit — segment classification at signup vs ICP; in-product behaviour mismatch (using read-only when sold workflow).

Health score = weighted aggregate per segment; weights derived from Step 0's cause distribution. Do not average across causes — average hides the binding signal.

Step 2: Set early-warning thresholds with confidence bands

For each signal, compute the historical threshold where the signal flipped to a churn event within 60 days. Attach a confidence band. A threshold without a band over-triggers in low-volume cohorts and trains CS to ignore the alert.

Step 3: Map cause → play

Each cause gets one default play and one disqualifier:

  • Involuntary — payment-retry + alternate-method outreach. Disqualifier: account in voluntary cancellation queue.
  • Value — capability-gap interview; if real gap, route to product; if perception gap, route to enablement.
  • Relationship — multi-thread outreach to second sponsor + exec sponsor injection.
  • Fit — controlled wind-down; do not invest CS hours in saving a fit-mismatch account.

Step 4: Run the early-warning loop weekly

Weekly: pull accounts crossing threshold per signal; tag with cause; assign default play; record outcome at +30 days. Outcomes that do not match the play's expected lift become Step 1 signal revisions next quarter — not next week.

Step 5: Hand back

Hand the cause-classification of the last 20 events, the per-cause signal definitions, and the cause → play map to CS operations and to expansion-playbook for the healthy-account expansion-trigger logic. Net retention work without the cause split is spending money in random directions.

Related Skills

WHEN to use this

  • Designing a churn-cause classification and weighted health score.
  • Running the weekly early-warning loop and tuning thresholds.

WHEN NOT to use this

When the agent should load this

  • "Why are accounts churning?"
  • "Design a health score that actually predicts."
  • "Classify last quarter's churn — value or fit?"
  • "Welche Plays für Relationship-Churn?"

Output

  1. churn-classification.md — last 20 events tagged with cause; cause-distribution percentages with bands.
  2. health-signals.md — per-cause leading signal · threshold · confidence band · weight in aggregate health score.
  3. cause-play-map.md — per-cause default play · disqualifier · expected lift at +30 days.

Gotcha

  • A health score that aggregates without segmenting by cause hides the binding signal; CS plays based on the aggregate burn hours on the wrong account.
  • "Engagement dropped" is not a cause; it is an observation. Engagement drops because of value, relationship, or fit — diagnose the cause before triggering a play.
  • Fit-mismatch accounts surface as save targets when they should be wind-down targets. Saving a fit-mismatch account costs CS hours and produces a louder churn one cycle later.

Do NOT

  • Do NOT run uniform CS plays across the book; weight by Pareto-risk-tier.
  • Do NOT change health-score thresholds inside a quarter without an A/B holdout — concurrent changes destroy the signal.
  • Do NOT invest save-cycles into accounts whose churn cause is fit; route to a controlled wind-down and tighten qualification upstream.

Runnable example

Mid-market SaaS, gross retention slipped from 92 % to 86 % over two quarters.

  • Cause classification — of last 20 churns: involuntary 15 %, value 30 %, relationship 25 %, fit 30 %.
  • Health signals — involuntary: payment-retry-depth ≥ 2 → 38 % cancel-in-60d (band 22–54). Value: feature-usage decay > 30 % MoM → 51 % cancel (band 38–64). Relationship: primary-contact silent 21+ days → 44 % cancel (band 30–58). Fit: ICP-classification ≠ ICP-purchased → 71 % cancel (band 58–82).
  • Cause-play map — relationship-churn plays generate +18 % save-rate at +30 days; value plays generate +9 % only when paired with a product commit on the capability gap.
  • Hand-off — classification + signals + plays → CS ops weekly; tightened qualification rule fed back to marketing (fit-mismatch upstream); healthy-account triggers handed to expansion-playbook.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.