Building a Customer Health Score Dashboard for SaaS CS Teams

Most SaaS companies build some version of a customer health score at some point. A spreadsheet that pulls NPS and last login date. A Gainsight implementation that never quite gets configured the way the CS team actually wants. A handful of Looker dashboards that show the inputs but don't synthesize them into something actionable.

The pattern is consistent: the underlying data exists, but getting it into a form that a customer success manager can act on — without a data analyst involved — is the hard part. A custom health score dashboard solves this.

What a customer health score actually measures

A health score is a single number (or a small set of signals) that summarizes the likelihood that an account will renew, expand, or churn. The useful version isn't just a gut-check — it's a weighted composite of objective signals that your team has validated actually correlate with outcomes.

The common mistake is building a health score that measures activity rather than value realization. An account that logs in daily but never activates the features that justify their plan cost is not healthy — it's at risk. The signals that actually predict churn tend to be: feature adoption relative to the customer's plan tier, decline in active user count, open support tickets older than 14 days, approaching or exceeding usage limits without upgrading, and missed business reviews.

The signals that matter

Product usage: Daily and monthly active users, feature adoption by tier, and trend (growing, stable, or declining). The most predictive signal is usually whether the customer is using the features they specifically purchased.

Billing signals: Days until renewal, payment failures in the last 90 days, and whether they're on a contract or month-to-month. Month-to-month accounts with declining usage are the highest-risk segment.

Support signals: Open ticket count, time-to-resolution trends, and whether recent tickets involve core workflow issues (a different signal than "how do I use this?" questions).

Engagement signals: Last executive sponsor login, NPS score and trend, last business review date.

Each signal needs a weight. Weights should be validated against historical data — which signals in your specific product actually predicted churn for accounts that churned? Generic weights from a Gainsight template are a starting point, not the answer.

How to build the dashboard

The technical implementation has two parts. The first is the score computation: a scheduled job (daily is usually sufficient) that pulls signals from your product database, billing system, and support tool, applies weights, and writes a score and signal breakdown per account to a dedicated table.

The second is the UI: a filterable account list sorted by health score, with a per-account detail view showing the score breakdown (which signals are dragging the score down), renewal date, CSM owner, and a notes/activity log. This is the surface the CS team actually works in.

The critical design decision is making the score explainable. A number without context doesn't drive action. When a CSM sees an account at 42/100, they need to see that the score is low because active users dropped 40% last month and there's an open critical ticket — not just a red number.

How CS teams use health scores to drive retention

The operational value of a health score dashboard is in the workflows it enables. A weekly triage: every Monday, the CS team reviews accounts that dropped more than 10 points in the previous week and assigns follow-up actions. An early warning filter: accounts below a threshold score (e.g., 50) with renewals in the next 90 days get flagged for an executive business review. A capacity model: CSMs with books of business weighted by health score can see where their attention is most needed.

At 200 accounts, this is manageable without tooling. At 500+, without a health score dashboard, customer success becomes reactive — you find out about churn when the cancellation comes in, not 90 days before.