How to build a customer health score that works

A health score exists to answer one operational question: which accounts should someone look at this week. That is all. It is a prioritization device for a team whose attention is the scarce resource, and every design decision should follow from that purpose.

This framing rules a lot out. A score designed to be reported to executives will optimize for looking stable. A score designed to prioritize attention will optimize for surfacing change early, accepting some false positives. You cannot have both from one number, and trying to produces something that serves neither.

There is a systematic bias in how health models get built. Teams start from available data — product events, ticket counts, CRM fields — rather than from predictive value, because those sources have clean APIs. The result is a model heavily weighted toward product usage that fails to catch the most common B2B churn causes.

Signals worth including, roughly in order of predictive value: stakeholder stability (is your champion still in role), engagement breadth (how many contacts are actively engaged), engagement recency and reciprocity (are they replying, and how fast), unresolved commitments on either side, value realization (can they name an outcome), support sentiment (not just volume), and product usage depth and breadth.

Note where product usage sits. It matters, and for high-frequency products it matters a lot. But an account can use your product daily and churn when the budget owner — who never logs in — decides the spend is not justified. Usage describes behaviour; it does not describe the decision.

Login frequency may be decisive for a daily-use collaboration tool and nearly meaningless for a quarterly reporting product. Applying one weighting across both produces noise in each. Weight by segment, and accept that this means maintaining several models rather than one.

Keep weights summing to 100% for interpretability, and keep the count low. A four-signal model where every weight is defensible beats a fifteen-signal model where nobody can explain why support sentiment is 7%. Complexity is not accuracy; it is usually just harder to debug.

This is the step almost everyone skips, and it is the one that separates a working score from a decoration. Take every account that churned in the last twelve months. Look up what each scored 90 days before they cancelled. Plot the distribution.

If churned accounts were predominantly green at 90 days, your model has no predictive value and needs different signals, not different weights. If they were mostly yellow or red, your model works and you can tune the thresholds. If the result is scattered, one segment is probably being scored with the wrong weighting.

Run this annually. Products change, segments shift, and a model calibrated against 2024 churn can be actively misleading by 2026. A score nobody revalidates decays silently, which is worse than having no score at all, because it carries false authority.

When a score drops from 82 to 64, the CSM needs to know whether to call the champion, escalate to support, or do nothing. A composite number cannot tell them. So the score must decompose: which signal moved, by how much, and what specific evidence caused it.

The strongest version of this is a score where every movement links to the underlying artifact — the email that went unanswered, the meeting where a concern was raised, the ticket that escalated. That converts the score from a claim into evidence, and evidence is what people act on. It is also what makes the score defensible in a renewal forecast review, where "the model says 64" does not survive scrutiny.