Why Dunning Tools Fail (And What to Do Instead)
Most dunning tools fail not because the technology is wrong but because the implementation skips the four steps that actually move the needle. Here is what those steps are.
Contents
Most subscription businesses that implement a dunning tool do not get the recovery rates the vendor promised. The tool is running. Emails are sending. Retries are firing. Recovery is still at 35 percent.
The problem is almost never the tool. It is the implementation. Four specific gaps account for most of the underperformance.
Gap 1: Treating all declines the same
The most common dunning implementation routes every failed payment into the same sequence: retry on day 3, email on day 5, retry on day 7, email on day 10, cancel on day 21.
That sequence is wrong for most of the failures it handles.
A lost_card decline will not succeed on a retry on day 3. Or day 7. Or any day. The card is gone. The right response is an email on day 1 asking for a new card, not silent retries burning through your retry budget.
An insufficient_funds decline on the 3rd of the month will likely succeed on a silent retry on the 5th or 6th after payday, without any email at all. Sending an alarming "please update your card" email on day 5 creates friction for a customer whose funds arrived on day 4 and who has no idea there was a problem.
A generic_decline wants a 24-hour retry, not a 3-day wait. The temporary condition that caused it usually clears within a day.
Every decline code has a different optimal response. A single sequence handles none of them optimally. The four decline categories each require a completely different approach.
The fix: classify decline codes on the webhook and route to code-specific sequences. Soft declines get retry-first. Hard declines get email-first. Card data errors get immediate email with a payment update link.
Gap 2: Emails that read like a billing system
The industry average email open rate for dunning emails is 20 to 30 percent. The average click-through rate on the "update your payment method" link is around 10 percent. Those numbers are mediocre, and they are mediocre because most dunning emails look like they came from a payment processor, not a person.
"Your payment for [COMPANY NAME] in the amount of [AMOUNT] has failed. Please update your payment method at the following link."
That email gets ignored. It reads like spam. It does not tell the customer anything useful about why their payment failed. It does not use their name. It does not reference their account. It does not sound like anyone who knows them wrote it.
Customers who get an email that reads like it came from a person respond at meaningfully higher rates. The message should be short, direct, and human. It should acknowledge the problem without alarm. It should make the update as frictionless as possible.
The fix: write dunning emails in the merchant's brand voice. Reference the customer's name and subscription. Keep the message to two or three sentences. Link directly to a pre-authenticated payment update page, not a login page.
Gap 3: No coordination between retries and emails
A retry fires on Tuesday. It succeeds. An email scheduled for Wednesday asks the customer to update their card. The customer is confused and annoyed. They just paid. Why is the company telling them their payment failed?
The reverse is also common: an email fires on day 5 asking the customer to update their card, creating urgency. A retry fires on day 7 and succeeds. The customer updated their card for no reason and the duplicate charge creates a support ticket.
Uncoordinated retry and email timing produces bad customer experiences and erodes trust in exactly the customers you are trying to retain.
The fix: the retry schedule and email schedule must be aware of each other. A successful retry cancels pending emails. A failed email delivery (hard bounce) triggers an account flag. The two systems need to be one system.
Gap 4: Starting too late in the failure window
The first 48 hours after a payment failure are when soft declines are most likely to resolve. A generic_decline that clears on a 24-hour retry never becomes a dunning problem. An insufficient_funds decline that resolves on a 3-day retry near payday never requires a customer email.
Most dunning tools wait too long before the first retry. A 3-day default retry window, which is common, misses the 24 to 48 hour window where many soft declines resolve on their own. The missed window means more failures escalate to email, more customers are unnecessarily contacted, and recovery rates are lower than they could be.
The fix: the first retry for soft declines should fire within 24 hours. Not 3 days. Not 5 days. Within 24 hours, silently, before any customer contact.
What good dunning looks like
Good dunning is:
- Decline code aware from the first webhook event
- Retry-first for soft declines, email-first for hard declines, and card data errors
- Coordinated so retries and emails do not conflict
- Written in a human voice, not a billing system voice
- Proactive before expiry, not just reactive after failure
- Tracked by decline code so you can see what is working and what is not
The businesses that hit 70 to 80 percent recovery rates are doing all six. The businesses at 35 percent are usually missing at least three.
- Why is my dunning tool not recovering enough revenue?
- The most common causes are treating all decline codes the same, generic emails that get ignored, uncoordinated retry and email timing, and waiting too long before the first retry.
- What is the right timing for the first retry after a payment failure?
- For soft declines like generic_decline and do_not_honor, the first retry should fire within 24 hours. For insufficient_funds, 2 to 3 days timed near payroll. Hard declines should not be retried at all.
- How much does email tone affect dunning recovery rates?
- Significantly. Customers who receive emails that read like they came from a person respond at materially higher rates than customers who receive generic billing system emails. Short, direct, human-voiced messages outperform templates.
- What recovery rate should I expect from a well-implemented dunning system?
- 60 to 80 percent with intelligent retry timing and email sequences combined, based on industry benchmarks from Recurly, Churnkey, and Chargebee. Businesses at 35 percent are typically missing one or more of the four gaps described above.