How to build a customer health score that predicts churn

A customer health score is a single number per customer that says how likely they are to stay. Many teams build one by picking a few signals, assigning weights that feel right and coloring accounts green, yellow and red. The result looks precise and often predicts little.

This guide builds one the other way round: start from your own churn history, keep the signals that actually separate churned customers from retained ones, check the score against the past before trusting it, and connect every band to an action. All numbers are hypothetical.

Step 1: define what the score predicts

“Health” is vague. Pick a concrete outcome and a time horizon:

target = customer churns (voluntarily or through failed payment)
         within the next 90 days

Decide whether failed-payment churn counts. It usually should, because it is lost revenue either way, but the signals differ: product usage predicts cancellation; card expiry and past failures predict payment churn. Many teams keep one score with signals for both, or two sub-scores.

The horizon should be long enough to act in. A score that predicts churn in the next 7 days leaves no time for anything but a last-minute offer.

Step 2: list candidate signals

Group them so you cover more than product usage:

Family	Example signals
Usage	Active days in last 30, key action count, trend vs previous 30 days, seats used ÷ seats paid
Adoption	Activation milestone reached, number of features used, integrations connected
Billing	Failed payments in last 90 days, card expiring before next renewal, plan downgrades, discount ending
Relationship	Support tickets, unresolved tickets, satisfaction or NPS answers, champion left
Profile	Plan, billing interval, company size, signup source, payment method type, tenure

Two rules for candidate signals:

Measure each at a fixed point in time. For a customer who churned in May, compute the signals as they were in February, not as they were when they left. Otherwise you are describing churn, not predicting it.
Prefer trends to levels. A customer who went from 20 active days to 5 is a different case from one who has always used the product 5 days a month.

For which attributes to collect in the first place, see how to find what predicts churn.

Step 3: test each signal against history

Take a past snapshot date, for example 6 months ago. For every customer active on that date, record each signal’s value then, and whether they churned in the following 90 days.

For each signal, split customers into groups and compare churn rates:

relative risk = churn rate in the group with the signal
                ÷ churn rate in the group without it

Example (hypothetical numbers)

Signal on snapshot date	Customers	Churned in 90 days	Churn rate	Relative risk
Active days in last 30 fell by half or more	120	30	25.0%	3.6
Active days stable or up	880	61	6.9%	(reference)
Failed payment in last 90 days	60	15	25.0%	3.1
No failed payment	940	76	8.1%	(reference)
Seats used under half of seats paid	200	28	14.0%	1.8
Seats used half or more	800	63	7.9%	(reference)

Keep signals with a meaningful relative risk and enough customers in each group. A relative risk of 4 based on 6 customers is noise. Look at confidence intervals, and be wary when you test dozens of signals: some will look strong by chance. The predict churn guide covers sample size and multiple comparisons.

Step 4: combine signals into a score

Option A: points (simple, explainable)

Give each kept signal points roughly in proportion to its relative risk, then cap the total at 100:

score = 100 − (points for each risk signal present)

Example weights from the table above: usage halved −30, failed payment −25, seats under half −10. A customer with a failed payment and halved usage scores 45.

Points are easy to explain to a customer success team, which matters: a score nobody trusts gets ignored.

Option B: a statistical model

Logistic regression on the same snapshot data gives each signal a weight learned from history and accounts for signals that overlap (customers with halved usage may also be the ones with unused seats). It needs more data and someone who can check it. Whatever model you use, keep it explainable enough to say why a given customer scored low.

Step 5: backtest before you trust it

Score every customer as of an older snapshot date that the weights were not built on, then check what happened over the next 90 days.

Churn rate by band

Band	Customers	Churned in 90 days	Churn rate
0–39	80	26	32.5%
40–69	260	31	11.9%
70–100	660	30	4.5%

Hypothetical numbers again. What you want to see: churn rate falls steadily from the lowest band to the highest, and the bands are far apart. If the middle band churns like the top band, the thresholds are wrong or the score adds little.

Capture

capture (lowest band) = churned customers in the lowest band
                        ÷ all churned customers

Here 26 ÷ 87 ≈ 30%: the lowest band holds 8% of customers and 30% of churn. That is useful. But 70% of churn came from customers who did not look at risk, which tells you the score is a help, not a radar. Say that plainly to whoever uses it.

Step 6: connect each band to an action

A score without an action is a dashboard decoration. Write the playbook:

Band	Action
Low (0–39)	Personal outreach within a week; check billing; offer help or a better-fitting plan
Middle (40–69)	Automated, specific nudge based on the signal that pulled the score down
High (70–100)	Nothing extra; consider for expansion or referrals

Make the action depend on the reason, not just the number. A low score from a failed payment needs a card update link. A low score from falling usage needs help using the product. The same “we miss you” email for both helps neither.

Step 7: maintain it

Re-run the backtest every quarter. Products, pricing and customers change; weights drift.
Watch for the score changing behavior. If the team works hard on low-score accounts, their churn drops and the signals look weaker next time. That is success, not a broken score; keep a small untouched holdout if you want to measure it.
Log score changes. “Score dropped from 72 to 41 because active days halved” is something a person can act on. “Score: 41” is not.

Common mistakes

Weights chosen by opinion. Test against history.
Signals measured at churn time. That is description, not prediction.
No backtest. You do not know whether the score works.
Too many bands. Three is plenty if each has a different action.
Treating correlation as cause. A signal that predicts churn may not cause it. Customers who connect an integration may churn less because they were more committed to begin with. Test interventions with a holdout before investing heavily.

Doing this with NoChurn

NoChurn gives every customer a churn score from 0 to 100 at signup and on every change, using signals such as the payment method and payment history. You can send your own attributes and events by API (usage, activation, signup source, support data) and NoChurn shows which ones go together with churn: churn drivers, correlation not causation. To act on the score, it runs failed payment recovery, cancel flows with one offer per reason and one-click cancel always visible, and win-back emails at day 30, 60 and 90 by reason. Every feature is on every plan, priced by MRR only (pricing).