TLDR: Most founders track one churn number and treat it like one problem. It is two. Involuntary churn is a payment that failed: an expired card or a declined charge, from a customer who still wants you. Voluntary churn is someone finding the cancel button because the product was not worth it. Same number on the dashboard, two different diseases, and the cure for one does nothing for the other. Spend three months rebuilding onboarding when your real leak is failed payments and you just fixed the wrong thing. Here is how to tell which one is actually yours.
Why the same churn number is two different diseases
A single churn percentage is an average, and an average hides the reason people left. Two SaaS companies can both post 5% monthly churn. In one, most of that 5% is cards that quietly failed. In the other, it is people who logged in, felt nothing, and cancelled. Identical dashboards. Opposite problems.
This is the same trap as reading a single churn rate instead of the retention curve underneath it. The number tells you how much you are losing. It never tells you why. And with churn, the why is the entire decision about what to build next.
Two diseases, one number. The playbook on the left does nothing for the problem on the right.
Involuntary vs voluntary churn, side by side
Here is the split laid out. Notice that the only row they share is the one on your dashboard.
| Involuntary churn | Voluntary churn | |
|---|---|---|
| What it is | A payment that failed | A customer who chose to cancel |
| Root cause | Expired or declined card, billing hiccup | Weak value, poor onboarding, bad fit |
| Do they still want you? | Yes. They did not decide to leave | No. They decided you were not worth it |
| Typical share of churn | ~20% to 40% for most subscriptions | The rest |
| The fix | Dunning, card updater, pre-expiry outreach | Onboarding, activation, save flow, real value |
| Time to results | Often within 30 days | Weeks to months |
| What it really signals | A billing problem | A product problem |
The fix for involuntary churn is a billing problem. The fix for voluntary churn is a product problem. Run the wrong playbook and you burn a quarter proving it.
How do you tell which one is actually yours?
You do not need a data team. Take last month's churned customers and separate the ones whose payment failed from the ones who clicked cancel. That single ratio decides which team owns the problem and which playbook you run. The widget below does the split, then puts a dollar figure on the recoverable side.
Drop in last month's numbers. This runs the exact split from the video.
About 30% of your churn is involuntary, the recoverable kind. Fix that first for a quick win, then work the slower voluntary side: onboarding, activation, and your save flow.
Where these numbers come from: the recoverable figure assumes smart dunning wins back about 60% of failed payments, which sits inside the range that Stripe and Recurly report for automated retries plus a card updater. The 20% to 40% involuntary share is the band those same providers see across most subscription businesses. If more than a fifth of your churn is involuntary, that is the cheapest revenue you will ever recover, and most teams never even measure it. That is the whole reason involuntary churn gets silence while voluntary churn gets a dashboard.
What fixing the wrong one costs you
Here is the expensive part, and it is exactly what the video is about. Say your churn ticks up and you assume it is a value problem, so you spend a quarter rebuilding onboarding. Meanwhile the real leak was expired cards, and it kept draining the entire time. Three months gone, the number barely moved, and the team takes the morale hit because the big project "did not work."
The reverse is just as costly. You bolt aggressive dunning onto a product that people are actively leaving, so you re-bill a stream of customers who were always going to walk. Recovering someone who wanted out is not a real save. It comes back later as a refund request and a one-star review, which is the trade-off buried inside Stripe's automatic card updater.
The two fixes are completely different
If your leak is involuntary
This is a billing problem, and it is the faster win. Turn on smart dunning so failed charges retry at sensible times, add a retry and card-updater setup so reissued cards keep billing, and send pre-expiry outreach before the card dies. Stripe, Chargebee, and Paddle all ship revenue-recovery tooling for this, so you are wiring up existing features rather than building from scratch. Most of it pays back within 30 days. If you want the fuller picture of why this money leaves quietly, start with what involuntary churn is.
If your leak is voluntary
This is a product problem, and it is slower. People are leaving because they never reached value, so the work is upstream: fix the onboarding and activation milestones that get new users to their first win, and add a cancellation save flow to catch the ones already heading for the door. No amount of dunning fixes this, because the customer already decided. If you are new to the distinction, here is what voluntary churn is and why it maps to value rather than billing.
Diagnose it in about 60 seconds
The single move that saves you a quarter is splitting the number before you treat it. The free Churn Health Check is 8 questions and takes about a minute, and it tells you which leak is actually yours before you commit three months to the wrong fix. If you would rather put a dollar figure on the recoverable side first, the MRR Impact Simulator shows what winning back your failed payments is worth at your scale, and the full experiments library has the playbook for whichever side turns out to be your real problem. Diagnose first. Then treat.