Dunning Management: Recovering Revenue Before It Becomes Churn

A failed payment is not a lost customer yet. It is a Signal that lands in a queue, and what happens in the days after it lands determines whether that Account recovers quietly or shows up next month as a churn number nobody can explain. Dunning management is the program that decides which outcome you get - not a single retry setting, but a designed sequence of attempts, messages, and escalations built around how issuers, customers, and payment behavior actually work.

Our companion post on involuntary churn covers what failed-payment churn is and roughly how much of total churn it represents. This post goes one level deeper: how to actually design and run the program, who owns it, and what to measure. A more tactical retry-schedule playbook is planned as a follow-up for teams that want attempt-by-attempt configuration detail.

Key takeaways

• Soft declines and hard declines need different sequences - retrying a hard decline wastes attempts and risks a fraud flag.
• Retry timing should respect issuer limits and payday cycles, not just "retry more often."
• Pre-dunning (card-expiry notices, account updater) prevents failures instead of recovering them after the fact.
• The message ladder should escalate from neutral to urgent without shaming the customer.
• Grace period, downgrade, and read-only mode are three different responses to a lapsed payment - pick deliberately.
• Billing/RevOps owns the automated sequence; high-ARR Accounts should hand off to a CSM.
• Recovery rate by attempt, days-to-recover, revenue recovered, and false-positive cancellations are the metrics that matter.

How should soft declines and hard declines be handled differently?

A soft decline is temporary: insufficient funds, an issuer rate limit, a network timeout, or a card processor briefly unreachable. The same card frequently succeeds on a later attempt with no customer action needed. A hard decline is permanent: the card was reported stolen, the account is closed, or the issuer has flagged the card as invalid. Retrying a hard decline on the same schedule as a soft decline does two things wrong - it burns retry attempts that could have gone toward genuinely recoverable Accounts, and repeated attempts on a dead card can trigger issuer fraud review, which makes the customer's next legitimate payment harder, not easier.

The practical fix is reading the decline code your processor returns and branching the sequence on it, rather than running every failure through one retry ladder. Most gateways expose enough detail to make this distinction at the code level; if yours doesn't, treat any decline that repeats on a second attempt as effectively hard and move straight to a payment-update message.

What does a sane retry schedule actually look like?

The instinct is to retry aggressively - miss a payment, chase it hard. That instinct is usually wrong. Card issuers apply their own retry limits and can flag an account for excessive same-day attempts, and same-day repeats rarely succeed anyway since the underlying cause (insufficient funds, a temporary hold) hasn't changed within hours.

A more durable pattern:

1. Immediate or next-day retry - catches transient network or processor errors.
2. Day 3 retry - gives time for a balance to refresh or a temporary hold to clear.
3. Day 7 retry - aligns loosely with weekly pay cycles for many consumers and SMB owners.
4. Day 14 retry (final automated attempt) - aligns with biweekly pay cycles and marks the point where the sequence should escalate rather than repeat.

Recurly's own retry-logic documentation frames this the same way: intelligent retry systems vary timing per transaction rather than applying one fixed interval to every failure, because the right gap depends on the decline reason and the issuer.

What is pre-dunning, and why does it matter more than the retry itself?

Pre-dunning happens before a payment fails at all. The most common trigger is a stored card approaching its expiration date - most cards expire every three to four years, and without a warning, the customer's first sign of trouble is a canceled subscription, not a heads-up email.

Two pre-dunning mechanisms do most of the work:

• Expiry notice emails: sent 30 days and again 7 days before a stored card expires, with a direct link to update payment - no login wall, see below.
• Network account updater: a service offered by Visa and Mastercard that automatically refreshes stored card numbers when a card is reissued, so a class of failures never reaches the customer at all.

Billing vendor Recurly markets a 25% average recovery rate for dunning on its own platform - a self-reported figure about one vendor's customer base, not an industry benchmark. Either way, the mechanisms that prevent a failure from happening in the first place - expiry notices and account updater - avoid the recovery problem entirely rather than solving it after the fact.

How should the message ladder escalate without shaming the customer?

The tone of a dunning sequence should move from neutral to urgent across the sequence, never from urgent to accusatory. A first-attempt email that reads like a collections notice trains customers to associate your product with anxiety before they've even had a chance to fix a routine card issue.

A workable ladder:

• First failure: neutral, informational. "We couldn't process your payment - here's how to update it." No urgency language.
• Second failure: slightly more direct. Mention the retry schedule and what happens if it isn't resolved.
• Final notice: clear deadline and clear consequence (grace period ending, feature downgrade, or read-only mode), stated plainly - not as a threat.
• Post-lapse: a single win-back message once the Account has actually downgraded or gone read-only, distinct in tone from the active-dunning messages.

Pair every email with an in-app banner for logged-in admin users - many payment failures go unnoticed in email because the notification lands in a shared or unmonitored inbox.

Grace period, downgrade, or read-only mode - which response fits?

These are three different consequences for a lapsed payment, and conflating them is a common mistake:

1. Grace period: the Account keeps full access for a defined window (commonly 7-14 days) while retries and messages run. Best default for most B2B SaaS - it protects the relationship while the payment issue resolves.
2. Read-only mode: the Account can view data but not create or modify it. A middle option for products where full lockout causes disproportionate damage (data tools, dashboards) but continued write access isn't warranted for an unpaid Account.
3. Immediate downgrade or suspension: access drops right away. Appropriate mainly for low-ARR, self-serve, month-to-month Accounts where the cost of a false-positive cancellation is low and automation needs to run without exceptions.

Matching the response to the Account's value and contract terms - not applying one policy universally - is what keeps the false-positive cancellation rate low.

How much friction should the self-serve update link have?

None that you can remove. A payment-update link that requires the customer to log in first is one of the most common - and most fixable - leaks in a dunning program. Many customers who get a failed-payment email are not sitting logged into your product; they're on their phone, reading an email between meetings. A tokenized, one-click link straight to a payment-update form (no password, no session) converts materially better than a link that dead-ends at a login screen.

If your billing provider supports a hosted update page with a secure token, use it. If it doesn't, that's worth fixing before optimizing anything else in the sequence - the best-timed retry schedule in the world doesn't matter if the recovery path itself has a login wall in front of it.

Who should own the dunning program, and when does a CSM get involved?

Automated dunning - the retry schedule, the email ladder, the in-app banners - is a systems problem, and it's typically owned by Billing or RevOps. It should run without a human touching each case.

But automation has a ceiling. Once an Account crosses an ARR threshold you define, or has been through the full automated sequence without recovering, it should hand off to a CSM rather than sit in the queue until it lapses. A CSM reaching out directly - "I noticed your payment didn't go through, is everything okay on your end?" - solves problems automation can't: a company card that was intentionally canceled during a vendor review, a champion who left and no one updated billing contacts, or a budget freeze that a human conversation can navigate but an email cannot.

What should you actually measure?

Recovery rate alone is a weak signal on its own - it can look healthy while your grace period is quietly too generous or too short. Track these together:

• Recovery rate by attempt number: which retry in the sequence is actually recovering payments. If attempt 1 recovers most of them, later attempts may be low-value and worth shortening.
• Days-to-recover: how long an Account sits in a failed-payment state before paying. A long tail here means customers are discovering the problem late, which points back to messaging, not retry timing.
• Revenue recovered: the dollar total the sequence saves, tracked against total failed-payment volume, so leadership sees dunning as a revenue function, not just an ops task.
• False-positive cancellations: Accounts that were downgraded or canceled but would have paid given more time or a different channel. This is the metric most programs don't track and the one that reveals whether the grace period and escalation ladder are actually calibrated.

A dunning program is never really finished - issuer rules change, card networks update their retry guidance, and your own Account mix shifts over time. Which of these gaps - decline-type branching, pre-dunning coverage, or the CSM handoff threshold - is missing from your current setup?