agentsclimarketplace

Churn prevention

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

Universal AI Agent OS — audited skills, governance rules, replayable state. One contract, every host agent.

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.

What its author says it does

Copied from the file, not written here

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

SKILL.md

7.8 KB, 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.

Keep looking

Skills are one crate of 328,083. 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.