Customer Health Scoring: How PMs Build an Early-Warning System for Churn
Picture a $140K account that canceled with six weeks of runway that nobody used. The customer health score sat green the whole time. Logins were steady. Support tickets were low. Nobody at the company had complained about anything. The first real signal, the one that would have actually mattered, was that the champion who’d sponsored the deal had quietly moved to a different team, and the three people who inherited the account had never touched the product before. The health score didn’t track org changes. It tracked activity, and activity looked fine right up until the day someone canceled.
That’s the trap most customer health scores fall into: they measure what’s easy to pull from an API, not what actually precedes churn. It matters more than most product teams treat it. Harvard Business Review’s oft-cited retention research puts the cost of acquiring a new customer at five to twenty-five times the cost of keeping one you already have, which is the entire economic case for building an early-warning system instead of just reacting at renewal. Building one that works means starting from your actual churn history instead of a checklist of “best practice” metrics, and being honest about what the data does and doesn’t tell you.
What a Customer Health Score Actually Measures
A customer health score is a composite number: usually 0 to 100, or a red/yellow/green band, that estimates how likely an account is to renew, expand, or churn based on signals from product usage, billing, support, and the relationship itself. It is not a satisfaction score, and it is not the same thing as net revenue retention, which tells you what already happened to revenue last quarter. A health score is supposed to tell you what’s about to happen to a specific account, early enough that someone can still do something about it.
The distinction matters because most teams build health scores that are really just usage dashboards with a color applied. They track daily active users, login frequency, and feature adoption: data that’s genuinely useful but that measures the past, not the trajectory. A customer who logged in every day for six months and then drops to twice a week is sending a completely different signal than a customer who’s always logged in twice a week. A flat health score treats them the same. A good one doesn’t.
The teams that get this right treat the score as an input to a decision, not a decoration on a dashboard. If nobody’s job changes when the score turns yellow, you haven’t built a health score. You’ve built a report nobody reads. It also shouldn’t live in isolation from the rest of your product metrics framework — a health score that contradicts what your activation and retention metrics are telling you is a sign one of the two is measuring the wrong thing.
Building Your First Customer Health Scoring Model
Start backward, not forward. Before you touch a spreadsheet or a weighting formula, pull every account that churned in the last 12 months and every account that renewed or expanded in the same window. Go back 60 to 90 days before each churn date and reconstruct what that account’s behavior actually looked like. Not what you assume it looked like.
This is the step most teams skip, and it’s the reason most homegrown health scores drift out of usefulness within a year. Someone picks “logins per week” as 30% of the score because it feels rigorous, ships it, and never revisits it. Eighteen months later the product has changed, a chunk of power users moved to the API and stopped touching the UI at all, and the score is now measuring a behavior pattern that no longer maps to anything. Recalibrate against real outcomes on a set schedule, quarterly is reasonable for most B2B products, or the score will quietly stop meaning anything while still looking authoritative.
Once you’ve reconstructed pre-churn behavior, group your candidate signals into three buckets:
- Usage signals — not raw activity, but activity relative to that account’s own baseline. A 40% drop in distinct weekly users is a stronger signal than any absolute login count.
- Relationship signals — champion changes, unanswered outreach, missed QBRs, declining voice-of-customer survey response rates.
- Commercial signals — late payments, downgrade requests, a shift from annual to monthly billing, support tickets that mention budget or “reviewing options.”
Weight these based on what your reconstructed churn data actually shows correlates with the outcome, not on what feels important. Executive engagement feels strategically critical. It doesn’t always predict churn in the next 90 days. Let the historical pattern tell you what to weight, then sanity-check it with your customer success team before you ship it. They’ll catch signals in the data that don’t hold up on the ground, and they’ll catch ground truth that isn’t in the data yet.
Customer Health Score Signal Weighting Template
| Signal Category | Example Metric | Suggested Weight Range | Data Source |
|---|---|---|---|
| Usage trend | 30/60-day active users vs. account baseline | 25–35% | Product analytics |
| Feature adoption breadth | Core features used vs. plan tier | 10–20% | Product analytics |
| Relationship health | Champion changes, QBR attendance | 15–25% | CRM, CS notes |
| Support signal | Ticket volume trend, sentiment, unresolved P1s | 10–15% | Helpdesk |
| Commercial signal | Payment status, downgrade requests, billing cadence change | 15–20% | Billing system |
| Survey sentiment | NPS/CSAT trend (not absolute score) | 5–10% | Survey tool |
Which Signals Actually Predict Churn (And Which Just Feel Predictive)
This is where most first attempts go wrong, and it’s worth naming the specific failure mode: teams weight signals by how important they sound in a QBR, not by what the data shows. Picture a 40-person B2B SaaS company whose initial model put heavy weight on support ticket volume: more tickets, lower score. It turns out ticket volume often has almost no relationship to churn. The accounts that churn quietly tend to have low ticket volume, because they’ve stopped engaging with support entirely rather than fighting to fix the problem. The accounts with high ticket volume are often the most engaged: they’re annoyed, but they’re still trying to make the product work.
What actually predicted churn in that dataset was a drop in the number of distinct users logging in over a rolling 30-day window, even when total login count stayed flat. That pattern meant the internal champion had left or lost interest and nobody else had picked up the account. It’s a specific, checkable signal, and it doesn’t show up if your model is only tracking aggregate usage.
A second finding surprised the team more: accounts with consistently flat NPS scores — never improving, never declining, just a shrug quarter after quarter — churned at a higher rate than accounts with a single bad NPS score that then recovered. Indifference turned out to be a stronger risk signal than a visible complaint, because a complaint means someone’s still invested enough to be annoyed.
Take a position here, because vague hedging is where most health-scoring guides fail their readers: usage trend relative to baseline and distinct-user count are the two signals worth weighting most heavily for the majority of B2B SaaS products. Support ticket volume, on its own, is usually a weak signal and often gets overweighted because it’s the easiest thing to pull a number for. Reforge’s writing on churn makes a similar point from a different angle: treating churn as a single cancellation event, rather than the tail end of a much longer disengagement process, is what leads teams to build scores around the wrong moment in that process.
When a Customer Health Score Breaks Down
Health scores fail in three specific, recurring ways, and each one is worth naming because each has a different fix.
The score is a snapshot, not a trajectory. An account can sit at a 65 for six months and look stable, while the underlying trend is a slow bleed from 90 to 65. A static threshold (“flag anything under 50”) misses that account entirely until it’s already deep in the danger zone. The fix is to score the slope, not just the level: flag accounts whose score has dropped more than a set amount over a rolling window, regardless of where they currently sit.
Nobody owns the yellow accounts. Red accounts get attention because they’re clearly on fire. Green accounts get ignored because they’re fine. Yellow accounts — the ones the score exists to catch — often get neither, because no one is explicitly accountable for them. If a yellow flag doesn’t route to a specific person with a specific expected action within a specific window, the score is theater.
The model gets stale and nobody notices. This is one of the most common failure modes, and it’s insidious because the dashboard keeps looking exactly as authoritative as the day it launched. A product changes: a new self-serve tier launches, a power-user workflow moves from the UI to the API, and the signals that used to predict churn stop meaning what they used to mean. Six months later, the team is making renewal decisions off a number that’s actively wrong, and because the dashboard still renders cleanly, nobody questions it. Put a recalibration review on the calendar before you launch the score, not after you notice it’s wrong.
A Worked Example: Scoring Health at a 40-Person B2B SaaS Startup
A vertical SaaS company selling scheduling software to home-services businesses had one CSM covering 200 accounts and no budget for a dedicated CS platform. The team disagreed early on about whether to build a lightweight rule-based score in a spreadsheet or wait and save for a proper tool. The CS lead wanted to wait; the head of product argued that a rough score shipped now beats a perfect score shipped in eight months, because you can’t collect the churn data you need to calibrate a model until you’re already scoring accounts and watching what happens.
They shipped a five-signal rule-based score in three weeks: weekly active users vs. 90-day baseline, invoice status, days since last login by the account admin specifically (not just any user), support ticket sentiment via a simple keyword flag, and NPS trend. It ran in a spreadsheet pulled nightly via a scheduled query, color-coded red/yellow/green, and pushed yellow-and-red accounts into a Slack channel the CSM checked every morning.
The real constraint that shaped the build was headcount: with one CSM for 200 accounts, the score’s only job was to tell that person which 15 accounts to look at that week, not to produce a perfect risk percentage. Over the next two quarters, the team tracked whether flagged accounts actually churned at a higher rate than unflagged ones. They did — roughly three times higher — which was enough signal to justify investing in a proper CS platform. The rough version also cut the number of surprise cancellations (accounts that churned with no prior flag) by about a third, simply because the admin-login signal caught champion turnover that the team had previously only discovered at renewal time.
How Do You Roll Out Health Scores Without Creating Alert Fatigue?
A health score that flags 40% of your accounts as at-risk isn’t a health score, it’s noise, and your CS team will learn to ignore it within a month. Benchmarks vary a lot by segment — what counts as healthy monthly churn for an enterprise SaaS product looks nothing like what’s healthy for a self-serve SMB tool. So calibrate your red threshold against your own segment’s baseline, not a number you saw in someone else’s blog post. Calibrate thresholds so that “red” genuinely means “the top slice of accounts most likely to churn in the next quarter,” not “anything below an arbitrary round number.” If red is more than 10–15% of your book at any given time, tighten the thresholds.
Route flags to a specific action, not a general alert. “This account is yellow” is not actionable. “This account’s admin hasn’t logged in in 21 days: send the re-engagement sequence and loop in the CSM” is. The same discipline that tells you when to retire a feature instead of letting it quietly rot applies here: a threshold with no defined action attached is a policy nobody actually follows. The product-led growth teams that do this well treat the health score as the trigger for a defined playbook per risk type, not a single generic “reach out” instruction.
Finally, resist the urge to build the perfect model before shipping anything. A five-signal rule-based score built on real churn history and revisited quarterly will outperform an unvalidated machine-learning model built on vanity metrics, every time. You can always add sophistication once you’ve proven the simple version catches real risk — and once you have two or three quarters of outcome data to actually validate against, which you don’t have on day one no matter how good your model architecture is.
This week, pull your last 15 to 20 churned accounts and check whether your current health score, if you have one, would have flagged any of them 60 days before they left. If it wouldn’t have caught most of them, you don’t have an early-warning system. You have a dashboard that agrees with reality after reality has already happened, which is a very different and much less useful thing.
References
- Harvard Business Review — “The Value of Keeping the Right Customers,” 2014 — https://hbr.org/2014/10/the-value-of-keeping-the-right-customers
- Lenny’s Newsletter — “What is good monthly churn,” Lenny Rachitsky — https://www.lennysnewsletter.com/p/monthly-churn-benchmarks
- Reforge Blog — “Trying to Reduce Churn Rate? Avoid These 3 Common Myths” — https://www.reforge.com/blog/churn-rate-myths
