Customer health scores: design them like you mean it

Every B2B SaaS company eventually builds the dashboard: a table of accounts with a column of coloured dots — green, amber, red — and a number from 0 to 100 that is supposed to tell a customer-success manager where to spend her morning. Ask the CSMs whether they trust it. Watch them glance at the dots, then open their own spreadsheet anyway.

The failure is rarely in the data. It's in the design decision to compress a complex, contested judgement — is this customer healthy? — into one opaque integer and present it as an oracle. A score nobody can interrogate becomes a score nobody acts on, and then becomes set decoration: the dashboard that exists so the board deck can say "we track health." This piece is the alternative: health-score interfaces designed to earn trust from the people who spend against them. It's the CS-specific application of our dashboard hierarchy rules and, honestly, of everything we believe about honest metrics.

Signals you can argue with, not oracles you can't

The single composite number fails for a structural reason: it hides its reasoning. When Acme Corp is a 61, the CSM's first question is why?, and if the answer requires opening the BI tool and reverse-engineering a formula, the score has lost to the spreadsheet. The spreadsheet, for all its sins, shows its work.

So show the work. We design health scores as a composite with visible components: the headline score stays (you need sort and triage), but it decomposes on the row itself into three to five named signals with their own mini-scores:

Signal	What feeds it	Display
Adoption	weekly active users vs seats, feature breadth	bar + direction arrow
Cadence	logins per week trend, key-workflow frequency	sparkline
Outcomes	customer's own success metric moving (reports run, invoices sent)	delta vs baseline
Relationship	champion activity, QBR attendance, response latency	qualitative badge
Load	open escalations, unresolved tickets, error rates	count + severity

The components do two jobs. They make the composite arguable: a CSM can say "adoption is fine, but the champion left in March and the score hasn't caught up" — a sentence that is impossible against a bare 61. Arguable scores get corrected; corrected scores get trusted. And they make the score actionable: "work on this account" is vague; "outcomes are green but cadence is decaying — they may have built the report and stopped visiting" is a Monday-morning plan.

Two design rules keep components honest. First, cap the composite's independence: the headline number must be a documented, weighted function of the visible components, not a secret sauce with extra ingredients. If data scientists want exotic features in the model, those features become visible components too, or they don't go in. Second, render uncertainty: a score based on fourteen days of data from a two-seat account is not the same object as a score built on a year of enterprise telemetry. A small "low confidence" marker does more for trust than a full point of accuracy.

Trend beats point-in-time, always

A health score of 55 means almost nothing. A health score of 55 that was 78 eight weeks ago means everything. Yet most health dashboards default to the snapshot: this week's number, this week's colour.

Design the trend in from the first sketch. The row shows a ninety-day sparkline next to the score, the detail view leads with the trajectory chart, and — critically — the default sort is not by score but by slope: biggest negative deltas first. Sorting by absolute score buries your best rescue candidates (a declining 65) under hopeless lows that have been red for a year and are red because the signal is wrong. Sorting by decline surfaces the accounts where intervention still has room to work, which is the entire point of the exercise.

This also changes alerting. Point-in-time alerts — "account dropped below 50" — fire late and fire on noise. Slope alerts — "cadence down 30% over three weeks" or "outcomes flat since implementation ended" — fire early with a hypothesis attached. When we rebuilt the CS dashboard for a fictional-but-representative HR platform, moving from threshold alerts to slope alerts shifted median intervention from eleven days before renewal panic to seven weeks before it — the difference between a rescue and an apology. (Illustrative figures, but the direction is what every team that makes this switch reports.)

Thresholds without the noise fatigue

Health-score alerting follows the same arc as every alerting system ever built: enthusiasm, flood, muting, death. The design problem is not the threshold line; it's the alert budget.

Rules we ship:

• One notification per account per condition per week. A decaying account generates one "cadence declining" alert that persists as a state, not a daily drumbeat of the same fact. Alerts are state changes, not sensors.
• Alerts route to a queue with an owner, not to a channel. Slack-based health alerts are dead within a month; a triage inbox where every alert requires a disposition (acted, snoozed with reason, dismissed as false positive) lives for years — and the dismissal reasons become your recalibration data.
• Measure precision like a growth team. If fewer than a third of alerts get acted on, the thresholds are wrong, full stop. Track it, review it monthly, and be willing to delete alert classes — a noisy notification system teaches users that silence is the correct response, and muting generalises.
• Celebrate the floor. A weekly digest of accounts that recovered — with the action that preceded recovery where it's known — is how a CS team learns what works, and it's the only reason anyone opens the digest in month six.

Should customers see their own score?

The genuinely interesting design question. Two schools, both with real merit.

Against sharing: the score is a triage tool built from surveillance-flavoured telemetry; exposing it invites gaming, confuses customers ("why am I amber? I feel fine"), and leaks the weighting to anyone who wants to inflate the number on the way to an exit.

For sharing — selectively: a customer's own usage story, framed as their data, changes behaviour. "Your team used 3 of 12 features last month; teams like yours get the most value from X" is not a health score — it's a mirror, and mirrors prompt action that no CSM email can. QBRs built on shared component views ("here's your adoption line, here's how it compares to your own last two quarters") land better than ones built on a vendor's secret verdict. And a company willing to show its working signals confidence in the relationship.

Our position: never share the composite, often share the components. The composite exists for your triage; the components belong to the customer's understanding of their own progress. Package them as customer-facing insight (monthly usage recaps, benchmark snippets, an in-product "your programme at a glance"), which does double duty — it's retention marketing built from true numbers, the kind of thing our growth team would call lifecycle content with a pulse.

Governance: someone owns the model, on a calendar

A health score is a product, and products without owners decay. The governance minimum: a named owner (usually RevOps or a CS lead with analytical chops — not the data team alone, who will optimise it out of touch with the floor), a documented definition versioned like an API, and a quarterly recalibration where the model is audited against reality: pull the last two quarters of churns and renewals, check what the score said about them eight and sixteen weeks out, and confront the misses in a room with CSMs present.

The output of that meeting is not a new formula — it's usually a shorter one. Complex models die of their own maintenance cost and opacity; the five-component score with visible signals, a trend view and an alert budget will out-perform the seventeen-feature model that nobody dares touch. This holds across every analytics product we've built, from data-dense operational tables to board dashboards: legibility is a feature, and it compounds.

If you're designing this surface from scratch — or rescuing the traffic-light table nobody opens — it's core product design and engineering work: data modelling, interaction design and change management in one problem. Get the trust layer right and the score becomes the morning's first tab; get it wrong and you've built an expensive horoscope.

Key takeaways

• Keep the composite number for sorting, but make it decompose into named, visible components that CSMs can argue with and act on.
• Sort and alert on slope, not snapshot: decline rate surfaces rescuable accounts; thresholds fire late and cry wolf.
• Alerts are state changes routed to an owned queue, with precision measured monthly and a recovery digest to keep the channel alive.
• Share components with customers as their own insight; keep the composite internal. Never expose weightings.
• Assign a named model owner, version the definition, and recalibrate quarterly against actual churns and renewals.

FAQ

How many components is right? Three to five. Fewer and you can't diagnose; more and you've rebuilt the opaque composite at component level. If a proposed component doesn't suggest a distinct intervention, it's decoration — cut it.

What data do we need before starting? Less than you think: login cadence, two or three key workflow events, seat counts and support tickets cover a credible v1. Start with what you can compute reliably and let the quarterly review earn each new signal — it's far easier to add a component than to remove one the org has imprinted on.

Should the score predict churn explicitly? Call it what it is. If you run a model against churn outcomes, present probability-of-non-renewal as one component among several rather than rebranding triage as prophecy. Predictions belong in the calibration meeting; the interface should stay legible.

Product-led product, no CSMs — is any of this relevant? Yes, and the trend-over-snapshot rule matters more, not less. The "CSM" becomes lifecycle automation: slope alerts trigger winback and education flows instead of phone calls. Same signals, different actuator, identical trust requirements.

Red, amber, green — fine? Fine as shorthand inside a consistent system with text labels, never fine alone: colour-only signalling fails accessibility and prints as mush. Pair every colour with the word and the number, and check the palette against our colour-contrast guidance before it ships.