Most dunning setups go live the way most monitoring goes live: someone enables it on a Friday, watches nothing break over the weekend, and declares it done. The failures this creates are quiet ones. The emails send, but from a domain whose authentication was never finished, so half of them land in spam. The retries run, but on the processor's default schedule, which retries a payday problem on the three days before payday. The card-update page works, but nobody tested it on a phone, where most recipients will open it. Nothing crashes. The system simply recovers a fraction of what it should, indefinitely, and the shortfall looks like the natural failure rate.
Working through a launch checklist for dunning before the first real failure arrives in order, rather than from memory, catches these in the only cheap week to catch them. Start with deliverability, because every later item depends on the messages arriving: sending domain authenticated, a reply address a human actually reads, and a test message opened on a real phone and a real desktop client. Then the retry schedule itself, written down per decline family — soft declines on a timed ladder, insufficient-funds attempts aimed at paydays, hard declines taken out of the retry pool entirely and routed straight to a card-update request. A schedule that exists only inside a settings screen, undocumented, will be a mystery to whoever inherits it.
Test the unhappy paths deliberately. Decline a test card and follow your own sequence as a customer: does the first email arrive while the failure is still fresh, does it say plainly what happened and what to do, does the update page accept the new card without an account password nobody remembers? Then test the paths nobody thinks of as dunning at all. A customer who updates their card in response should stop receiving reminders within the hour, not get one more apologetic email tomorrow. A customer who cancels mid-sequence should exit the sequence immediately — chasing a cancelled account for money is the fastest way to turn a neutral departure into a chargeback and a story they tell other people.
Decide the counting rules before the first recovery, not after the first argument about them. Which pool is the denominator — every failure, or only the workable ones? What window closes a case, and what happens to a payment that lands after it? Does a customer who pays through an ordinary support conversation count the same as one the sequence recovered? None of these answers matter as much as having them written down, because the first month's number becomes the baseline every later month is judged against, and a baseline built on unstated rules cannot be compared to anything.
Add one item most checklists omit: agree, in writing, who owns the queue each week. Dunning fails organisationally more often than technically — a pile of cases needing a human decision, a support inbox where billing replies wait behind product questions, a schedule nobody feels authorised to adjust. Name the owner, name the backup, and give them explicit permission to change timing, wording, and grace handling when the evidence asks for it. A system everyone assumes is someone else's job decays silently, one unreviewed week at a time, until its numbers are indistinguishable from having no system at all.
Finally, schedule the review while the launch energy is still there. Thirty days out, read a sample of actual sequences end to end — not the aggregate rate, the individual stories: where this customer was contacted, what they saw, when they acted or did not. Aggregate rates tell you whether the system works. Individual sequences tell you why, and the why is where the next improvement lives. A launch is not the moment dunning is finished. It is the moment it becomes measurable, and a checklist is how you make sure the thing being measured is the thing you meant to build.
Published by Swipe Again, the flat-fee failed payment recovery service for subscription businesses.
Top comments (0)