Recurly ships a serious dunning system. Automated retries, account updater integrations, and configurable campaigns handle the mechanical core of failed-payment recovery competently, and teams evaluating their stack should start from that respect rather than from a sales pitch. The interesting question for an operator is narrower: where does the platform's machinery stop, and what quietly falls into the gap?
A gap audit takes one month of failed renewals and sorts every outcome into three buckets: recovered by the platform untouched, recovered only after a human intervened, and never recovered. The first bucket is your baseline, and it is usually healthy. The audit lives in the other two.
The human-intervention bucket is the most instructive. Read twenty of those cases closely and patterns repeat. A customer replied to a generic notice asking a question the notice could not answer, and a person resolved it in one exchange. A card updated through a link that a staff member sent manually because the automated sequence had already ended. A long-standing account was saved by a phone-quiet courtesy: a pause offered instead of a cancellation processed. Each case is a place where judgment, timing, or a conversation did work the campaign structure had no slot for.
The never-recovered bucket sorts further. Some were final on arrival: closed accounts, replaced cards never updated, customers who had plainly moved on. No process recovers those, and counting them against any tool is unfair. The remainder are the true gap: soft failures that aged out of the campaign window, timing failures retried on the platform's schedule rather than the customer's payday, and subscribers who received every scheduled message and acted on none of them because none said anything specific enough to act on.
Closing the gap does not mean replacing the platform. It means layering reading and response on top of its machinery: declines classified as they land rather than in a monthly report, outreach that runs in parallel with retries instead of after them, and a cadence that adapts to the response instead of repeating on schedule. Our complete walkthrough of how Recurly dunning works and where a recovery layer fits around it details that architecture for teams running the audit themselves.
Two practical warnings from teams that have run this audit before. First, sample honestly: pull the month as it happened, not the cases people remember, because memorable saves are systematically unrepresentative of the queue. Second, separate configuration problems from coverage problems before you buy anything. A mistimed campaign, an updater connection never enabled, a notice sequence ending days before the retry schedule does: those are settings, and fixing them costs an afternoon. Coverage problems are different in kind: no setting inside the platform reads a decline, re-sequences the response, and starts a conversation in parallel. Confusing the two leads teams either to shop for software they do not need or to keep tuning settings that were never the constraint.
Run the audit quarterly. Platforms improve, your card mix changes, and last year's gap list is not this year's. The teams that keep their involuntary churn low are rarely the ones with the most machinery; they are the ones who keep an honest, current map of where their machinery stops.
That map is where Swipe Again is designed to work: alongside the billing platform you already run, reading every failure, sequencing the response the decline actually calls for, and contacting customers while recovery is still easy. Audit first, though. The bucket sort takes an afternoon, and it will tell you more about your renewals than any feature comparison.
Top comments (0)