Methodology & benchmarks
How RecoverFlow works
RecoverFlow turns four numbers about your subscription business into a clear estimate of the recurring revenue you lose to failed payments — and how much a real dunning flow would win back. This page shows the exact formula, the published benchmarks behind every default, what the model deliberately leaves out, and why nothing you type ever leaves your browser.
- Privacy guarantee
- The formula
- The benchmarks
- Reading the result
- What it doesn't model
- Lifting recovery
- Roadmap
Nothing you enter leaves your browser
RecoverFlow has no backend. When you type your MRR, subscriber count, or recovery rates, every number stays on your machine. The whole calculation runs in JavaScript, locally, in the tab you're looking at.
- No network requests with your data. Your figures are never uploaded, POSTed, or beaconed anywhere — ours or anyone else's.
- No logging or storage. Nothing is written to a database, log, local storage, or analytics. Reload the tab and it's gone.
- It works offline. Load the page once, disconnect, and the calculator still runs — the simplest proof there's nothing to upload to.
The formula
The model is intentionally simple and transparent — a steady-state snapshot of one month, then multiplied out to a year. Everything starts from your monthly recurring revenue (MRR). If you enter subscribers and ARPU instead, MRR is just subscribers × ARPU.
recovered = at_risk × current_recovery_rate
lost = at_risk − recovered ← the leak
won back = at_risk × target_rate − recovered
annual = monthly × 12
Revenue at risk is the slice of your MRR exposed to involuntary churn each month — the charges that fail. Your current recovery rate splits that into what you keep and what you lose; the loss is the leak the headline reports. Lifting to your target recovery rate recovers more of the same at-risk revenue, and the difference is the win-back. The "at-risk share" lets you treat only a fraction of failures as genuinely lost (leave it at 100% to count every failure).
The benchmarks behind the defaults
Each default reflects widely cited subscription-payments research. They're sensible starting points, not laws — replace any of them with your own data the moment you have it.
| Input | Default | Why |
|---|---|---|
| Monthly failure rate | 9% | Studies of subscription billing consistently land near ~9% of recurring charges failing in a given month — mostly expired cards, insufficient funds, and issuer fraud blocks. |
| Involuntary share of churn | 20–40% | A large slice of total churn is involuntary (payment-driven), not customers choosing to leave. RecoverFlow treats failed charges directly, so the at-risk-share field defaults to 100% of failures; this benchmark is why recovering them matters so much. |
| Current recovery rate | ~38% | Stripe's built-in Smart Retries recover roughly 38% of failed charges on their own — the right default if retries are all you rely on. |
| Target recovery rate | 60–80% | A dedicated dunning flow — smart retry timing plus card-update emails, SMS, and in-app prompts — typically recovers 60–80% of failed charges. |
Figures are industry benchmarks and vary by business, price point, geography, and card mix. Treat them as representative ranges, and override them with your own numbers for an accurate estimate.
Reading the result
The big number is the recurring revenue you're losing per year at your current recovery rate — the charges that fail and never get recovered. The teal band below it is the additional revenue a dunning flow would win back by lifting you to your target rate. The breakdown bars show the same money split five ways: at risk, recovered today, lost today, won back, and still lost even after dunning.
The shareable line packs the headline into one sentence you can drop into a Slack message, a board update, or a note to your co-founder: "RecoverFlow estimates we're losing about $X/yr to failed payments…"
What the model doesn't capture
To stay simple and honest, the model leaves several things out — and they mostly make the real loss larger, not smaller:
- Lifetime value compounding. A recovered customer keeps paying for months. The model counts only the immediate month's charge × 12, so it understates the value of saving a long-tenure subscriber.
- Seasonality and growth. It assumes a steady-state month. Real MRR, failure rates, and card-expiry clusters move over the year.
- Your exact card mix. Recovery rates depend on geography, network, and how aggressively you retry. Use your own current rate for a tighter number.
- Fees and refunds. Figures are gross recurring revenue, not net of processing fees or later refunds.
What actually lifts recovery from 38% to 70%
Built-in retries only retry the card on a fixed schedule. A dedicated dunning flow adds the parts that recover customers retries miss:
- Smart retry timing. Retry when funds are likely — after payday, or when a topped-up balance is probable — instead of on a blind fixed cadence.
- Card-update prompts. Email and SMS that ask the customer to update an expired or declined card, with a one-click hosted update page.
- In-app nudges. Banners and prompts for active users who'd happily fix billing if they knew it had failed.
- Graceful escalation. A sequence that escalates over days before access is cut, so you don't lose a willing customer to a single silent decline.
Each channel recovers customers the others miss — which is how purpose-built tools reach the 60–80% range. That paid recovery engine is what Copper Bay Labs is building next. Get on the list →
On the roadmap
The RecoverFlow recovery engine. This free calculator shows the size of the leak. The paid product plugs it: connect Stripe, and RecoverFlow runs the smart-retry schedule and the email / SMS / in-app dunning sequence automatically — turning the win-back number above into recovered revenue. Stay tuned.