Customer health score: what billing and usage data add to it.

Most customer health scores are built the same way. A customer success leader picks a handful of inputs, usually product logins, support ticket volume, an NPS number, maybe executive engagement, assigns each a weight, and rolls it into a red, yellow, or green rating. It is a reasonable model. It is also missing a category of data that, for a subscription business, is sitting right in the billing system: payment failures, downgrade and contraction events, and usage that has quietly drifted below what a customer is paying for.

Quick answer

A customer health score is a weighted composite metric that estimates how likely a customer is to renew, expand, or churn, usually built from product usage, support activity, and sentiment data. For subscription-based SaaS companies specifically, the score is more predictive when it also includes billing-native signals, payment failure frequency, plan downgrades or seat reductions, and usage-to-plan-tier ratio, because these reflect financial commitment rather than self-reported sentiment, and they update automatically instead of waiting on a survey or a support ticket.

What a customer health score actually measures

A customer health score consolidates several inputs into one number or color band so a team can tell, at a glance, which accounts need attention now. Gainsight, one of the category-defining customer success platforms, describes it as a predictive metric that helps teams "evaluate the likelihood of renewal, growth, or churn" by combining usage, support history, NPS, and engagement data into a single score, often shown as a 0 to 100 number or a red, yellow, green rating.

The idea behind the score is sound: instead of a CSM guessing which of forty accounts to call this week, the score ranks them. The problem is what goes into the ranking. Paddle's own explainer on the topic is candid about this: "the customer health score doesn't have a set formula," and the standard approach is to list product actions a team believes correlate with retention or churn, then assign each one a weight by hand. That works when the inputs are actually correlated with outcomes. It breaks down when the inputs are proxies for behavior a company could measure directly, and doesn't.

The inputs most health scores use, and the ones they skip

Gainsight's own framework for building a score groups inputs into five categories: behavioral (feature adoption, login frequency), support (ticket volume, resolution time), relationship (executive engagement, CS interactions), financial (renewals, invoice history, upsells), and feedback (NPS, CSAT). Notice that "financial" here means renewal history and invoice records, a look-back at what already happened, not a live signal from the billing system about what is happening right now.

That gap matters more for subscription-first businesses than for point-of-sale software, because a subscription relationship generates ongoing billing events that carry real information about the account's trajectory. Three of them are consistently underused.

Payment failure and dunning frequency

A card decline is not automatically a churn signal, cards expire for reasons that have nothing to do with satisfaction. But a rising rate of failed charges on an account, or a customer who has moved through multiple dunning cycles in the last two quarters, is a concrete, timestamped data point that a support-ticket-and-login model never sees unless someone manually notes it. Recurly's benchmark research puts involuntary churn, cancellations driven by payment failure rather than an active decision to leave, at 0.86 percentage points of the average 3.27% overall churn rate it tracks across subscription businesses, with B2B software and professional services running a lower blended churn rate (3.8%) than consumer subscription categories (6.5%).

Recurly also found that businesses using structured recovery techniques, card updaters, intelligent retries, and dunning management, saw an average 16x return on that effort. A health score that ignores payment failure history is ignoring a share of churn risk that is both real and, per that data, unusually recoverable once it is visible.

Downgrade, contraction, and seat-reduction events

A customer who drops from 50 seats to 30, removes a paid module, or steps down a pricing tier has taken an action with more predictive weight than a slightly lower login count. Contraction is a stronger signal than usage decline alone because it is a decision the customer had to actively make and pay to formalize. Most CS-tool health scores treat this as a "financial" input recorded after the fact, at renewal, rather than as a live trigger the moment it happens.

Usage relative to the plan tier being paid for

Login frequency tells you if someone is showing up. It does not tell you whether they are using enough of the product to justify what they are paying. A customer on a usage-based or tiered plan whose consumption has fallen well below their tier, while their invoice stays the same, is a customer quietly building a case for a downgrade or a "why are we paying for this" conversation at renewal. That comparison, usage against the specific plan or module a customer bought, only exists where billing and usage data live in the same system.

Building the score: start narrow, weight what predicts, not what's easy to collect

Gainsight's own guidance is to pick four to six metrics and assign weights based on what actually correlates with renewal or churn in your own account base, for example usage at 40%, support activity at 25%, sentiment at 20%, and executive engagement at 15% in one of their published examples. That structure is a reasonable starting frame. The adjustment worth making for a subscription business is to make sure at least one or two of those four to six slots go to billing-native signals rather than filling all of them with usage and sentiment data alone.

A practical starting model for a subscription SaaS company:

Gainsight also flags the most common way these models fail: relying too heavily on subjective inputs, using too many or too few metrics, and never validating whether the weights actually predict what they're supposed to. The fix for the first two is mechanical, cap the model at four to six inputs and make most of them behavioral or financial rather than opinion-based. The fix for the third is to check the score against actual renewal and expansion outcomes on a quarterly basis and re-weight accordingly.

From score to action

A health score that sits in a dashboard nobody checks between QBRs isn't doing its job. The score is only useful if a falling number triggers something: a task for a CSM, an automated retention email sequence, or an alert to whoever owns the account. This is the connective point between customer health scoring and AI-powered churn prediction: the health score's inputs are largely the same billing and product-usage signals a churn model trains on, and a system that already has both in one place can move a customer from "risk flagged" to "retention workflow triggered" without someone manually exporting a spreadsheet.

For a growth or product leader, the same underlying data answers a different question: which healthy accounts are showing early expansion signals, sustained usage near or above their tier ceiling, seat growth, feature adoption breadth, that make them good upsell candidates before a renewal conversation even starts. That is the same billing-and-usage dataset, read for the opposite signal, and it is the same dataset behind net revenue retention: accounts a health score flags as expanding are the ones pulling NRR above 100%.

A quick evaluation checklist

Before building or rebuilding a health score, it's worth checking:

Why reactive churn dashboards fall short

The common failure mode in subscription businesses isn't a missing health score, most teams past a certain size have one. It's that the score is rebuilt from data pulled out of three or four disconnected tools (a CRM for relationship data, a support platform for tickets, Stripe or a billing tool for payment history, a spreadsheet to combine them), which means it's stale by the time anyone acts on it, and it structurally can't include billing signals that live in a system the CS team doesn't have access to. Unifying subscription billing, usage, and revenue data in one place doesn't just save the manual export step, it makes billing-native signals available to the score in the first place, which is the gap this piece has been describing throughout.

Frequently asked questions