Open any dunning software demo and the first screen is usually a message editor. Fonts, tones, send windows, a cheerful preview of the email your customer will receive after a payment fails. It is a strange place to begin, because by the time that email matters, most of the outcome has already been decided by things the editor never shows: how the failure was classified, whether a retry was even appropriate, and what the system did in the silent hours before anyone wrote to the customer.
A more honest evaluation starts at the queue. Ask the vendor to show you a morning's worth of failed renewals as the software sees them, before any outreach happens. You want to see decline families separated, not blended into one red number. Expired cards in one pile, because their fix is a calendar and a link. Insufficient funds in another, because their fix is timing. Authentication challenges in a third, because no retry schedule on earth resolves a step only the customer can complete. A tool that cannot show you that split is asking you to trust averages.
The second question is what happens without a message. A large share of recoverable failures resolve through mechanics alone: a network card updater quietly supplying the replacement credential, a retry placed after payday rather than on a fixed interval, a second attempt that respects the issuer's own signals instead of hammering on a schedule. If the demo cannot walk through those paths case by case, the product is a messaging layer wearing a recovery costume.
That queue-first view is the organising idea behind a buyer's guide to dunning software that starts from the retry queue outward: it scores tools on classification, retry mechanics, card-update handling and attribution before it ever reaches email copy, and it insists on seeing how recovered revenue is counted, because a vendor that credits itself for payments that would have succeeded anyway is selling you your own renewals back.
Counting deserves its own paragraph in any evaluation. Ask what happens to the recovery rate when a customer updates a card three weeks later through their bank, or when a paused subscription resumes and pays. Ask whether a cancellation mid-sequence counts against the number or quietly disappears from the denominator. The honest answers make the headline rate smaller and far more believable. The evasive answers tell you the demo was the product.
Price shape matters for the same reason. A percentage-of-recovery fee feels aligned until you notice it taxes your best customers hardest and makes every recovered dollar negotiate against you at renewal time. A flat monthly price is duller and easier to audit: you can hold it against the recovered total each month and decide, with arithmetic instead of faith, whether the tool earns its place.
One more queue question separates serious tools from decorated ones: what does the system do on day zero, in the minutes after the failure lands? The best sequences begin before the customer hears anything, with classification, an updater check, and a first retry decision made from the decline family rather than from a global timer. If day zero is empty and every case simply waits for the first email slot, the tool has surrendered the highest-recovery hours in the entire sequence to a sending schedule.
None of this requires a sales call to check. The queue view, the counting rules and the price are either visible in the product and its public pages or they are not. Software that survives those three questions has usually earned the right to show you its email editor. Software that leads with the editor is telling you, in its own order of priorities, where its effort went.
Swipe Again is dunning built queue-first: failures classified by family, retries and card updates worked before outreach, and recoveries counted once, for one flat monthly price.
Top comments (0)