Churn Prevention
Corey HainesCommunityCreated by Corey Haines
- Skill
- Workflow
- Business and productivity
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to managing SaaS retention. It covers the two primary drivers of churn: voluntary (customer-initiated) and involuntary (failed payments). It guides users through designing effective cancellation flows that use exit surveys and dynamic save offers to retain customers, as well as implementing dunning sequences to recover failed payments. The skill emphasizes data-driven decision-making, such as tracking churn signals and using cohort analysis to refine retention strategies.
What it does
- Designs multi-step cancellation flows with exit surveys and dynamic save offers.
- Provides strategies for involuntary churn recovery through dunning email sequences and smart retries.
- Outlines leading indicators and health score models to predict and prevent churn before it happens.
- Offers guidance on segmenting churn data to identify high-risk cohorts and effective interventions.
- Recommends specific retention tools and billing provider configurations for implementation.
- Defines key metrics like save rates, recovery rates, and net revenue churn for performance tracking.
When to use it
- When you need to build or optimize a self-serve cancellation flow for your SaaS product.
- When you are experiencing high involuntary churn due to failed credit card payments.
- When you want to implement proactive retention campaigns based on user engagement signals.
- When you need to design win-back or save offers tailored to specific cancellation reasons.
- When you need to establish a dunning process to recover revenue from expired or declined cards.
Advantages
- Reduces churn by addressing both voluntary and involuntary causes systematically.
- Improves customer lifetime value by using targeted save offers instead of blanket discounts.
- Provides actionable frameworks for both B2B and B2C subscription models.
- Helps maintain brand trust by ensuring cancellation processes are transparent and user-friendly.
- Offers clear benchmarks for measuring the success of retention and recovery efforts.
Usage examples
- “Our SaaS churn rate is 8%. How can I build a cancellation flow that helps us save more users?”
- The agent will guide you through creating a trigger-survey-offer-confirmation flow, suggest appropriate exit survey questions, and help you map specific save offers to common cancellation reasons.
- “We have a lot of involuntary churn from failed payments. How should I set up a dunning sequence?”
- The agent will provide a recommended timeline for retry attempts and email templates, explain how to use smart retry logic, and suggest best practices for card expiry management.
- “How do I identify which users are at risk of churning before they actually cancel?”
- The agent will help you define a health score model based on engagement signals like login frequency, feature usage, and support sentiment to trigger proactive interventions.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/coreyhaines31/churn-prevention/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip churn-prevention.zip -d .agents/skills
Documentation by Corey Haines
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.
Before Starting
Check for product marketing context first:
If .agents/product-marketing.md exists (or .claude/product-marketing.md, or the legacy product-marketing-context.md filename, 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)
How This Skill Works
Churn has two types requiring different strategies:
| Type | Cause | Solution |
|---|---|---|
| Voluntary | Customer chooses to cancel | Cancel flows, save offers, exit surveys |
| Involuntary | Payment fails | Dunning emails, smart retries, card updaters |
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:
Build a cancel flow — Design from scratch with survey, save offers, and confirmation
Optimize an existing flow — Analyze cancel data and improve save rates
Set up dunning — Failed payment recovery with retries and email sequences
Cancel Flow Design
The Cancel Flow Structure
Every cancel flow follows this sequence:
Trigger → Survey → Dynamic Offer → Confirmation → Post-CancelStep 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:
| Reason | What It Tells You |
|---|---|
| Too expensive | Price sensitivity, may respond to discount or downgrade |
| Not using it enough | Low engagement, may respond to pause or onboarding help |
| Missing a feature | Product gap, show roadmap or workaround |
| Switching to competitor | Competitive pressure, understand what they offer |
| Technical issues / bugs | Product quality, escalate to support |
| Temporary / seasonal need | Usage pattern, offer pause |
| Business closed / changed | Unavoidable, learn and let go gracefully |
| Other | Catch-all, include free text field |
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:
| Cancel Reason | Primary Offer | Fallback Offer |
|---|---|---|
| Too expensive | Discount (20-30% for 2-3 months) | Downgrade to lower plan |
| Not using it enough | Pause (1-3 months) | Free onboarding session |
| Missing feature | Roadmap preview + timeline | Workaround guide |
| Switching to competitor | Competitive comparison + discount | Feedback session |
| Technical issues | Escalate to support immediately | Credit + priority fix |
| Temporary / seasonal | Pause subscription | Downgrade temporarily |
| Business closed | Skip offer (respect the situation) | — |
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.
Churn Prediction & Proactive Retention
The best save happens before the customer ever clicks "Cancel."
Risk Signals
Track these leading indicators of churn:
| Signal | Risk Level | Timeframe |
|---|---|---|
| Login frequency drops 50%+ | High | 2-4 weeks before cancel |
| Key feature usage stops | High | 1-3 weeks before cancel |
| Support tickets spike then stop | High | 1-2 weeks before cancel |
| Email open rates decline | Medium | 2-6 weeks before cancel |
| Billing page visits increase | High | Days before cancel |
| Team seats removed | High | 1-2 weeks before cancel |
| Data export initiated | Critical | Days before cancel |
| Individual recommendation rating is 0–6 (detractor) | Medium | 1-3 months before cancel |
Health Score Model
Build a simple health score (0-100) from weighted signals. Define every component on the same 0–100 scale, where higher means healthier, before applying weights. Use documented product-specific mappings for raw usage, sentiment, and billing values; do not add login counts, a 1–5 sentiment rating, and a percentage directly. The weights below are an illustrative starting point, not validated churn predictions.
Treat missing or stale signals as unavailable, rather than automatically healthy or zero. Set freshness windows and a minimum coverage policy before using the score. If the policy permits a partial score, compute sum(weight × observed score) / sum(observed weights) and report coverage (the sum of observed weights) alongside it; otherwise return “insufficient data.” All unavailable means no score. For example, only login (80) and feature usage (60) produce (0.30×80 + 0.25×60)/0.55 = 70.91, with 55% coverage. Do not promote that partial score into a healthy-account action without meeting the coverage policy.
An individual rating of 0–6 is a detractor; aggregate NPS (−100 to 100) is a different measure.
Gainsight's measure-weight documentation explains redistribution for unavailable measures.
Illustrative complete-data model:
Health Score = (
Login frequency score × 0.30 +
Feature usage score × 0.25 +
Support sentiment × 0.15 +
Billing health × 0.15 +
Engagement score × 0.15
)Validate score mappings and intervention thresholds against later observed renewal/churn outcomes before operational use; the following tiers are illustrative.
| Score | Status | Action |
|---|---|---|
| 80-100 | Healthy | Upsell opportunities |
| 60-79 | Needs attention | Proactive check-in |
| 40-59 | At risk | Intervention campaign |
| 0-39 | Critical | Personal outreach |
Proactive Interventions
Before they think about cancelling:
| Trigger | Intervention |
|---|---|
| Usage drop >50% for 2 weeks | "We noticed you haven't used [feature]. Need help?" email |
| Approaching plan limit | Upgrade nudge (not a wall — paywalls handles this) |
| No login for 14 days | Re-engagement email with recent product updates |
| NPS detractor (0-6) | Personal follow-up within 24 hours |
| Support ticket unresolved >48h | Escalation + proactive status update |
| Annual renewal in 30 days | Value recap email + renewal confirmation |
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 cancelPre-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:
| Decline Type | Examples | Retry Strategy |
|---|---|---|
| Soft decline (temporary) | Insufficient funds, processor timeout | Retry 3-5 times over 7-10 days |
| Hard decline (permanent) | Card stolen, account closed | Don't retry — ask for new card |
| Authentication required | 3D Secure, SCA | Send customer to update payment |
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
| Timing | Tone | Content | |
|---|---|---|---|
| 1 | Day 0 (failure) | Friendly alert | "Your payment didn't go through. Update your card." |
| 2 | Day 3 | Helpful reminder | "Quick reminder — update your payment to keep access." |
| 3 | Day 7 | Urgency | "Your account will be paused in 3 days. Update now." |
| 4 | Day 10 | Final warning | "Last chance to keep your account active." |
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
| Metric | Poor | Average | Good |
|---|---|---|---|
| Soft decline recovery | <40% | 50-60% | 70%+ |
| Hard decline recovery | <10% | 20-30% | 40%+ |
| Overall payment recovery | <30% | 40-50% | 60%+ |
| Pre-dunning prevention | None | 10-15% | 20-30% |
For the complete dunning playbook with provider-specific setup, see references/dunning-playbook.md.
Metrics & Measurement
Key Churn Metrics
| Metric | Formula | Target |
|---|---|---|
| Monthly churn rate | Churned customers / Start-of-month customers | <5% B2C, <2% B2B |
| Revenue churn (net) | (Lost MRR - Expansion MRR) / Start MRR | Negative (net expansion) |
| Cancel flow save rate | Saved / Total cancel sessions | 25-35% |
| Offer acceptance rate | Accepted offers / Shown offers | 15-25% |
| Pause reactivation rate | Reactivated / Total paused | 60-80% |
| Dunning recovery rate | Recovered / Total failed payments | 50-60% |
| Time to cancel | Days from first churn signal to cancel | Track trend |
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:
| Test | Hypothesis | Metric |
|---|---|---|
| Discount % (20% vs 30%) | Higher discount saves more | Save rate, LTV impact |
| Pause duration (1 vs 3 months) | Longer pause increases return rate | Reactivation rate |
| Survey placement (before vs after offer) | Survey-first personalizes offers | Save rate |
| Offer presentation (modal vs full page) | Full page gets more attention | Save rate |
| Copy tone (empathetic vs direct) | Empathetic reduces friction | Save rate |
How to run cancel flow experiments: Use the ab-testing 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). See the PostHog integration guide for setup.
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
Tool Integrations
For implementation, see the tools registry.
Retention Platforms
| Tool | Best For | Key Feature |
|---|---|---|
| Churnkey | Full cancel flow + dunning | AI-powered adaptive offers, 34% avg save rate |
| ProsperStack | Cancel flows with analytics | Advanced rules engine, Stripe/Chargebee integration |
| Raaft | Simple cancel flow builder | Easy setup, good for early-stage |
| Chargebee Retention | Chargebee customers | Native integration, was Brightback |
Billing Providers (Dunning)
| Provider | Smart Retries | Dunning Emails | Card Updater |
|---|---|---|---|
| Stripe | Built-in (Smart Retries) | Built-in | Automatic |
| Chargebee | Built-in | Built-in | Via gateway |
| Paddle | Built-in | Built-in | Managed |
| Recurly | Built-in | Built-in | Built-in |
| Braintree | Manual config | Manual | Via gateway |
Related CLI Tools
| Tool | Use For |
|---|---|
stripe | Subscription management, dunning config, payment retries |
customer-io | Dunning email sequences, retention campaigns |
posthog | Cancel flow A/B tests via feature flags, funnel analytics |
mixpanel / ga4 | Usage tracking, churn signal analysis |
segment | Event routing for health scoring |
Related Skills
emails: For win-back email sequences after cancellation
paywalls: For in-app upgrade moments and trial expiration
pricing: For plan structure and annual discount strategy
onboarding: For activation to prevent early churn
analytics: For setting up churn signal events
ab-testing: For testing cancel flow variations with statistical rigor
Files
- ATTRIBUTION.mdAdded by AutoGineer893 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md19.6 KiB
- evals/evals.json8.0 KiB
- references/cancel-flow-patterns.md10.4 KiB
- references/dunning-playbook.md13.7 KiB
references/dunning-playbook.md
Dunning Playbook
Complete guide to recovering failed payments and reducing involuntary churn.
Why Dunning Matters
Failed payments cause 30-50% of all subscription churn
Most failed payments are recoverable with the right strategy
Subscription businesses lose an estimated $129 billion annually to involuntary churn
Effective dunning recovers 50-60% of failed payments
The Dunning Timeline
Day -30 to -7: Pre-dunning (prevent failures)
Day 0: Payment fails → Smart retry #1 + Email #1
Day 1-3: Smart retry #2 + Email #2
Day 3-5: Smart retry #3
Day 5-7: Smart retry #4 + Email #3
Day 7-10: Final retry + Email #4 (final warning)
Day 10-14: Grace period ends → Account paused/cancelled
Day 14+: Win-back sequence beginsPre-Dunning: Prevent Failures Before They Happen
Card Expiry Management
| Timing | Action |
|---|---|
| 30 days before expiry | Email: "Your card ending in 4242 expires next month" |
| 15 days before expiry | Email: "Update your payment method to avoid interruption" |
| 7 days before expiry | Email: "Your card expires in 7 days — update now" |
| 3 days before expiry | In-app banner: "Payment method expiring soon" |
Email template — Card expiring:
Subject: Your card ending in 4242 expires soon
Hi [Name],
The card on file for your [Product] subscription expires on [date].
Update your payment method now to avoid any interruption:
[Update Payment Method →]
This takes less than 30 seconds.
— [Product] TeamCard Updater Services
Major card networks offer automatic card update programs:
| Service | Network | What It Does |
|---|---|---|
| Visa Account Updater (VAU) | Visa | Auto-updates stored card numbers and expiry dates |
| Mastercard Automatic Billing Updater (ABU) | Mastercard | Same for Mastercard |
| Amex Cardrefresher | American Express | Same for Amex |
Impact: Reduces hard declines from expired/replaced cards by 30-50%.
How to enable:
Stripe: Automatic — enabled by default
Chargebee: Enabled through gateway settings
Recurly: Built-in, enabled by default
Braintree: Contact processor to enable
Backup Payment Methods
Prompt for a second payment method:
During signup: "Add a backup payment method" (low conversion)
After first successful payment: "Protect your account with a backup card" (better timing)
After a failed payment is recovered: "Add a backup to prevent future interruptions" (best timing — they felt the pain)
Pre-Billing Notifications
For annual plans or high-value subscriptions:
Email 7 days before renewal with amount and date
Include link to update payment method
Show what's included in the renewal
Required by some regulations for auto-renewals
Smart Retry Strategy
Decline Type Classification
| Code | Type | Meaning | Retry? |
|---|---|---|---|
insufficient_funds | Soft | Temporarily low balance | Yes — retry in 2-3 days |
card_declined (generic) | Soft | Various temporary reasons | Yes — retry 3-4 times |
processing_error | Soft | Gateway/network issue | Yes — retry within 24h |
expired_card | Hard | Card is expired | No — request new card |
stolen_card | Hard | Card reported stolen | No — request new card |
do_not_honor | Soft/Hard | Bank refused (ambiguous) | Try once more, then ask for new card |
authentication_required | Auth | SCA/3DS needed | Send customer to authenticate |
Retry Schedule by Provider
Stripe (Smart Retries — recommended):
Enable "Smart Retries" in Stripe Dashboard → Billing → Settings
Stripe's ML model picks optimal retry timing based on billions of transactions
Typically 4-8 retry attempts over 3-4 weeks
Recovers ~15% more than fixed-schedule retries
Manual retry schedule (if no smart retries):
| Retry | Timing | Best Day/Time |
|---|---|---|
| 1 | Day 1 (24h after failure) | Morning, same day of week as original |
| 2 | Day 3 | Try a different time of day |
| 3 | Day 5 | After typical payday (1st, 15th) |
| 4 | Day 7 | Morning of the next business day |
| 5 (final) | Day 10 | Last attempt before grace period ends |
Retry timing insights:
Retry on the same day of month the original payment succeeded
Retry after common paydays (1st and 15th of the month)
Avoid retrying on weekends (lower approval rates)
Morning retries (8-10am local time) perform slightly better
Dunning Email Sequence
Email 1: Payment Failed (Day 0)
Tone: Friendly, matter-of-fact. No alarm.
Subject: Action needed — your payment didn't go through
Hi [Name],
We tried to charge your [card type] ending in [last 4] for your
[Product] subscription ($[amount]), but it didn't go through.
This happens sometimes — usually a quick card update fixes it.
[Update Payment Method →]
Your access isn't affected yet. We'll retry automatically, but
updating your card is the fastest fix.
Need help? Just reply to this email.
— [Product] TeamEmail 2: Reminder (Day 3)
Tone: Helpful, slightly more urgent.
Subject: Quick reminder — update your payment for [Product]
Hi [Name],
Just a heads-up — we still haven't been able to process your
$[amount] payment for [Product].
[Update Payment Method →]
Takes less than 30 seconds. Your [data/projects/team access]
is safe, but we'll need a valid payment method to keep your
account active.
Questions? Reply here and we'll help.
— [Product] TeamEmail 3: Urgency (Day 7)
Tone: Direct, clear consequences.
Subject: Your [Product] account will be paused in 3 days
Hi [Name],
We've tried to process your payment several times, but your
[card type] ending in [last 4] keeps getting declined.
If we don't receive payment by [date], your account will be
paused and you'll lose access to:
• [Key feature/data they use]
• [Their projects/workspace]
• [Team access for X members]
[Update Payment Method Now →]
Your data won't be deleted — you can reactivate anytime by
updating your payment method.
— [Product] TeamEmail 4: Final Warning (Day 10)
Tone: Final, clear, no guilt.
Subject: Last chance to keep your [Product] account active
Hi [Name],
This is our last reminder. Your payment of $[amount] is past
due, and your account will be paused tomorrow ([date]).
[Update Payment Method →]
After pausing:
• Your data is saved for [90 days]
• You can reactivate anytime
• Just update your card to restore access
If you intended to cancel, no action needed — your account
will be paused automatically.
— [Product] TeamGrace Period Management
What Happens During Grace Period
| Setting | Recommendation |
|---|---|
| Duration | 7-14 days after final retry |
| Access | Degraded (read-only) or full access |
| Visibility | In-app banner: "Payment past due — update to continue" |
| Retry | Continue background retries during grace |
| Communication | Dunning emails continue |
Access Degradation Options
Option A: Full access during grace (recommended for B2B)
Lower friction, customer feels respected
Higher recovery rate (they still see value)
Risk: some customers exploit the grace period
Option B: Read-only access (recommended for B2C)
Can view but not create/edit
Creates urgency without data loss fear
Clear message: "Update payment to resume full access"
Option C: Immediate lockout (not recommended)
Aggressive, damages relationship
Lower recovery rate
Only appropriate for very low-cost plans
Post-Grace Period
| Timing | Action |
|---|---|
| Grace period ends | Pause account (not delete) |
| Day 1 post-pause | "Your account has been paused" email |
| Day 7 post-pause | "Your data is still here" reminder |
| Day 30 post-pause | Win-back attempt with new offer |
| Day 60 post-pause | Final win-back |
| Day 90 post-pause | Data deletion warning (if applicable) |
Provider-Specific Setup
Stripe
Enable Smart Retries:
Dashboard → Settings → Billing → Subscriptions and emails
Enable "Smart Retries" under retry rules
Set failed payment emails in Dashboard → Settings → Emails
Custom retry rules (if not using Smart Retries):
Retry 1: 3 days after failure
Retry 2: 5 days after failure
Retry 3: 7 days after failure
Final: Mark subscription as unpaid after last retryWebhook events to handle:
invoice.payment_failed— trigger dunninginvoice.paid— cancel dunning, restore accesscustomer.subscription.updated— status changescustomer.subscription.deleted— final cancellation
Chargebee
Built-in dunning:
Settings → Configure Chargebee → Retry Settings
Configure retry attempts and intervals
Settings → Configure Chargebee → Email Notifications → Dunning
Dunning options:
Automatic retries with configurable schedule
Built-in dunning emails (customizable templates)
Grace period configuration per plan
Paddle
Managed dunning:
Paddle handles retries and dunning automatically
Limited customization (Paddle manages the relationship)
Paddle Billing webhooks (dot-separated
event_typenames):transaction.payment_failedreports a failed payment attempt. Use itssubscription_idto associate a subscription renewal; a failed one-off transaction is not subscription churn.subscription.past_duereports that the subscription is past due.subscription.canceledreports an effective cancellation. A cancellation scheduled for the next billing period emitssubscription.updatedfirst; retain access according to the current subscription state until that change takes effect.
Configure notification subscriptions for these exact names.
subscription.payment_failedandsubscription.cancelledare not Paddle Billing event types; do not mix Billing webhooks with the separate Paddle Classic alert names.Verify the payment-failure and cancellation contracts before wiring account state changes.
Best for hands-off approach
Recurly
Revenue Recovery:
Configuration → Dunning Management
Set retry schedule per plan
Configure grace period and final action (pause vs cancel)
Advanced features:
Machine-learning retry optimization
Per-plan dunning schedules
Built-in Account Updater
In-App Dunning
Don't rely on email alone. Show payment failures in the app:
Banner Pattern
┌──────────────────────────────────────────────────────┐
│ ⚠ Your payment of $29 failed. Update your card to │
│ avoid losing access. [Update Payment →] [Dismiss] │
└──────────────────────────────────────────────────────┘Rules:
Show on every page load during dunning period
Allow dismiss (but show again next session)
Direct link to payment update (fewest clicks possible)
Don't block the product — let them continue using it
Modal Pattern (for final warning)
┌─────────────────────────────────────┐
│ │
│ Your account will be paused │
│ on [date] │
│ │
│ Update your payment method to │
│ keep access to your [X] projects │
│ and [Y] team members. │
│ │
│ [Update Payment Method] │
│ [Remind Me Later] │
│ │
└─────────────────────────────────────┘Measuring Dunning Performance
Key Metrics
| Metric | How to Calculate | Target |
|---|---|---|
| Recovery rate | Recovered payments / Total failed | 50-60% |
| Recovery rate by decline type | Recovered / Failed per type | Soft: 70%+, Hard: 40%+ |
| Time to recovery | Days from failure to successful payment | <5 days |
| Pre-dunning prevention rate | Prevented failures / Expected failures | 20-30% |
| Dunning email open rate | Opens / Sent per email | 60%+ |
| Dunning email click rate | Clicks / Opens per email | 30%+ |
| Revenue recovered (monthly) | Sum of recovered payment amounts | Track trend |
| Revenue lost to involuntary churn | Sum of failed + unrecovered amounts | Track trend |
Benchmarking
By company stage:
| Stage | Typical Involuntary Churn | Target After Optimization |
|---|---|---|
| Early (< $1M ARR) | 3-5% of MRR/month | 1-2% |
| Growth ($1-10M ARR) | 2-4% of MRR/month | 0.5-1.5% |
| Scale ($10M+ ARR) | 1-3% of MRR/month | 0.3-0.8% |
ROI Calculation
Assumed failed invoice amount: $10,000/month
Baseline collected amount: 30% ($3,000/month)
Scenario collected amount: 60% ($6,000/month)
Additional recovered cash: $3,000/month
If repeated for 12 months: $36,000/year
Assumed incremental tooling cost: $200-500/month
Recovered-revenue / tooling ratio: 6-15x
After tooling alone / tooling cost: 5-14x (500-1,400%)The 6–15x is recovered cash ÷ tooling cost. Net of tooling it is 5–14x ((3,000 - 500) / 500 = 5; (3,000 - 200) / 200 = 14), before labor and payment fees. Validate the 60% recovery target against your own baseline. See gross versus net profit.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Corey Haines
- Publisher
- Corey Haines (Community)
- Source
- coreyhaines31/marketingskills · skills/churn-prevention · commit 96798cf
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Corey Haines or Corey Haines.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download churn-prevention.zip