Building Customer Health Scores That Predict Churn
Overview
Building Customer Health Scores That Predict Churn
A step-by-step framework for building a health score that actually predicts churn — not just describes it.
Why most health scores don't work
Ask five Customer Success teams how they built their health score, and four of them will tell you some version of the same story: someone pulled together a handful of metrics that felt right, split them evenly, and shipped it in time for the next board meeting. Login frequency, feature adoption, support ticket volume — reasonable inputs, arbitrarily combined.
The problem shows up later. A customer with a "healthy" green score churns anyway. Another sits in the "at risk" bucket for six months and renews without incident. Nobody trusts the score, so nobody acts on it, and eventually it quietly stops showing up in QBR decks.
A health score that actually works isn't a vibe check — it's a model, even a simple one. That means it has to be built, tested, and revisited the same way you'd treat any other predictive tool. Here's how.
What you will achieve
By the end of this playbook, you'll have a practical Customer Health Score framework that helps your team identify at-risk customers, prioritise Customer Success efforts, and take action before issues escalate.
Step 1
Define what you're actually predicting
Before touching a single metric, get specific about the outcome. "Customer health" isn't one thing — churn risk, expansion potential, and advocacy likelihood are three different predictions, and a single score trying to do all three usually does none of them well.
Pick a primary outcome. For most teams starting out, that's churn - specifically, non-renewal or downgrade within a defined window (next 90 days, next renewal cycle, whichever matches your contract terms).
Worksheet
Common mistakes
Step 2
Source candidate metrics — and test them against real history
This is the phase teams rush. The instinct is to list every metric your product analytics can spit out — logins, feature usage, NPS, support tickets — and assume more data means a better score.
Instead, go backward from outcomes you already have. Pull a list of accounts that churned in the last 12 months and a list that renewed or expanded. For each candidate metric, check whether it actually differed between the two groups before the churn happened — not the month of cancellation, but three or six months prior, when there was still time to act.
A metric that only moves right before someone cancels is a symptom, not a predictor. A metric that diverges months earlier is worth including.
Worksheet
Common mistakes
Step 3
Weight the metrics
Once you've got a validated shortlist — usually 4 to 7 metrics is plenty — decide how much each one contributes to the overall score. Equal weighting is the default most teams fall back to, and it's almost always wrong: a metric that diverges strongly and early between churned and retained accounts should carry more weight than one that's only weakly correlated.
If you have enough historical data, a simple logistic regression will hand you defensible weights. If you don't, weight based on how strongly and how early each metric separated your churned and retained groups in Phase 2 — even a rough ranking beats defaulting to even splits.
Common mistakes
Step 4
Set thresholds and bands
A single number (say, 0–100) is only useful if you've defined what the number means. Set clear bands — Healthy, Neutral, At Risk, Critical — and anchor the cutoffs to your historical churn data rather than round numbers that feel intuitive.
If accounts that churned clustered below a score of 40, that's your "at risk" line — not an arbitrary 50.
Worksheet
Step 5
Attach a trigger action to every band
A health score that doesn't drive action is a vanity metric. For each band, define exactly what happens next — and who's responsible for making it happen.
"At Risk" might trigger an automatic CSM outreach within 48 hours. "Critical" might escalate to a save-play with the account's exec sponsor. "Healthy" accounts might get flagged for an expansion conversation instead. If a band doesn't have an action attached, ask honestly why it exists.
Worksheet
Step 6
Assign ownership and a review cadence
Health scores decay if nobody's accountable for them. Decide who owns the model itself (usually CS Ops or RevOps), who owns acting on individual scores (CSMs), and how often the whole model gets reviewed — not just individual customer scores, but the weighting and metrics themselves.
Quarterly is a reasonable starting cadence for most teams.
Worksheet
Step 7
Test, validate, recalibrate
Before rolling the score out company-wide, backtest it against the last 2–4 quarters of churn and renewal data. Would it have correctly flagged the accounts that actually churned? How many false positives — healthy-looking accounts that got flagged unnecessarily — did it produce?
No model is perfect on the first pass. Expect to adjust weights and thresholds after the first real quarter of use, and build that recalibration into your cadence from Phase 6 rather than treating it as a failure.
Worksheet
Worked example: a mid-market SaaS health score
A 40-person CS team selling to mid-market accounts wanted to predict churn 90 days out. Their shortlist, after backtesting: product login frequency (25%), % of licensed seats active (25%), support ticket sentiment (15%), executive sponsor engagement — measured by EBR attendance (20%), and time since last value-realization conversation (15%).
Thresholds were set at 70+ (Healthy), 50–69 (Neutral), 30–49 (At Risk), under 30 (Critical) — anchored to the fact that 80% of their historical churned accounts had scored under 45 at least one quarter before cancelling.
"At Risk" accounts triggered an automatic CSM check-in within a week. "Critical" accounts escalated straight to the CS Director. After one quarter live, they found executive sponsor engagement was under-weighted — accounts with disengaged sponsors churned even when usage metrics looked fine — and adjusted the weighting from 20% to 30% at the next review.
