Building recurflux made me realize how many SaaS founders cannot explain their own churn
most founders i talk to know their churn rate. it's on the dashboard. usually somewhere between 3-7% monthly.
but when i ask them to break it down, things get fuzzy fast.
the conversation usually goes like this:
me: "what's your churn rate?"
them: "around 5%"
me: "how much of that is voluntary vs involuntary?"
them: "uh... what's the difference?"
this happens more than you'd think.
voluntary vs involuntary churn
voluntary churn = customer actively cancels because they don't want your product anymore
involuntary churn = customer wants to stay but gets churned due to failed payments (expired cards, insufficient funds, payment errors)
about 30% of all churn is involuntary. that means if you're looking at a 5% churn rate, roughly 1.5% of your customers didn't mean to leave at all.
why this matters
when you lump them together, you're trying to solve two completely different problems with the same solution.
voluntary churn needs: better onboarding, feature improvements, customer success, value demonstration
involuntary churn needs: smart payment retries, card updaters, dunning sequences, pre-debit notifications
most founders are spending time on product improvements and customer interviews trying to reduce churn, while 30-40% of their lost revenue is just... payment infrastructure failing quietly in the background.
what i've seen so far
talked to a founder last week doing $50k MRR with 6% monthly churn. when we broke it down:
4% voluntary (product/value issues)
2% involuntary (failed payments)
they were spending all their retention effort on feature requests and customer calls. zero effort on payment recovery. that 2% involuntary churn was costing them ~$12k/year in completely recoverable revenue.
stripe retries failed payments automatically, but the default recovery rate is usually 40-60% at best. the other 40-60% just... disappears.
the test
if you're a SaaS founder, try this:
open your payment dashboard (stripe, paddle, razorpay, whatever)
check how many failed payments you had last month
check how many of those were successfully recovered
multiply the unrecovered amount by 12
that number is what you're losing annually to involuntary churn alone.
most founders i show this to had no idea the number was that high.
if you want to see the actual breakdown for your SaaS, i built a free tool that splits your churn into voluntary vs involuntary: https://recurflux.com/resources/churn-splitter
takes about 2 minutes. just connect your payment processor and it'll show you exactly how much is recoverable.
anyone else tracking this? or did you only realize involuntary churn was a thing when you saw the actual revenue leaking?
Yes, ownership is the part that turns churn insight into an actual save attempt. A dashboard can tell you who is drifting, but someone still needs to decide: reach out, offer help, escalate, or let it go. The useful system is the one that makes that next human decision impossible to miss.
The intervention timing is completely different too. Payment failure needs to be caught in the 48 hours before the card fails. Product churn usually signals at day 7 or 14 when someone silently decides it's not for them. Treating both with the same retention email sequence is one of the most common mistakes I see. What does your detection timeline look like for each bucket?
And once you split them the solutions look nothing alike. Involuntary is a payments and retry problem. Voluntary is a product fit or onboarding problem. Treating them the same is why retention efforts stall.
So true. “retention” sounds like one problem until you break it apart - then it’s clear that payments issues and product issues need totally different fixes.
the voluntary/involuntary split is the right starting framing but in practice there's a third bucket hiding inside the metric: "never activated → counted as churn". someone signs up, doesn't hit the first value moment, churns at month 1. dashboard says churn. it was actually an onboarding failure.
involuntary side (dunning + smarter retry) is high-ROI infra work, agree. but most of the real damage is upstream at activation.
your 30% involuntary number sounds high though — most B2B SaaS I've seen runs 15-25%. where's that benchmark from? would help to know the cohort. either way recurflux is solving a real gap because most churn tools count churn without surfacing causes.
The third bucket is the sneaky one. I had the exact same issue with Genie 007 for months. Users signing up, not hitting the first value moment, gone by day 7. Dashboard logged it as churn. It was an onboarding gap the whole time. On the 30% benchmark — fair challenge, I picked that up from a SaaS post and didn't verify it. You're right to question it. What are Recurflux's own cohorts showing for involuntary vs activation failure split?
You're right - "never activated but counted as churn" is a huge hidden bucket. they didn't churn from the product, they bounced during onboarding. completely different fix.
involuntary is high-ROI infra work, but activation failure is the upstream killer. if they never hit value, dunning won't save them.
30% involuntary varies by vertical - B2C/prosumer runs higher, B2B typically 15-25%. self-serve and international payment mixes spike it.
most churn tools just count exits without tying it to failure type or usage - that's what we're fixing with Recurflux.
appreciate you coming back on this. one thing that worked for a founder I know was tagging every cancellation with whether the account ever hit the core action, just a crude yes/no column in a spreadsheet, and it completely changed how they read their churn number. does recurflux let you segment churned accounts by activation status, or is that something on the roadmap?
"Founders can't explain their own churn" is the right observation. Most explain the loud reason (price, missing feature) and miss the quiet one (customer never built a habit around the product). Churn data without session data is resignation letters without context. The tools that fix this pull cancellation reason and usage cohort into the same row, not into separate dashboards.
This is it. founders blame price or features because that's what users say in exit surveys, but the real reason is usually "never stuck in their workflow."
churn without usage context is just reading the official excuse, not diagnosing the actual problem.
cancellation reason + usage cohort in the same view changes the diagnosis entirely - lets you see if they churned because the product failed or because they never really used it to begin with.
The voluntary-vs-involuntary split is sharp, and the involuntary side is solvable with infra. The voluntary 4 percent is the noisier number. In practice I see most of it trace back to a hero that promised a different outcome than the one the product delivers.
A founder doing 50k MRR with 4 percent voluntary almost always has signup messaging that overpromises one job and an active feature set that quietly delivers a smaller one. The user does not churn because the product is bad. They churn because the promise that pulled them in stopped matching what they actually use it for after week three. Recovery sequences will not catch that. The audit worth running on top of yours: pull the cancel reasons, then re-read the hero. The gap is usually the answer.
This is the real issue. involuntary = infrastructure fix. voluntary = promise didn't match reality after onboarding.
hero copy vs cancel reasons audit would solve it, but most founders would rather ship features than admit the positioning was wrong.
True, and the bias plays out sharper than that. The founders who actually do the audit usually catch the hero issue, then ship a feature anyway because the rewrite feels less measurable. "I shipped X" beats "I rewrote the H1" in standup, even when the rewrite is what would move MRR.
The fix I've seen work: pair the hero rewrite with one number the founder commits to checking in 14 days. Signup conversion on cold traffic is usually enough. Suddenly the rewrite is a real, talked-about thing on the team, not a vibes change.
What I do for SaaS pages these days, in case useful: I rewrite the hero plus pull five specific fixes from the page, founder ships it and watches the number for two weeks. If you'd ever want one done on Recurflux, happy to trade. You give me one honest cancel-reasons-from-Recurflux observation I can use in a teardown, I send back the rewrite. The page right now reads churn-tool-shaped, but the actual story sounds like the queue-vs-metric reframe you just landed on in that other thread, which is the more interesting hero.
This is real, and the split matters more than founders think. At SocialPost we found a third bucket that hides inside 'voluntary' churn: the customer who actually loves the product but their billing email goes to a finance person who has never logged in. A card declines, a confusing renewal email lands, the finance team flags it as fraud, the card gets killed. Looks like voluntary churn on the dashboard, behaves exactly like involuntary churn in reality. Two cheap fixes most SaaS skip: turn on Stripe's network card updater so cards refresh silently before they fail, and send the renewal heads-up to the actual user, not just the billing contact on file. Together those usually claw back another chunk on top of what smart retries catch.
This is such an underrated failure mode. the decision maker never engaged, billing contact gets confused, card dies, looks like churn but it's really just bad email routing.
network card updater is free money sitting there, and routing renewals to actual users vs billing ghosts is a one-time config change with permanent lift.
are you separating this out as its own churn type now, or treating it as a subset of involuntary?
Usually it's not churn — it's never activated users counted as churned. The metric that actually matters is "used core feature at least once before canceling."
This is the real issue. calling it churn when they never activated is like calling a bounce rate a retention problem.
if they didn't use the core feature even once, you lost them in onboarding — not because the product failed to retain them.
completely different root cause, completely different fix.
Exactly. The "never activated" cohort needs a completely different intervention — onboarding fix, not retention campaign. Are you separating those in your churn dashboard, or do most tools still lump them together?
Yes, in Recurflux we separate the never-activated cohort from true churn, so you can see onboarding issues without them getting buried in the overall churn number.
Just curious.
"about 30% of all churn is involuntary. " where did you get this number?
ProfitWell's data across thousands of SaaS accounts. Range is 20-40%, 30% is the midpoint.
I don't have that problem because I don't have any paying customers yet.
that's actually the best time to think about this,way easier to set up recovery infrastructure before you have customers than to retrofit it later when you're losing real revenue.
The useful next layer is treating involuntary churn like an exception queue, not a retention metric. Failed payment, customer still active, expected recovery action, owner, next attempt, and final state. Once those rows exist, a founder can see whether the leak is retry timing, unclear billing emails, expired cards, or nobody owning the follow-up. That makes the fix much less abstract than "reduce churn."
This is the right framing - treat it like an ops queue, not a retention problem.
suddenly it's debuggable. you can see exactly where it breaks: retry didn't fire, email went to spam, card updater failed, nobody followed up.
vs staring at "5% churn" and guessing.
have you actually run this as a queue with owners and states, or is this the mental model?
Mostly the mental model. The version I’d actually run is a tiny queue: account, failure state, owner, next action, due date. Even a sheet or CRM view works until the pattern proves itself.
this is exactly what we built Recurflux around - failed payment queue with failure state, owner assignment, and automated next actions.
sheet/CRM works to start, but automating the detection and prioritization saves hours once volume grows.
happy to walk you through the setup if it's helpful.
Nice, that makes sense. The thing I like about the queue approach is that it turns churn from a vague metric into a worklist.
Where do you see the biggest bottleneck once volume grows: detecting the right failures early, or making sure a human actually owns the follow-up before the customer disappears?
I like that framing a lot. detection is important, but I think the real bottleneck is usually ownership - once volume picks up, the hardest part is making sure a human actually takes the next step before the customer goes cold.
The voluntary vs involuntary churn split is one of the most under-discussed things in SaaS. Most founders conflate them and then wonder why their retention playbook isn't moving the needle.
The "30% is involuntary" stat is one I've shared in sales conversations too. When a prospect asks "how do we reduce churn?" the first question should always be: which kind?
Good framing here.
Appreciate it. the "which kind?" framing stops you from solving the wrong thing.
most retention work targets voluntary churn by default. meanwhile involuntary sits there unpatched because nobody realizes it's a separate problem.
The involuntary slice is wild once you actually look. A chunk of 'churn' is just expired cards and failed retries, customers who never decided to leave. It is also the cheapest to recover: dunning and a smarter retry schedule, no product changes. Most founders pour energy into win-back emails for voluntary churn while the involuntary leak sits there unpatched. Splitting the number is the first real step.
Exactly right. it's the cheapest churn to recover and most founders completely ignore it.
they're optimizing win-back emails while customers who wanted to stay are getting auto-churned from failed payments.
once you split the number, you stop wasting effort on the wrong problem.
Right, and the gap is that win-back emails feel like growth work while dunning feels like plumbing, so the plumbing loses. The customer who wanted to stay is the easiest save on the board and nobody's looking at them. Are you surfacing involuntary churn as its own number or still buried in the blended rate?
This resonates a lot. we act like win‑backs are offense and dunning is janitorial work, when in reality the “card failed but they still want in” group is the closest thing to free money we have - and most dashboards hide them.
That hidden bucket is where we found the most recoverable revenue too. The fix that worked was boring: retry on a schedule that matches when cards actually get replaced, then one plain email that says your access is still on, not a discount beg. Running it as an ops queue instead of a marketing campaign moved the recovery rate more than any clever copy ever did.
This is exactly it. “hidden bucket” revenue is the easiest to recover, and the fix is just weirdly boring: smarter retry timing, one honest email, and an ops queue. nothing fancy, but it works.
Founders can't explain their churn because they never got enough early users to even see the pattern.
That would make sense if this was a pre-revenue problem.
it's not. founders with enough churn to actually worry about it still can't answer it - because they've never looked at the breakdown, not because they don't have the data.
early-stage founders get a pass. founders at scale don't.