Every subscription business already has dunning management. It just usually lives in one person's head: the founder who remembers that annual plans get a longer grace period, the support lead who knows which email tone makes subscribers update cards instead of cancelling, the engineer who set the retry schedule two years ago and has not looked at it since. The software question is not whether to manage dunning. It is whether that management survives the person who carries it.
What the head-held version quietly costs
Head-held dunning fails in boring ways. A retry schedule tuned for monthly plans gets applied to annual ones, where a single failure is worth twelve times more and deserves a completely different tempo. A card-update email written during a brand refresh goes out with the old link for a month. Nobody notices either, because failed payments do not complain — they just leave, and the exit survey says "too expensive" or nothing at all.
The deeper cost is that nothing is measured as a system. Individual emails get opened and clicked, individual retries succeed or fail, but nobody owns the number that matters: of the renewals that failed this week, how many are subscribers again, and how long did it take? Without that number reviewed on a rhythm, every dunning decision is an anecdote competing with another anecdote.
The management layer, concretely
Strip it down and managing dunning is four recurring jobs. Watching the queue: failures by cause, by plan, by age, reviewed weekly while they are still recoverable. Tuning the schedule: retry timing and message order adjusted when the mix changes — a new acquisition channel with thinner card balances is a dunning event, not just a marketing one. Guarding the tone: every outbound touch read as a subscriber reads it, mid-busy-day, possibly annoyed at the interruption. And reconciling the count: one recovery rule, applied the same way every month, so a good month means something.
Tools enter here, not before. The category usually labelled dunning management software is really the attempt to give those four jobs a home: the queue visible, the schedule editable without a deploy, the messages reviewable, the count kept honestly. Judged that way, feature lists matter less than whether the weekly review actually happens inside the tool or still depends on someone remembering to export a spreadsheet.
A thirty-minute version that works
You do not need a platform migration to start; you need a standing half hour. Same time each week, same four questions. What failed, and what kind of failure was it? What came back, and through which touch? What is still open and ageing past the point where recovery is realistic? What one thing changes before next week — one retry moved, one subject line rewritten, one plan given its own grace period?
Write the answers down where the next person can find them. That document, more than any dashboard, is the difference between dunning as a settings page somebody configured once and dunning as a managed part of the business. Software earns its fee when it makes that half hour easier to run and harder to skip — when the queue, the schedule, and the count are already assembled and waiting, and the meeting is about decisions instead of archaeology.
The businesses that recover well are rarely the ones with the cleverest single email. They are the ones where somebody looks, every week, on purpose.
Notes on running that review — and the tooling behind it — are kept at Swipe Again.
