Exeechain

Something i wish someone had told me before i built anything in customer success:

Churn isn't one thing. it's two, and they need opposite fixes.

The first kind is a decision. someone weighed your product and said no. that's a product problem or a fit problem, and no amount of "just checking in" emails changes it.

The second kind nobody decided. a card expired the week before renewal. a finance contact changed jobs and the invoice email went to a dead inbox. a launch discount was supposed to end in month three and is still running in month eighteen. the customer is using the product this morning. they just aren't paying for it, and in most books that's 20 to 40 percent of what gets called churn.

The mistake almost every team makes is sending the CSM after both. the CSM writes a heartfelt "is everything ok?" to a customer whose only problem is a 16-digit number that changed. the customer is confused. the CSM is demoralised. the money was recoverable the whole time with a pay link and a follow-up on day 3.

So the first question to ask about any churned account isn't "why did they leave." it's "did they leave, or did the payment?" once you split the pile, the second half turns out to be a billing-ops problem with a known fix, and the first half gets a lot smaller and a lot more honest.

I wrote up the seven ways revenue leaks without a decision and how each one shows up in stripe data, because once you know what to query it's a 20 minute job:

exeechain.com/blog/revenue-leakage-saas

Something I keep running into while building in this space, and I think it's costing people real money.

Your churn number is two completely different problems averaged into one metric:

Voluntary churn — someone evaluated your product and decided to leave.
Involuntary churn — someone's card expired.

These have nothing to do with each other. One is a product/positioning problem that takes months. The other is plumbing you can fix this week. Public Stripe dunning benchmarks put involuntary at roughly 1 in 4 cancellations.

But most dashboards blend them. So a founder looks at 6% monthly churn, feels bad about their product, and goes off to rewrite onboarding, while a quarter of the leak is people who never decided to leave at all.

Three things that actually move the number:

1. Split the metric before you do anything else. You can't fix what you can't see separately. This is a one-hour reporting change and it usually reframes everything after it.

2. Pre-dunning beats retries. Everyone builds the retry sequence. Almost nobody emails before the card expires, and Stripe already hands you the expiry date. Reaching someone while their card still works converts far better than chasing them after a decline, when your product is now associated with a failed payment.

3. For voluntary churn, watch login breadth, not frequency. How many distinct people at an account logged in this month, not how often. One power user staying active masks an entire team that's gone quiet. Frequency lies. Breadth doesn't.

Full disclosure, because this community deserves it: I'm building a tool that does this automatically (exeechain.com). Zero customers so far, I'm at the stage where I'd rather learn than sell.

So: I'll do this analysis by hand, free, for anyone who wants it. Send me your numbers or connect Stripe read-only and I'll send back your actual voluntary/involuntary split and which accounts are drifting. No call, no deck, and it's yours whether or not you ever pay me anything.

Comment or DM and I'll get to you today.

I've spent the last several months building a customer success platform solo, which means I've spent the last several months staring at churn data instead of doing marketing. Here is the thing that changed how I think about retention, and that I wish someone had told me before I wrote a single line of code.

Almost every CS tool, mine included at the start, treats churn as a continuous quantity. You compute a health score, you watch it drift, you alert when it crosses a line. It feels rigorous. It demos well.

But when I actually traced churned accounts backwards, the picture was different. Churn wasn't a slow drift. It was decided in two narrow windows, and the "health score" was often calm during both.

Window one: the first 90 days. If a customer never reaches their first real outcome with your product, the renewal decision is already made, eleven months before anyone makes it. The account looks fine in the dashboard the whole time. Logins happen. Nobody files tickets, because people don't file tickets about a product they've quietly stopped caring about. The silence that looks like health is the disease.

Window two: the renewal window itself. The strongest churn signal I have ever seen in data is embarrassingly simple: the customer switched auto-renew off. That is not a "risk indicator." That is a person who already clicked the button. And most scoring models I studied, again including my own first version, gave it literally zero weight, because it doesn't look like "engagement data."

So the rebuild boiled down to three rules:
1. A stalled onboarding should be the loudest alarm in the product. Days-since-last-milestone beats almost every fancy signal during the first 90 days.

2. Score the renewal window explicitly. Contract end date and the auto-renew flag are sitting in your billing data. Read them. A mid-risk account 30 days from a lapsing contract is a different species from the same account mid-contract.

3. Absence of data is never risk. If you don't track NPS, that's a data gap, not a detractor. Scoring silence as danger trains your team to ignore the score. Every signal in my scorecard now abstains when its data doesn't exist, and the score renormalizes over what's actually known.

One more uncomfortable lesson: seat utilization. A 200-seat contract with 12 active users renews exactly once more, at 12 seats, if you're lucky. Aggregate usage graphs hide this completely because those 12 users can be very active. You need per-user identity in your tracking events to see it at all.

None of this needs machine learning, despite every tool in the category now marketing itself as AI churn prediction. It's deterministic arithmetic over data most SaaS companies already have in Stripe and their own event stream. The ML can come later, once you have enough labeled outcomes to calibrate against. Starting with a transparent scorecard also means every score comes with its reasons attached, which is the only way a one-person CS team (i.e., the founder) will ever trust it enough to act.

The tool I built around these ideas is Exeechain (https://exeechain.com). It predicts churn with explained drivers, drafts the save outreach for human approval, and only counts revenue as "saved" after the renewal actually happens, because I got tired of retention tools grading their own homework.

But honestly, even if you never touch my tool: go check how many of your churned accounts flipped auto-renew off weeks before anyone noticed, and how many never finished onboarding. I'd bet money it's most of them. Happy to share more of the scoring logic in the comments if anyone's building something similar.

I've launched a handful of SaaS products. Most flopped. The ones that got traction all taught me the same painful lesson, and I wish I'd learned it earlier: I was obsessed with getting new customers and completely blind to the ones quietly leaving out the back door. I'd celebrate signups while roughly the same number churned, running up a down escalator without realizing it.

When I finally dug into the churn data, two things genuinely surprised me:

1. By the time a cancellation shows up in your revenue number, the customer decided to leave weeks earlier. Churn is a lagging indicator — the warning signs (usage dropping, a key user going quiet, a failed payment) are all there before the cancel, if you're looking at leading indicators instead of last month's MRR.

2. A big chunk of "churn" isn't people choosing to leave at all — often 20–40% is cards that silently failed and dunning never recovered. The customer never decided anything; the payment just quietly died. And it's usually the easiest revenue to win back, because they weren't even unhappy.

That second one broke my brain a little. Most dashboards lump both together as one "churn" number, so you end up fixing the wrong problem.

I got obsessed enough with this that I ended up building a tool around it (Exeechain), but honestly the lesson stands with or without any software: retention is a leading-indicator game, and most of us only watch the lagging number.

Curious how other founders here handle it: do you separate voluntary churn from failed-payment churn? And have you found any signal that reliably tells you a customer's about to leave before they do?

Happy to share more of what I found in the data if it's useful — and if anyone wants their own churn broken down (voluntary vs failed-payment split), I'm genuinely happy to do a few for free.