Ask five subscription operators how long a dunning cycle should run and you will get five answers, each delivered with total confidence: three days, a week, two weeks, a month, until the next billing date. The confidence is the tell. Almost nobody derived their number from their own recovery data, because almost nobody has recovery data organized by day-since-failure. The number came from a default setting, a competitor's help doc, or a feeling that longer must mean pushier.
Here is the measurement that settles it for your own book. Take the last two quarters of failed renewals that eventually recovered, and plot them by the day the money actually arrived. Every business I have seen do this finds the same shape: a heavy cluster in the first few days, a long and surprisingly productive tail through the second week, and then a thin trickle that stretches — mostly on the strength of monthly paydays — toward day thirty. The shape is not the answer by itself, but it turns an argument about taste into an argument about arithmetic: what does day seventeen buy you, in recovered subscriptions, against what it costs in messages sent and goodwill spent?
Two clocks run underneath that curve, and they explain its shape. The first is the customer's money clock. A large share of soft declines are calendar accidents — the renewal landed two days before payday, or inside the gap between a card replacement being mailed and activated. Those resolve on the customer's schedule, not yours, and a cycle shorter than a pay period structurally abandons them. The second clock is access. How long a failed subscriber keeps using the product during dunning changes what the messages are: with access, you are reminding; without it, you are negotiating a return, and the tone, spacing, and finality of the sequence should change with the access policy, not drift independently of it.
day 0 failure lands; first note is informational, not alarmed
days 1-4 dense cluster of recoveries; light-touch attempts
days 5-14 the productive tail; payday spacing matters most here
days 15-30 thin trickle; monthly-payday cases only; wind down
day ~30 final notice, defined end, door left open
A worked example makes the trade concrete. Take a book where the day-by-day plot shows 55 percent of recoveries landing by day four, another 30 percent by day fourteen, and 10 percent more by day thirty. A three-day cycle keeps the first cluster and forfeits most of the rest — roughly forty cents of every recoverable dollar, surrendered to a setting. A thirty-day cycle keeps nearly everything but sends three more messages to the 5 percent who will never pay. Read that way, the question stops being "how long is too long" and becomes "what is the last week of this window buying, per message sent" — a question with a numerical answer in your own data.
The failure mode at the short end is obvious — money left on the table. The failure mode at the long end is quieter. A cycle that drags past the point of plausible recovery keeps a dead subscription in a half-alive state: support answers its tickets, the customer receives increasingly apologetic mail about a service they have mentally cancelled, and your failure statistics stay inflated by cases that were never recoveries-in-progress. Cutting the cycle is partly an editorial decision about when a business relationship is actually over.
My working rule, after running this plot a few times: let the cycle breathe across at least one full payday for your customer base, keep attempts and messages spaced rather than stacked, and write the end date down where the team can see it. For the reasoning in full — pay cycles, card replacement times, and how access policy should bend the window — this breakdown of how to choose a dunning window is the version I send people.
Tools encode whatever duration you choose, which is why the choice deserves an hour of data before it becomes a setting. It is one of the decisions Swipe Again makes visible rather than burying in a default — because a default chosen by someone else's customers is still a choice, just not yours.
Top comments (0)