To: The operator deciding whether to staff recovery or automate it
From: Billing operations
Subject: What recovery actually costs, and what it returns
Every subscription business I have worked with has quoted the same number in the same meeting: our recovery rate is twenty-something percent, as if that percentage settles whether recovery is worth doing. It does not. A percentage has no salary, no queue, and no Friday afternoon. People do. When a failed payment lands, someone has to notice it, decide whether to retry it, write to the customer, check whether the card changed, and follow up when nothing happens. That work is the real cost, and it is the thing this memo is about.
Why the percentage misleads
A recovery percentage blends together things you control and things you do not. A month with more expired cards will look worse than a month with more temporary bank declines, even if your team worked the second month harder and smarter. A higher average plan price can make a mediocre rate worth more than an excellent rate at a lower price. And a percentage says nothing about timeliness: recovering a payment on day two keeps a customer in rhythm, while recovering it on day twenty-eight, after access was cut and trust was spent, is a different outcome wearing the same label.
Input one: failure volume
Start instead with failure volume. Count failed first attempts in a normal month, not your best month and not the month a processor incident spiked declines. Split that count if you can. How many are hard declines that will never succeed on the same card, and how many are soft declines, expiries, and insufficient-funds cases where timing and a new payment method can change the result? The recoverable pool, not the raw failure count, is the denominator that matters. Everything else in the calculation should be built on that smaller, honest number.
Input two: average ticket
Next, use average ticket honestly. Not your headline plan price, and not the enterprise outlier who skews every average. Use the monthly revenue you actually collect from a typical subscriber whose payment fails. Multiply the recoverable pool by that ticket and by a conservative recovery assumption, and you have a revenue range, not a promise. Then remember the second-order value: a subscriber recovered this month usually stays for more than one further cycle, so the return compounds in a way a single recovered invoice understates.
Input three: the hours
Now count the headcount input nobody puts in the spreadsheet. Time one week of manual recovery work truthfully: exporting the failed-payment list, checking each account, sending individual emails, answering the confused replies, updating cards by hand, re-running charges, and reconciling who recovered and who quietly churned. In most small teams this work is scattered across support, operations, and a founder, which is why it looks free. It is not free. It is fragmented, it is easy to postpone when tickets pile up, and postponed recovery work decays fast, because cards get replaced, budgets close, and customers forget why they subscribed.
An illustrative example
Illustrative example — all numbers invented for illustration. Imagine a service with 400 failed payments in a month, of which 280 look recoverable. The typical ticket is $29 a month. Recovering even a quarter of that pool restores 70 payments, or about $2,030 in that month alone, before any retention beyond it. Against that, the team spends nine scattered hours a week chasing cards manually, roughly 36 hours a month, and still misses evenings and weekends, when many customers actually read billing email. The question is not whether 25 percent sounds impressive. It is whether 36 fragmented hours should be spent producing an inconsistent version of a process that runs on rules.
What an automated sequence actually replaces
An automated attempt sequence does not replace judgment. It replaces the repetitive middle: retrying soft declines at sensible intervals instead of all at once, sending a clear update-card message while the failure is fresh, spacing follow-ups so they help rather than nag, pausing when a customer responds, and recording the outcome so nobody chases a payment that already recovered. People keep the exceptions — the angry reply, the disputed charge, the loyal customer who needs a human pause. That division is the point. You are not automating care; you are automating the queue so care has time to happen.
The decision
So make the decision like a headcount decision. If the recoverable revenue in a normal month would fund the tooling many times over, and the manual hours would free a named person for work only they can do, the return is already there, whether the headline percentage moves by two points or ten. If volumes are tiny and one person handles recovery in an hour a week, keep it manual and revisit later. For a fuller method, try working through payment recovery ROI with real billing inputs and judge any vendor, including Swipe Again's failed payment recovery work, by whether they show you those inputs plainly. Quote the inputs, not the percentage, in your next meeting. That is where the honest argument starts.
Top comments (0)