churn-prevention-v2

name: churn-prevention-v2 description: "Churn Prevention workflow skill. Use this skill when the user needs Reduce voluntary and involuntary churn with cancel flows, save offers, dunning, win-back tactics, and retention strategy. Use when users are cancelling, failed payments are rising, or subscription retention needs improvement and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off." version: "0.0.1" category: business tags: ["churn-prevention-v2", "churn-prevention", "reduce", "voluntary", "and", "involuntary", "churn", "cancel"] complexity: advanced risk: caution tools: ["codex-cli", "claude-code", "cursor", "gemini-cli", "opencode"] source: community author: "sickn33" date_added: "2026-04-16" date_updated: "2026-04-25"

Churn Prevention

Overview

This public intake copy packages plugins/antigravity-awesome-skills/skills/churn-prevention from https://github.com/sickn33/antigravity-awesome-skills into the native Omni Skills editorial shape without hiding its origin.

Use it when the operator needs the upstream workflow, support files, and repository context to stay intact while the public validator and private enhancer continue their normal downstream flow.

This intake keeps the copied upstream files intact and uses the external_source block in metadata.json plus ORIGIN.md as the provenance anchor for review.

Churn Prevention You are an expert in SaaS retention and churn prevention. Your goal is to help reduce both voluntary churn (customers choosing to cancel) and involuntary churn (failed payments) through well-designed cancel flows, dynamic save offers, proactive retention, and dunning strategies.

Imported source sections that did not map cleanly to the public headings are still preserved below or in the support files. Notable imported sections: Before Starting, How This Skill Works, Cancel Flow Design, Churn Prediction & Proactive Retention, Involuntary Churn: Payment Recovery, Metrics & Measurement.

When to Use This Skill

Use this section as the trigger filter. It should make the activation boundary explicit before the operator loads files, runs commands, or opens a pull request.

• Use when churn is rising or cancellation behavior needs intervention.
• Use when designing cancel flows, save offers, dunning, or retention programs.
• Use when the user wants to reduce either voluntary or involuntary churn.
• Use when the request clearly matches the imported source intent: Reduce voluntary and involuntary churn with cancel flows, save offers, dunning, win-back tactics, and retention strategy. Use when users are cancelling, failed payments are rising, or subscription retention needs....
• Use when the operator should preserve upstream workflow detail instead of rewriting the process from scratch.
• Use when provenance needs to stay visible in the answer, PR, or review packet.

Operating Table

Workflow

This workflow is intentionally editorial and operational at the same time. It keeps the imported source useful to the operator while still satisfying the public intake standards that feed the downstream enhancer flow.

1. Confirm the user goal, the scope of the imported workflow, and whether this skill is still the right router for the task.
2. Read the overview and provenance files before loading any copied upstream support files.
3. Load only the references, examples, prompts, or scripts that materially change the outcome for the current request.
4. Execute the upstream workflow while keeping provenance and source boundaries explicit in the working notes.
5. Validate the result against the upstream expectations and the evidence you can point to in the copied files.
6. Escalate or hand off to a related skill when the work moves out of this imported workflow's center of gravity.
7. Before merge or closure, record what was used, what changed, and what the reviewer still needs to verify.

Imported Workflow Notes

Imported: Before Starting

Check for product marketing context first: If .agents/product-marketing-context.md exists (or .claude/product-marketing-context.md in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Gather this context (ask if not provided):

1. Current Churn Situation

• What's your monthly churn rate? (Voluntary vs. involuntary if known)
• How many active subscribers?
• What's the average MRR per customer?
• Do you have a cancel flow today, or does cancel happen instantly?

2. Billing & Platform

• What billing provider? (Stripe, Chargebee, Paddle, Recurly, Braintree)
• Monthly, annual, or both billing intervals?
• Do you support plan pausing or downgrades?
• Any existing retention tooling? (Churnkey, ProsperStack, Raaft)

3. Product & Usage Data

• Do you track feature usage per user?
• Can you identify engagement drop-offs?
• Do you have cancellation reason data from past churns?
• What's your activation metric? (What do retained users do that churned users don't?)

4. Constraints

• B2B or B2C? (Affects flow design)
• Self-serve cancellation required? (Some regulations mandate easy cancel)
• Brand tone for offboarding? (Empathetic, direct, playful)

Examples

Example 1: Ask for the upstream workflow directly

Use @churn-prevention-v2 to handle <task>. Start from the copied upstream workflow, load only the files that change the outcome, and keep provenance visible in the answer.

Explanation: This is the safest starting point when the operator needs the imported workflow, but not the entire repository.

Example 2: Ask for a provenance-grounded review

Review @churn-prevention-v2 against metadata.json and ORIGIN.md, then explain which copied upstream files you would load first and why.

Explanation: Use this before review or troubleshooting when you need a precise, auditable explanation of origin and file selection.

Example 3: Narrow the copied support files before execution

Use @churn-prevention-v2 for <task>. Load only the copied references, examples, or scripts that change the outcome, and name the files explicitly before proceeding.

Explanation: This keeps the skill aligned with progressive disclosure instead of loading the whole copied package by default.

Example 4: Build a reviewer packet

Review @churn-prevention-v2 using the copied upstream files plus provenance, then summarize any gaps before merge.

Explanation: This is useful when the PR is waiting for human review and you want a repeatable audit packet.

Best Practices

Treat the generated public skill as a reviewable packaging layer around the upstream repository. The goal is to keep provenance explicit and load only the copied source material that materially improves execution.

• Keep the imported skill grounded in the upstream repository; do not invent steps that the source material cannot support.
• Prefer the smallest useful set of support files so the workflow stays auditable and fast to review.
• Keep provenance, source commit, and imported file paths visible in notes and PR descriptions.
• Point directly at the copied upstream files that justify the workflow instead of relying on generic review boilerplate.
• Treat generated examples as scaffolding; adapt them to the concrete task before execution.
• Route to a stronger native skill when architecture, debugging, design, or security concerns become dominant.

Troubleshooting

Problem: The operator skipped the imported context and answered too generically

Symptoms: The result ignores the upstream workflow in plugins/antigravity-awesome-skills/skills/churn-prevention, fails to mention provenance, or does not use any copied source files at all. Solution: Re-open metadata.json, ORIGIN.md, and the most relevant copied upstream files. Check the external_source block first, then restate the provenance before continuing.

Problem: The imported workflow feels incomplete during review

Symptoms: Reviewers can see the generated SKILL.md, but they cannot quickly tell which references, examples, or scripts matter for the current task. Solution: Point at the exact copied references, examples, scripts, or assets that justify the path you took. If the gap is still real, record it in the PR instead of hiding it.

Problem: The task drifted into a different specialization

Symptoms: The imported skill starts in the right place, but the work turns into debugging, architecture, design, security, or release orchestration that a native skill handles better. Solution: Use the related skills section to hand off deliberately. Keep the imported provenance visible so the next skill inherits the right context instead of starting blind.

Imported Troubleshooting Notes

Imported: Common Mistakes

• No cancel flow at all — Instant cancel leaves money on the table. Even a simple survey + one offer saves 10-15%
• Making cancellation hard to find — Hidden cancel buttons breed resentment and bad reviews. Many jurisdictions require easy cancellation (FTC Click-to-Cancel rule)
• Same offer for every reason — A blanket discount doesn't address "missing feature" or "not using it"
• Discounts too deep — 50%+ discounts train customers to cancel-and-return for deals
• Ignoring involuntary churn — Often 30-50% of total churn and the easiest to fix
• No dunning emails — Letting payment failures silently cancel accounts
• Guilt-trip copy — "Are you sure you want to abandon us?" damages brand trust
• Not tracking save offer LTV — A "saved" customer who churns 30 days later wasn't really saved
• Pausing too long — Pauses beyond 3 months rarely reactivate. Set limits.
• No post-cancel path — Make reactivation easy and trigger win-back emails, because some churned users will want to come back

Related Skills

• @00-andruia-consultant - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @00-andruia-consultant-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @10-andruia-skill-smith - Use when the work is better handled by that native specialization after this imported skill establishes context.
• @10-andruia-skill-smith-v2 - Use when the work is better handled by that native specialization after this imported skill establishes context.

Additional Resources

Use this support matrix and the linked files below as the operator packet for this imported skill. They should reflect real copied source material, not generic scaffolding.

• cancel-flow-patterns.md
• dunning-playbook.md
• evals.json
• cancel-flow-patterns.md
• dunning-playbook.md

Imported Reference Notes

Imported: How This Skill Works

Churn has two types requiring different strategies:

Voluntary churn is typically 50-70% of total churn. Involuntary churn is 30-50% but is often easier to fix.

This skill supports three modes:

1. Build a cancel flow — Design from scratch with survey, save offers, and confirmation
2. Optimize an existing flow — Analyze cancel data and improve save rates
3. Set up dunning — Failed payment recovery with retries and email sequences

Imported: Cancel Flow Design

The Cancel Flow Structure

Every cancel flow follows this sequence:

Trigger → Survey → Dynamic Offer → Confirmation → Post-Cancel

Step 1: Trigger Customer clicks "Cancel subscription" in account settings.

Step 2: Exit Survey Ask why they're cancelling. This determines which save offer to show.

Step 3: Dynamic Save Offer Present a targeted offer based on their reason (discount, pause, downgrade, etc.)

Step 4: Confirmation If they still want to cancel, confirm clearly with end-of-billing-period messaging.

Step 5: Post-Cancel Set expectations, offer easy reactivation path, trigger win-back sequence.

Exit Survey Design

The exit survey is the foundation. Good reason categories:

Survey best practices:

• 1 question, single-select with optional free text
• 5-8 reason options max (avoid decision fatigue)
• Put most common reasons first (review data quarterly)
• Don't make it feel like a guilt trip
• "Help us improve" framing works better than "Why are you leaving?"

Dynamic Save Offers

The key insight: match the offer to the reason. A discount won't save someone who isn't using the product. A feature roadmap won't save someone who can't afford it.

Offer-to-reason mapping:

Save Offer Types

Discount

• 20-30% off for 2-3 months is the sweet spot
• Avoid 50%+ discounts (trains customers to cancel for deals)
• Time-limit the offer ("This offer expires when you leave this page")
• Show the dollar amount saved, not just the percentage

Pause subscription

• 1-3 month pause maximum (longer pauses rarely reactivate)
• 60-80% of pausers eventually return to active
• Auto-reactivation with advance notice email
• Keep their data and settings intact

Plan downgrade

• Offer a lower tier instead of full cancellation
• Show what they keep vs. what they lose
• Position as "right-size your plan" not "downgrade"
• Easy path back up when ready

Feature unlock / extension

• Unlock a premium feature they haven't tried
• Extend trial of a higher tier
• Works best for "not getting enough value" reasons

Personal outreach

• For high-value accounts (top 10-20% by MRR)
• Route to customer success for a call
• Personal email from founder for smaller companies

Cancel Flow UI Patterns

┌─────────────────────────────────────┐
│  We're sorry to see you go          │
│                                     │
│  What's the main reason you're      │
│  cancelling?                        │
│                                     │
│  ○ Too expensive                    │
│  ○ Not using it enough              │
│  ○ Missing a feature I need         │
│  ○ Switching to another tool        │
│  ○ Technical issues                 │
│  ○ Temporary / don't need right now │
│  ○ Other: [____________]            │
│                                     │
│  [Continue]                         │
│  [Never mind, keep my subscription] │
└─────────────────────────────────────┘
         ↓ (selects "Too expensive")
┌─────────────────────────────────────┐
│  What if we could help?             │
│                                     │
│  We'd love to keep you. Here's a    │
│  special offer:                     │
│                                     │
│  ┌───────────────────────────────┐  │
│  │  25% off for the next 3 months│  │
│  │  Save $XX/month               │  │
│  │                               │  │
│  │  [Accept Offer]               │  │
│  └───────────────────────────────┘  │
│                                     │
│  Or switch to [Basic Plan] at       │
│  $X/month →                         │
│                                     │
│  [No thanks, continue cancelling]   │
└─────────────────────────────────────┘

UI principles:

• Keep the "continue cancelling" option visible (no dark patterns)
• One primary offer + one fallback, not a wall of options
• Show specific dollar savings, not abstract percentages
• Use the customer's name and account data when possible
• Mobile-friendly (many cancellations happen on mobile)

For detailed cancel flow patterns by industry and billing provider, see references/cancel-flow-patterns.md.

Imported: Churn Prediction & Proactive Retention

The best save happens before the customer ever clicks "Cancel."

Risk Signals

Track these leading indicators of churn:

Health Score Model

Build a simple health score (0-100) from weighted signals:

Health Score = (
  Login frequency score × 0.30 +
  Feature usage score   × 0.25 +
  Support sentiment     × 0.15 +
  Billing health        × 0.15 +
  Engagement score      × 0.15
)

Proactive Interventions

Before they think about cancelling:

Imported: Involuntary Churn: Payment Recovery

Failed payments cause 30-50% of all churn but are the most recoverable.

The Dunning Stack

Pre-dunning → Smart retry → Dunning emails → Grace period → Hard cancel

Pre-Dunning (Prevent Failures)

• Card expiry alerts: Email 30, 15, and 7 days before card expires
• Backup payment method: Prompt for a second payment method at signup
• Card updater services: Visa/Mastercard auto-update programs (reduces hard declines 30-50%)
• Pre-billing notification: Email 3-5 days before charge for annual plans

Smart Retry Logic

Not all failures are the same. Retry strategy by decline type:

Retry timing best practices:

• Retry 1: 24 hours after failure
• Retry 2: 3 days after failure
• Retry 3: 5 days after failure
• Retry 4: 7 days after failure (with dunning email escalation)
• After 4 retries: Hard cancel with reactivation path

Smart retry tip: Retry on the day of the month the payment originally succeeded (if Day 1 worked before, retry on Day 1). Stripe Smart Retries handles this automatically.

Dunning Email Sequence

Dunning email best practices:

• Direct link to payment update page (no login required if possible)
• Show what they'll lose (their data, their team's access)
• Don't blame ("your payment failed" not "you failed to pay")
• Include support contact for help
• Plain text performs better than designed emails for dunning

Recovery Benchmarks

For the complete dunning playbook with provider-specific setup, see references/dunning-playbook.md.

Imported: Metrics & Measurement

Key Churn Metrics

Cohort Analysis

Segment churn by:

• Acquisition channel — Which channels bring stickier customers?
• Plan type — Which plans churn most?
• Tenure — When do most cancellations happen? (30, 60, 90 days?)
• Cancel reason — Which reasons are growing?
• Save offer type — Which offers work best for which segments?

Cancel Flow A/B Tests

Test one variable at a time:

How to run cancel flow experiments: Use the ab-test-setup skill to design statistically rigorous tests. PostHog is a good fit for cancel flow experiments — its feature flags can split users into different flows server-side, and its funnel analytics track each step of the cancel flow (survey → offer → accept/decline → confirm).

Imported: Tool Integrations

For implementation, use the billing, analytics, and experimentation tools available in the current environment.

Retention Platforms

Billing Providers (Dunning)

Related CLI Tools

Imported: Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.