Dunning Isn't a Nagging Problem. It's a Diagnosis Problem.

Most companies treat failed payments like a behavior issue. Send a nicer email. Send it sooner. Send it three times instead of two. As if the customer just needs a gentle nudge to remember they owe you money.

That's not what's happening. Most of the time, the customer didn't do anything wrong.

Here's the number that should reframe how you think about this: a large chunk of what gets logged as "voluntary churn" is actually involuntary churn wearing a disguise. The subscription didn't fail because the customer wanted out. It failed because a card expired, a bank's fraud model got twitchy, or a temporary balance hiccup collided with your billing date at exactly the wrong moment. None of that is a retention problem. It's a plumbing problem that gets misfiled as a retention problem, and then someone in a strategy meeting builds a whole narrative around "customers losing interest" that isn't even true.

I wrote about retention recently as a design problem, not a willpower problem. Dunning is the same story, one layer down. You're not trying to convince someone to stay. You're trying to get a transaction to actually clear.

The mistake: treating every decline the same

A decline code is not a verdict. It's a diagnosis. And most dunning systems ignore it completely.

Insufficient funds, expired card, and suspected fraud are three completely different problems that require three completely different responses. Retry an insufficient funds decline at 3am three days later, after payday, and it often just works. Retry it five minutes later and you're not solving anything, you're just annoying the issuing bank and burning your own retry budget. Retry a "do not honor" fraud flag on any schedule and you're wasting everyone's time, because that card isn't going to clear until the cardholder calls their bank directly.

Smart retry logic reads the decline code before it decides what to do next. Timing follows the failure type, not a fixed calendar. That single shift, from a blind retry schedule to a diagnosis driven one, recovers more revenue than almost any copy change to your emails.

The other mistake: outsourcing the fix to the customer

The instinct is always to write a better email. Softer tone, more urgency, a discount thrown in to smooth it over. And email matters, don't get me wrong. But email is the layer you reach for last, not first, because it puts the entire burden of solving a technical failure onto a person who doesn't know what a decline code is and shouldn't have to.

Before you write a single word of copy, ask what you can fix without involving the customer at all. Network account updater services that refresh expired card data automatically. Retry logic that's actually reading the failure reason. Routing that gives a transaction a second shot through a different path before it ever becomes "past due" in anyone's inbox.

The best dunning flow is the one the customer never notices, because the payment just quietly resolved itself before it became their problem.

Where the email actually earns its place

Once you've done everything possible on the infrastructure side, the remaining failures are the ones that genuinely need a human decision: an expired card that needs a new number, a fraud hold that needs a phone call, a subscription the customer is actually done with. That's a much smaller pile than most companies think, and it's the only pile where a well-timed email does real work.

Write it like you're explaining a real problem to a real person, because you are. Say exactly what failed and exactly what to do about it. Skip the guilt, skip the "we miss you," skip anything that sounds like it's competing for their attention instead of solving their problem.

The reframe

Dunning done well isn't just a communications strategy. It's closer to error handling in a system that happens to have a customer relationship attached to it. Fix the plumbing first. Let the email carry the load it was actually built for, instead of the load you handed it because building better retry logic felt harder than writing a nicer subject line.