When a subscription business decides to "fix dunning," the first meeting is almost always about email copy. Subject lines get workshopped. Somebody reads a competitor's reminder sequence aloud. This is understandable — copy is the visible part — and it is also why so many dunning improvements disappoint. The emails sit at the end of a pipeline of decisions made elsewhere: how failures are classified, when attempts fire, what the subscriber sees in the product, and how success is counted. Manage the pipeline and the copy mostly writes itself. Manage only the copy and you have decorated a leak.
The pipeline, in the order failures experience it
A failed renewal passes through five stations. Classification: what kind of failure is this — transient, credential, authentication, terminal? Scheduling: given that class, when are attempts worth making, and how many? Subscriber contact: does this class need a human in the loop, and if so, at what point in the schedule? Access policy: what happens to the account while the clock runs — full access, grace, hard stop? Measurement: when money arrives, which station gets the credit? Every dunning disappointment I have ever audited traced back to one station being run on defaults while the team polished another. The classic case is beautiful emails attached to a schedule that burns all its attempts in 48 hours on subscribers whose problem is a payday that has not happened yet.
Management means owning the interfaces
The stations fail at their borders. Retries fire while a "we're working on it" email is still in the subscriber's inbox, so the card gets charged after they already updated it — or the email promises a retry date the scheduler does not honor. The account updater refreshes a card overnight and nobody tells the dunning sequence, which keeps sending increasingly urgent messages about a problem that no longer exists. Dunning management, as a discipline, is mostly the unglamorous work of making these systems aware of each other: one calendar per failed payment, one source of truth for its state, every actor reading from it. A structured walkthrough of dunning management as an end-to-end practice lays the stations out with the checks that belong at each border.
What good looks like from the outside
From the subscriber's chair, well-managed dunning is nearly invisible: a quiet fix when the card updates itself, one clear message when action is needed, a fair amount of time to act, and no surprises. From the operator's chair it looks like a boring dashboard: failures by class, recoveries by cause, a number for how much revenue is currently inside the window. Boring is the aesthetic of a system under management. Drama — the monthly scramble, the heroic manual saves — is the aesthetic of its absence.
The meeting that replaces the scramble
Managed dunning also changes the calendar. Instead of a quarterly panic when churn prints badly, the operating rhythm is a short monthly review of five numbers: failures by class, recovery rate by class, median days-to-recovery, revenue currently inside the window, and the share of cancellations that began as payment failures. Trends in those five numbers tell you which station needs work next month, and they make the copy meeting — when it finally happens — a discussion about a specific class of subscriber in a specific situation, which is the only kind of copy discussion that ever produced a good email. Systems do not remove judgment from dunning. They aim it.
Start at whichever station your failure file indicts. Just do not start at the subject lines.
Swipe Again publishes systems notes on recovery operations for subscription businesses.
Top comments (0)