How Do I Build a Health Score Without Usage Data?

A health score without usage data draws on nine inputs, seven of which live in systems the customer success team already owns. Billing knows who pays late. The helpdesk knows who has stopped asking questions. The calendar knows who cancelled the last two reviews. The inbox knows who takes eight days to reply now and took one day in March. None of that needs a product engineer, and none of it can be lost when an analytics migration breaks.

The gap is wider in the market than the product pages suggest. Of 4,978 public G2 reviews of customer success platforms published up to 2026, 459 (9.2%) mention a customer health score while only 114 (2.3%) mention usage data and 5 mention telemetry at all. Teams are scoring health far more often than they are feeding a score with product events.

A health score without usage data loses depth and gains timing. It cannot tell you which feature a customer stopped using or which team inside the account went quiet, so feature-level risk and user-level expansion signals are out of reach. What it gains is that relationship and commercial signals often move before behaviour does, and that none of them disappears when an analytics pipeline breaks or a customer runs the software inside their own network.

That practitioner account matters for anyone waiting on telemetry before they build anything. Usage data answers whether the product is being used; it does not answer whether the reason the customer bought it still exists. A score built from sponsors, meetings and commercial behaviour is aimed at the second question, which is the one that decides annual renewals. What are the early warning signs of churn when data is scattered covers pulling those signals out of the tools you already have.

Weights come from your own churn history, not from a template. Take every account that churned or contracted in the last four quarters and an equal number that renewed flat, then compare each input across the two groups at the 90-day mark. An input that looks the same in both groups predicts nothing and gets a weight of zero, whatever anyone believes about it. An input that separates the groups earns weight in proportion to how cleanly it separates them.

Building a no-telemetry score takes five steps and about a week of elapsed time, most of it spent getting export access to the helpdesk and the shared inbox. Do the inputs before the weights and the weights before the colours, because a colour scheme agreed early becomes the thing people argue about for a month.

1. 1

   List the systems you can already export from

   Billing, helpdesk, calendar, shared inbox, CRM, survey tool, admin console. Write down the refresh interval of each one, because the slowest source sets the speed of the whole score.

2. 2

   Pull 90 days of history per account for the inputs you can get

   You need history to compute change against a baseline, so a score built from today's snapshot cannot work. Start with four inputs you can get this week rather than waiting for all nine.

3. 3

   Compute each input as change, and set its direction

   Support volume down is bad. Reply latency up is bad. Seat gap up is bad. Meeting cancellations up is bad. Write the direction beside each input so nobody has to guess later.

4. 4

   Set weights from the churn comparison, not from a workshop

   Run the churned-against-renewed comparison from the section above. Any input that fails it gets a weight of zero and stays visible on the account record as context.

5. 5

   Publish the score with its refresh time and its accuracy

   Print when each input last updated and how many of last year's churns the score flagged at 90 days. A score that shows its own limits gets used correctly; one that hides them gets trusted and then abandoned.

One rule carries more weight here than on a usage-based score: nothing a CSM types enters the number. A score built from relationship signals is easier to flatter than one built from product events, so keep the CSM's read of the account as a note beside the score where it is useful and cannot move a colour. The customer success scorecard shows the same separation in a form you can hand to a team.

Proving a health score without usage data works takes one afternoon and the last four quarters of churn. Rebuild the score as it stood 90 days before each loss, count how many of those accounts were green, and you have the only number that matters about your score. Do the same for an equal number of flat renewals to get the false alarm rate. Without that test, weights are opinions with decimal places.

The full procedure, including what precision and recall mean for a score like this and what a passing result looks like, is on how to backtest customer health score logic before rollout. The failure modes that break scores of every kind, including gamed inputs and new customers scoring red, are on why customer health score accuracy is so poor.

Three events cover most of what a health score needs from a product, and asking for three is far more likely to succeed than asking for analytics. Engineering teams refuse open-ended instrumentation projects and accept narrow ones with a named consumer, so bring the three events, the destination, and the renewal number they protect.

Until those arrive, the nine inputs stand on their own. Plenty of teams with full telemetry in 2026 end up back here anyway, because product events describe the users and the renewal is decided by people who never log in.

GainTrace connects billing, CRM, support and email first, so a score exists from those sources on day one and improves if product events ever arrive. Each account is scored on change against its own baseline, and the signals behind the number are shown on the record with their refresh times. Customer health shows the sponsor, meeting and commercial movements behind each score, and churn prediction learns from your own renewals which of those signals carried the risk.