Failed payments are the largest leak in most subscription P&Ls. Depending on card mix and geography, 6–12% of recurring charges fail each cycle, and roughly half of those customers churn silently — not because they wanted to leave, but because no one followed up in the right way at the right time.
This playbook is the exact system Revenue Recovery Labs runs for its own customers. It is opinionated, engineering-first, and designed for teams who want to treat recovery as a product, not a "dunning setting" buried inside a billing tool.
# Why failed payments are a product problem, not a billing problem
Payment providers see the transaction. They do not see the customer. Their default recovery flow is a retry schedule — the same three or four attempts for every failure code, every plan, every geography, every risk segment. That approach recovers something. It does not recover well.
An AI-native recovery system treats each failed payment as a triage problem:
- What actually failed? Insufficient funds is not the same as a 3DS challenge is not the same as a hard decline.
- Who is this customer? A high-value annual renewal is not a $9 monthly.
- What channel do they respond to? Email, WhatsApp, SMS, in-app.
- What tone works for them? Reassuring for a long-time customer, direct for a first-charge failure.
Doing this by hand at scale is impossible. Doing it well at scale is what AI is finally good at.
# The four-stage cadence that actually works
RRLabs' default cadence is deliberately simple. Complexity kills recovery.
| Step | Timing | Channel | Purpose |
|---|---|---|---|
| T0 | Immediate | Notify + one-tap update-payment link | |
| T1 | +24h | Reframe: what's affected, what to do | |
| T2 | +72h | WhatsApp or Email | Human-tone reminder, retry manually |
| T3 | +7d | Last attempt, offer help, offer pause |
Every step is AI-generated per customer, not a template with {{first_name}} swaps. The model has:
- The failure reason code and its retry status.
- Plan, MRR, tenure, historical payments.
- Product context (what the customer uses).
- The workspace's brand voice guardrails.
Don't chase the perfect long cadence. The gains after step four are marginal, and the deliverability cost is high. Recovering revenue at T0–T3 with excellent copy beats recovering at T5–T7 with mediocre copy every time.
# Message generation: three rules that matter
One. Lead with what the customer needs, not what you need. "We couldn't renew your plan" is inferior to "Your dashboards were about to pause — here's a one-tap link to keep them running." The first is a company problem. The second is a customer problem the company is helping to solve.
Two. Match tone to failure type. Insufficient funds is embarrassing. Hard decline is scary (was my card stolen?). Expired card is routine. If your copy treats all three the same, all three underperform.
Three. Never lie about urgency. "Your account will be deleted in 24 hours" recovers short-term and destroys trust long-term. AI is very good at drafting genuinely urgent copy when the situation genuinely warrants it — and equally good at soft nudges when it doesn't.
# Deliverability is the silent killer
The best-written recovery email that lands in spam is worse than a mediocre one that lands in the primary inbox. Non-negotiables:
- Dedicated sending domain and subdomain for recovery mail (
billing.yourcompany.com). - SPF, DKIM, DMARC correctly aligned. DMARC at
p=quarantineminimum. - Warmup for any new sending IP or subdomain — never blast cold.
- Suppression list honored across every step and every workspace.
- Reply-to a real inbox, monitored, with an SLA under 4 business hours.
If you are using the same domain for marketing sends and recovery sends, your recovery mail is being suppressed by marketing engagement metrics. Separate the streams.
# Measuring recovery correctly
The metric most tools report is recovery rate: recovered attempts ÷ failed attempts. It is directionally useful and easy to game.
Track these instead:
- Recovered ARR / MRR, not attempts. Weighted by plan value.
- Time-to-recovery, p50 and p90. Fast money is more valuable than slow money.
- Recovery by failure code. Insufficient funds should recover very differently than hard decline.
- Recovery by tenure bucket. Retaining a 3-year customer is worth more than retaining a 3-week customer.
- Involuntary churn rate, cohorted. This is the number that shows up on the board deck.
# What "good" looks like
For a well-run SaaS with average card health:
- Recovery of 30–45% of failed dollars by day 7.
- Involuntary churn under 0.7% of active MRR per month.
- Time-to-recovery p50 under 24 hours.
- Reply rate on recovery mail 6–10% (a real human read it and cared enough to respond).
If any of those numbers surprise you as achievable, the gap is likely in copy quality or deliverability — not in your cadence structure.
# Where to start this week
- Segment failed payments by code, plan value, and tenure. Look at the last 90 days.
- Rewrite the first two steps of your cadence, per segment, using AI-generated copy that a human editor has approved.
- Move recovery mail to a dedicated subdomain, warm it, and set DMARC.
- Instrument the four metrics above. Baseline this month. Measure next month.
That's the whole playbook. Everything else is refinement.
This article is part of the RRLabs Playbooks series. For a hands-on walkthrough with your own Stripe data, start a workspace — no card needed.