Most teams set the length of their dunning cycle once, usually by copying a default, and then never look at it again. Fourteen days feels tidy. Twenty-one feels generous. Thirty feels like a lot of admin. The number survives because nothing in the monthly report ever asks whether the window itself was the problem, and so a cycle can be quietly too short for years while everyone argues about email copy instead.
There is a simple exercise that settles the question with your own evidence. Take the last fifty recovered payments — not the failures, the recoveries — and reconstruct each one as a timeline. When did the first attempt fail? When did the customer open a notice, update a card, or reply? And on which day, counted from the failure, did the money actually land? Plot those landing days in a rough row, earliest to latest, and look at where the cluster sits. Most operators are surprised twice: once by how late the tail runs, and once by how many recoveries landed within forty-eight hours of the cycle they currently run ending.
That second surprise is the expensive one. A recovery that lands on day sixteen of a fourteen-day cycle does not appear in your data as a near miss. It appears, if it appears at all, as a winback, a reactivation, or a brand-new signup, and each of those categories gets credited to a different effort with a different budget. The cycle gets no blame because the evidence of its shortness was reclassified before anyone reviewed it. Reconstructing timelines from the customer's side, rather than from the billing system's categories, is what makes the pattern visible.
The honest answer to how long a cycle should last is therefore not a universal number. It depends on the mix of decline reasons in your queue. A queue dominated by insufficient funds resolves on pay cycles, which have a calendar of their own. A queue dominated by expiring and replaced cards resolves when people notice and act, which is slower and less predictable. Reading a field guide to choosing a dunning duration that matches how customers actually recover alongside your reconstructed timelines is useful precisely because it treats duration as a property of the failure mix, not as a best-practice constant to copy from another company's settings page.
Two cautions belong in the same conversation. First, a longer window is not free: every extra day is a day a customer may be in an ambiguous state, unsure whether they still have access, and that ambiguity has its own churn cost if notices do not explain it clearly. Second, duration and intensity are different dials. Extending a window while spreading the same number of attempts more thinly is a different decision from extending it and filling the extra days with more pressure. The timelines will usually argue for the first and against the second.
What the exercise reliably produces is a defensible number — one you arrived at from your own recoveries rather than from a default — and a short list of accounts that would have been saved by it. That list is persuasive in a way a benchmark never is, because every name on it was a real customer who tried to stay. Set the cycle from the evidence, write down the date you set it, and repeat the reconstruction in a quarter. Failure mixes drift, and a duration that was right in January can be quietly wrong by spring.
That discipline — measure from the customer's timeline, then set the window — is how Swipe Again thinks about recovery length: long enough for a willing customer to finish fixing the problem, explained clearly enough that the wait never feels like neglect, and revisited on a schedule instead of inherited from a default nobody remembers choosing.
Top comments (0)