I've been talking to SaaS founders about churn lately. Not reading blog posts, actually getting on calls and asking "show me your numbers, what's happening."
One conversation stopped me cold.
The $26K blind spot
This guy runs a B2B SaaS, around $200 ARPU, decent product, growing. Loses about 40 customers a month. Spends $3,000/month on ads to replace them.
I asked him one question: "How many of those 40 actively canceled vs. had a failed payment?"
His answer: "I have no idea. I've never separated the two."
We pulled up his Stripe dashboard together. Out of 40 monthly churned customers, 11 were involuntary. Expired cards, bank declines, spending limits hit. These people never decided to leave. They probably didn't even know they'd been canceled.
11 customers × $200/month × 12 months = roughly $26K/year. Gone. From customers who wanted to stay.
Meanwhile he's burning $36K/year on ads to fill a bucket with a hole in the bottom.
This isn't one guy's problem
I had 20 of these conversations. The pattern was almost identical everywhere.
Most founders track churn as one number. They've never split voluntary vs. involuntary. Almost nobody has real payment recovery in place. The standard setup is one email, then cancel after 7 days. That email usually lands in spam. Every founder could tell me their CAC. Not one could tell me their payment recovery rate.
One churned customer literally told me "wait, what? I thought I was still paying for that." His card expired. The SaaS sent one email he never saw. Subscription canceled. He'd been using free-tier features for 6 weeks without realizing it.
Why it keeps happening
Acquisition is sexy. Retention is boring. Every founder I talked to had dashboards for ad spend, conversion rates, signups. None of them had a dashboard for failed payments.
And the number sounds small. Maybe 0.8% of monthly revenue. But compounded over a year, it's real money. And unlike product churn, it's almost entirely fixable.
What the founders who fixed it were doing
The few who had this dialed in were recovering 20-30% of what everyone else was writing off.
Smart retry logic. Not just hammering the same failed charge, but retrying at different times and days because banks have patterns for when they approve charges.
Pre-dunning emails. Contacting customers before their card expires, not after. "Hey, your card ending in 4242 expires next month" is a 30-second fix vs. a whole recovery process later.
Escalating notifications. Email first, then in-app, then SMS. Not one email into the spam folder and then goodbye.
Longer grace periods. 14-21 days instead of 7. Most payment issues resolve themselves if you keep retrying.
Hearing this same story over and over is actually what pushed me to build MRRSaver. Most billing systems handle this terribly out of the box, and I figured there had to be a better way to automate the whole recovery flow.
One thing to do today
Log into Stripe. Look at your failed payments over the last 90 days. Separate them from active cancellations. Do the math.
If you've never done this, the number will probably surprise you.
Have you ever actually checked what percentage of your churn is involuntary? Curious what people are finding.
Before recovery I kept looking at whether failed invoices and cancels are even subscribed on the webhook. Built a small read-only scanner for that, not another dunning product.
Free this week if useful: https://hookcheck.tarsdcs.workers.dev
Full disclosure: I'm Avery Lin (avrlin). I've been packaging a Stripe Dunning Email Pack ($29 — failure-reason matrix + calm retry copy) with AI assistance, so take this as adjacent interest, not neutral advice.
The $26K write-off you describe is the one I keep seeing: CAC is tracked, involuntary churn isn't. The email half of recovery is where it usually dies after that. Expired cards need a swap-card ask; insufficient funds need a retry-later ladder; fraud flags should get silence. One generic update-your-card email for every decline is how those 11 customers never even knew they were canceled.
Curious — when you split those 40, did the recovery email actually branch by decline reason, or was it still one template then cancel?
The voluntary vs. involuntary split is almost never tracked separately in the wild, and the difference matters because the fix is completely different. Voluntary churn requires product work. Involuntary churn often just requires a well-timed email.
The 'bucket with a hole in the bottom' framing is exactly right. We ran into almost the same stories while building tryrecoverkit.com — founders who could quote their CAC to the dollar but had never looked at payment recovery rate.
One thing worth adding from what we've seen: timing of the first recovery email matters as much as whether it exists. D+1 vs D+3 can be a 10-15% swing in recovery rate. Every hour a customer sits in 'payment failed' state without being contacted, the probability they update their card drops. The window is shorter than most founders assume — by day 5, a lot of the recoverable customers have already moved on mentally.
The Stripe dashboard exercise you describe is genuinely the best starting point. Most founders who look at that number for the first time are surprised by how much of it is fixable.
"Every founder could tell me their CAC. Not one could tell me payment recovery rate."
This exact blindspot exists in pricing too:
Founders know their price ($99/mo). Don't know competitor pricing by feature tier.
Result: Charging $99 when competitor premiums Team tier (+50%) but budgets Storage tier (-20%). You're competing in wrong category.
Both are "I never measured this" problems that leak revenue silently.
Great post. What % recovery rate are you seeing with MRRSaver?