Skip to content
cccskills
FreePublished on GitHub

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'.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md7.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

See all skills by event4u-app

Report a problem with this skill