At some point every subscription team asks the same question about failed payments: do we hire this problem away, or do we run it ourselves with better tooling? The managed-service route promises a team of specialists and no operational burden. The software route promises control, transparency, and a bill you can predict. Neither answer is universally right — but the trade-offs are rarely written down in one place, so here is the memo version.
What the service model actually sells
A managed recovery service sells attention. Someone watches your failure queue, tunes retry timing against live issuer behavior, and treats recovery as their whole job rather than your side project. For a team with no billing-ops capacity at all, that attention is real value, and the percentage-of-recovery pricing aligns the vendor's income with your recovered revenue — at least on paper.
The costs are quieter. Percentage pricing scales with your success: the better the service works, the more of the recovered money it keeps, forever. Visibility is usually a dashboard and a monthly report rather than your own event-level records, which makes independent verification of the recovery numbers a negotiation rather than a lookup. And the operational knowledge — which decline classes respond to which treatment at your store — accumulates inside the vendor's team, not yours.
What the software model asks of you
Software flips the ledger. The price is flat and known in advance, every retry and notice is visible in your own reporting, and the decline-class knowledge compounds in your own house. The honest cost is that somebody on your team owns the queue: checking the report, noticing when a class shifts, keeping the notice copy current. Modern recovery software automates the attempts and the sending, but judgment still has to live somewhere.
A useful middle test: count the hours. If your team would genuinely spend zero hours a month looking at billing failures, the service model's attention is worth paying for. If someone already opens the billing dashboard weekly — and at most growing subscription businesses, someone does — then the software model's main cost is already being paid, and the comparison becomes mostly about price structure and control.
The questions that settle it
Three questions usually decide the matter faster than any feature matrix. First: at last year's recovered revenue, what would each model have cost, in dollars, all-in? Run that arithmetic before any demo; it is the only pricing comparison that cannot be spun. Second: when a subscriber disputes a recovery or asks why they were emailed three times, whose records answer the question, and how quickly? Third: if you leave in eighteen months, what do you take with you — the full attempt history and the tuned schedules, or a final invoice?
Teams working through exactly this comparison can start from a written Gravy alternative breakdown — service pricing versus flat software pricing at real recovery volumes — and then substitute their own trailing-twelve-month numbers into the same frame.
A note on switching costs either way
Whichever direction you move, protect the in-flight subscribers. Anyone mid-sequence when you switch should finish that sequence or be handed over deliberately, with their attempt history intact; a subscriber dropped between systems experiences it as a cancellation they never chose. Export twelve months of failure and recovery data before access to the old system ends, keep it somewhere boring and durable, and judge the first full cycle under the new arrangement pile by pile against that baseline.
Swipe Again is firmly on the software side of this memo: recovery and cancel deflection together, one flat monthly price, and reporting the merchant owns outright. If your honest answer to the hours test is that nobody will ever look at the queue, hire the attention instead. If someone already looks, the software math is very hard to argue with.
Top comments (0)