The 7-stage dunning sequence I run on every SaaS engagement.

The sequence runs from T-3 (a pre-decline notification for cards you know are about to expire) through T+7 (final notice with a grace-period offer). Each stage stacks on the one before it, and skipping any of them leaves recoverable revenue on the table.

Stage 1: Pre-decline notification (T-3 days for known card expiry).

Most of your failed payments are knowable in advance because cards expire on a date thats already sitting in your billing system. A pre-decline notification three days before expiry (something like “your card on file expires in 3 days, heres a one-click update link”) prevents the decline from happening in the first place. Trigger: card_expires_at minus 3 days. Message: low-key, transactional, with a card-update CTA. Suppression: skip if the user already updated the card or paused the subscription. Success metric: percentage of expiring cards that update before the renewal date. Best-in-class is 30-50% pre-update when you surface this cleanly.

Stage 2: Soft retry (immediate).

When the initial payment fails, your payment processor will automatically retry based on the decline reason. No message goes out yet, it all happens at the processor layer. If the retry succeeds (often because of a temporary network issue or a temporary card hold), the user never knows the decline happened. Trigger: payment_failed event. Success metric: percentage of declines recovered by soft retry alone. Industry benchmark is 5-15% of declines clearing on the first soft retry.

Stage 3: Branded recovery email (T+0).

When soft retry fails, the user gets the first branded recovery email. Message angle matters a lot here. You want matter-of-fact (“we couldnt charge your card, lets fix that”) rather than punitive language that treats them like theyve done something wrong. Include the specific decline reason if you have it (insufficient funds, expired card) and provide a one-click card-update flow that doesnt require login. Suppression: skip if the soft retry already cleared. Success metric: percentage of T+0 emails leading to a card update or successful retry within 24 hours.

Stage 4: Smart retry (intelligent timing).

Static retry (try every 24 hours for 3 days, give up) is the default in most billing systems and its the wrong policy for most decline reasons. Smart retry uses the decline reason to time the next attempt. Insufficient-funds declines recover best when retried 2-3 days out, after a typical payday cycle. Soft declines from network issues recover best with same-day retry within hours. Hard declines from closed accounts or fraud flags shouldnt retry at all, they need to escalate directly to the user. The retry logic compounds with the email cadence because each retry attempt that fails triggers the next email in the sequence. Full mechanics in the next section.

Stage 5: Recovery push (T+3, urgency framing).

Three days after the first failed payment, send a second email with sharper urgency framing. The angle shifts from “lets fix this” to “your account will lose access in N days.” Include the specific cutoff date, provide the same one-click card-update flow, and add a small list of features the user is about to lose access to. The loss-aversion framing helps here. Suppression: skip if the card has been updated or a retry has cleared. Success metric: recovery rate from T+3 push.

Stage 6: CSM or account-manager touch (high-ACV only, T+5).

For accounts above an ACV threshold (typically $5K/year and up), a human touch at T+5 is justified by the unit economics. Your CSM or AM reaches out via email, in-app message, sometimes phone, with a supportive angle (“we want to keep this working for you, anything we can do?”) rather than anything collections-flavored. For low-ACV accounts you skip this stage because the cost of CSM time exceeds the contribution margin of the recovered subscription.

Stage 7: Final notice plus grace-period offer (T+7).

Seven days after the initial failed payment, the user gets a final notice that the account will be suspended in N days unless the payment clears. Include the grace-period offer if your billing logic supports it, whether thats a one-time pause-and-return option, a free month at the lower tier, or a one-click downgrade flow. The grace-period offer recovers a meaningful subset of users who would otherwise cancel out of frustration. Success metric: final-stage recovery rate plus pause/downgrade conversion.

Across all seven stages, a well-designed dunning sequence recovers 30-40% of failed payments. Thats the operating range I see on shipped builds. Below 25% recovery means stages are missing or misconfigured. Above 50% is unrealistic because some failed payments are genuinely uncollectable.

Worth being explicit about the boundary because dunning programs often get scoped to cover problems they cant actually touch.

Dunning cant fix voluntary churn. Users who consciously decided to cancel (usage dropped, product fit changed, budget cut) arent a dunning problem, theyre a lifecycle or product problem. Running dunning sequences against voluntary cancellations is intrusive and damages trust. Suppress these users from the recovery sequence at the cancellation event.

Dunning cant fix product-fit churn. If users churn because the product doesnt deliver value, no payment-recovery sequence saves them. The voluntary cancellation will happen at the next renewal regardless of whether the current renewal payment cleared. Dunning is a recovery mechanism for users who still want the product but couldnt pay, which is a different problem from users who decided to leave.

Dunning cant fix sustained billing-system issues. When your payment processor is having outage problems, your dunning emails are technically correct but operationally damaging because the user sees “your payment failed” messaging when the failure was actually on your end. Monitor your processor health metrics and suspend dunning sends during sustained outage windows.

The honest scope of a dunning program is the involuntary portion of churn. Voluntary churn lives in lifecycle, product, and CSM territory. The churn analysis cornerstone covers the intervention matrix for voluntary archetypes, and the cohort retention curves cluster covers how to read which archetype youre actually dealing with.