What Your CS Health Score Is Actually Measuring, and What It's Probably Missing
If you ask ten CS leaders what goes into their health score, you'll get ten different answers. Some will give you a precise model: weighted inputs from product usage, support volume, NPS, engagement frequency, days since last login. Others will describe something more intuitive: the CSM's gut feel, formalised into a red/amber/green status. A few will admit that the model exists but nobody fully trusts it.
What's consistent across most of those answers is this: the health score is built around inputs that are easy to measure (activity signals, usage metrics, ticket counts) rather than outputs that are hard to measure but actually matter: whether the customer is achieving the outcomes they bought the product to achieve.
This distinction between input and output metrics is, in my view, the most underappreciated design problem in CS. And it has concrete consequences: health scores that go green before an account churns, risk flags that fire too late to change the outcome, and a general sense among CSMs that the model is telling them something they already knew, but not the thing they actually needed to know.
The inputs and why they dominate
The dominance of input metrics in health scores is easy to explain. They're accessible. Most SaaS platforms can surface login frequency, feature adoption, and session duration directly. Support ticket volume is in the helpdesk. Engagement (calls logged, emails sent, check-ins completed) is in the CRM. These metrics can be pulled automatically, updated daily, and rolled into a composite score without much manual work.
Output metrics (whether the customer has achieved their defined success outcomes, whether the product is measurably contributing to a goal they care about) require a different kind of data infrastructure. You need to have defined the success outcomes with the customer. You need to have a mechanism for tracking whether they've been reached. You need to update that data regularly, which may require conversations with the customer, not just a platform pull. This is harder, costlier, and more variable across accounts.
So most organisations optimise for what they can measure easily. The health score becomes a proxy for "is the customer engaged with the product?" rather than "is the customer successful because of it?" And those two things are correlated, but not the same.
What green actually means
Here's the practical problem with an input-heavy health score: it can be green for an account that is actively churning, quietly, without making noise.
The customer who logs in regularly, submits tickets at a normal rate, attends quarterly reviews, and gives a seven on the NPS survey is a healthy account by most input-metric definitions. They might also be an account where the champion is about to leave, the CFO has just had a conversation about cost reduction, and the team using the product has evolved in a direction where the core use case no longer fits their workflow. None of that is visible in the input metrics until the churn notice arrives.
The output metrics would have told a different story earlier. A health score model that tracks: "Are the outcomes the customer committed to at the start still being achieved? Has the definition of success changed since we last reviewed it? Is the value proposition still landing the way it was when they signed?" surfaces the risk sooner and in a form that a CSM can act on.
The challenge is that building that model requires investment in the relationship data, not just the platform data. Which brings us to the design question.
Three things a better health score model accounts for
Outcome tracking alongside activity tracking. Every customer, at the beginning of the relationship, should have a defined set of success outcomes: not vague goals ("improve customer satisfaction") but specific, measurable markers ("reduce manual reporting time by at least 50% within 90 days"). The health score should track whether those outcomes have been reached, whether they've been re-evaluated since then, and whether the customer confirms they're still being achieved. This requires the CSM to have the conversation. It can't be automated, but it can be structured so the data is captured systematically.
Recency weighting on meaningful signals. A customer's product usage from six months ago is less informative than their pattern from the last four weeks. The CSMs who catch risk earliest are usually the ones who notice shifts: an account that was using a feature regularly and has stopped, a champion whose response time to emails has stretched from hours to days. A health score that heavily weights recent change rather than average state is more sensitive to the early warning patterns that matter.
Sentiment capture alongside behavioural data. There's information in how the customer talks about the product that doesn't appear in any usage metric. A CSM who comes out of a customer conversation and updates a sentiment field ("customer expressed frustration with X feature; mentioned competitor in passing for the first time") is contributing signal that changes the health picture. Building the infrastructure to capture and factor in CSM sentiment notes is part of what turns a health score from a dashboard metric into a genuine risk management tool.
The recalibration conversation most teams skip
Health scores degrade in accuracy over time even when they're well-designed, because the customer's context changes and the score's inputs don't automatically update to reflect it.
An account that was flagged green because they were achieving their year-one outcomes might still be showing green two years in, when the team has grown, the use case has shifted, and the definition of success is completely different from what it was at the start. The score is technically accurate given its inputs; it's just measuring the wrong things for where this account is now.
The discipline that prevents this is periodic recalibration: a structured conversation, maybe twice a year per account, where the CSM and the customer revisit: are the success outcomes we defined still the right ones? Has your situation changed in a way that changes what "healthy" looks like? This is also, not coincidentally, one of the most valuable conversations a CSM can have. It surfaces both risk and expansion opportunity, and it signals to the customer that the relationship is moving forward rather than just maintaining itself.
Questions worth sitting with
For any CS leader looking at their health score model:
In the last three accounts that churned unexpectedly, what did the health score show in the 60 days before churn notice? If it was green or amber rather than red, what was the score measuring that the CSM's intuition was already sensing?
Does your health score track whether customers are achieving their defined outcomes, or does it track whether they're active in the product? These are different questions with different answers.
If you removed all the input metrics from your health score and only kept the outcome metrics, what would the model tell you that it doesn't tell you now?
The short version
Most CS health scores are built around input metrics (activity signals, usage data, support volume), because these are easy to measure. They're a proxy for engagement, not a measure of success. The gaps that matter: no tracking of whether customers are achieving their defined outcomes, no recency-weighting that surfaces shifts in behaviour before they become risk, and no structured capture of CSM sentiment data that reflects what the relationship actually feels like on the ground. Fixing the model requires defining success outcomes at the start of every customer relationship, building the CS Ops infrastructure to track them systematically, and building a recalibration rhythm that keeps the score relevant as customer contexts evolve.
Where Pivotal Path comes in
Pivotal Path works with CS and CS Ops teams who are redesigning their health score models, from the outcome definition work at the start of the customer journey, to the data infrastructure that makes tracking systematic, to the recalibration process that keeps the model accurate over time. If your health score isn't telling you what you need to know when you need to know it, get in touch.
James Hayward-Zhu is the founder of Pivotal Path, a Customer Success and CS Ops consultancy working with SaaS businesses at the growth stage.
Working on this in your business?
We help UK SMEs and scale-ups turn this kind of thinking into action.