How to Build a Customer Health Score Dashboard for Your SaaS

A customer health score is the most overrated and most under-implemented metric in SaaS.

Overrated because most teams build a fancy 0-100 score nobody acts on. It sits in a Looker dashboard, gets glanced at on Monday morning, and dies. Under-implemented because the simple version — five weighted signals, color-coded red/yellow/green, refreshed weekly, with a clear playbook attached — actually works. Teams that ship the simple version see churn drop 15-30% within two quarters. Teams that try to ship the perfect version usually ship nothing.

This guide is the playbook for the simple version. What signals to pick, how to weight them, what the dashboard should look like, where to build it, and what to do when an account turns red. By the end you should have a dashboard you can stand up in a week and a CSM playbook your team will actually run.

Before you pick signals or weights, get clear on what the score is for. A health score is not a vanity number. It is a triage tool. It should answer three questions, in priority order:

If your dashboard does not answer those three questions in under thirty seconds, it is decoration. The whole point is to convert a noisy stream of product, support, and billing data into a short list of accounts your team can act on this week.

There are dozens of signals you could track. Most teams start with too many, drown in data engineering, and never ship. The honest answer is that five signals cover roughly 85% of the predictive power for most B2B SaaS products. Here they are, ordered by how much they typically contribute to a usable score.

How often do users from this account log in and complete a meaningful action? Not page views — meaningful actions. For a CRM, that is creating a contact, sending an email, logging a call. For a project tool, it is creating tasks, completing tasks, commenting. For an analytics tool, it is running a query or building a chart.

The metric to track: weekly active users (WAU) per account, trended over the last 8 weeks. The signal you care about is not the absolute number — it is the slope. A 20-user account averaging 12 WAU that drops to 6 WAU is in trouble. A 5-user account averaging 4 WAU that holds steady is fine.

Quick formula for a 0-100 sub-score: `engagement_score = min(100, (current_WAU / baseline_WAU) * 100)` where baseline is the trailing 4-week average from weeks 5-8 ago. Anything below 60 starts costing the account points.

Accounts that use one feature churn. Accounts that use four or five features rarely do. The mechanism is obvious: every feature an account integrates into their workflow becomes a switching cost.

Define 5-8 "core features" of your product — the ones that, if a customer uses them, they are clearly getting value. For a SaaS CRM that might be: contacts, deals, email sync, automation, reporting, integrations. Track how many of those features each account has used in the last 30 days.

Sub-score: `feature_score = (features_used / total_core_features) * 100`. An account using 6 of 8 core features scores 75. An account using 1 of 8 is at 12 and is one strategic conversation away from churn.

Support data is a two-way signal. A flood of tickets is bad. Zero tickets is also often bad — it can mean the account is disengaged. The shape that predicts churn most cleanly is rising ticket volume combined with negative sentiment.

Track two things per account over the last 30 days: ticket count and the share of tickets tagged frustrated, escalated, or critical (most helpdesks now expose sentiment via tags or AI classification). Compare to the trailing 90-day average.

Sub-score: start at 100. Subtract 5 points per ticket above the account's 90-day baseline. Subtract 15 points for any escalation. Subtract 30 points for an unresolved escalation older than 7 days. Floor at 0. Cap the deduction at 40 points so a single bad week does not crater the score.

Survey scores are noisier than product data, but they capture something product data cannot: how the customer *feels* about you. A power user who hates their CSM will still churn at renewal. A light user who loves the product will renew and refer.

Track the most recent NPS or CSAT response per primary contact at the account, weighted by how recent it is. A 9 from three weeks ago beats a 7 from six months ago.

Sub-score: map NPS 0-10 to 0-100 with a non-linear curve that punishes detractors and rewards promoters. A simple version: `nps_score = nps_value * 10` floored at 0, then subtract 30 if the latest response is older than 90 days (stale responses are unreliable).

The most under-rated signal in customer success. A failed payment, a downgrade, or a card on file expiring next month is often the loudest churn signal you have — and it sits in your billing system, frequently disconnected from the CS dashboard.

Track three states per account: payment status (current / past due / failed), recent plan changes (upgrade / no change / downgrade in last 90 days), and card expiration risk (does the card on file expire in the next 30 days).

Sub-score: start at 100. Past due → 60. One failed payment → 40. Two or more failed payments → 0. Recent downgrade → subtract 25. Card expiring in 30 days with no backup → subtract 10. This sub-score is binary in spirit: anything below 60 is a bright red flag that should ping the AE and CSM the same hour it changes.

Weights matter more than the signals themselves. Two teams with the same five signals but different weights will get wildly different lists of "at risk" accounts. There is no universally correct weighting — it depends on your product, your contract length, and where churn actually comes from in your data. But here is a sane starting point that works for most B2B SaaS products with monthly or annual contracts.

Recommended starting weights:

Final formula: `health_score = (engagement * 0.30) + (feature_breadth * 0.20) + (support * 0.20) + (nps * 0.15) + (billing * 0.15)`.

Two important rules. One: the billing signal is an override. Two failed payments forces the account to red regardless of the calculated score. A power user with a busted card is still about to churn. Two: revisit weights every quarter. Pull the last 90 days of churned accounts, look at their scores in the 60 days before they churned, and ask whether your model would have flagged them. If most churned accounts were green or yellow, your weights are wrong — usually engagement and billing should be heavier.

A 0-100 score is for engineers. A red/yellow/green band is for the CSM who has 80 accounts and 30 minutes a day. Map the score to bands:

A good health score dashboard has three views, in this order. If you build only one, build the first.

A flat table of every paying account, sorted by score ascending (worst at top). Columns: account name, MRR, current score, score change vs last week, owning CSM, last touchpoint date, primary risk signal. Filter chips at the top: red only, yellow only, my accounts, $5K+ MRR, missed renewal in next 60 days.

This is the view your CSM team opens every Monday morning. The job: scan the top 20 accounts, decide which ones get a call this week, and assign tasks. If a CSM cannot identify their top three intervention targets in 60 seconds from this view, the dashboard is not doing its job.

Click an account, see the score breakdown by signal. A radar chart or stacked bar showing engagement, feature breadth, support, NPS, billing — each as its own sub-score. A timeline of score changes over the last 12 weeks with annotations ("score dropped from 78 to 42 on March 14, triggered by escalated ticket and 3-week login gap"). Last 5 support tickets, last 3 product activity events, billing status, NPS history.

This is the view a CSM opens before a save call. The goal: walk into the conversation knowing exactly what to talk about, not just "the score went down."

An aggregate view across the entire customer base. Distribution of scores (how many red, yellow, green) trended over time. Average score by plan tier, by industry, by CSM, by acquisition source. Churned accounts overlaid with their score 60 days before they churned (the validation loop for your weighting).

This view is for the VP of CS, the head of RevOps, and the founder. The job: spot systemic problems. If your enterprise tier has a 25% lower average score than your mid-market tier, something is broken in onboarding for big customers. The score is your early warning.

There are three reasonable places to put the dashboard, and your choice depends on data maturity and team makeup.

Build it in your CRM if your CS team lives there already, your account record is the natural home for a score, and you want CSMs to see the score in the same place they take notes and log calls. This is what most teams should pick. The score becomes a custom field, the dashboard is a saved view, and intervention tasks are CRM tasks.

Build it in a BI tool if you have a data warehouse with product events, billing, and support data already piped in, and you have an analytics engineer who can model dbt-style. The advantage: every signal is queryable and you can iterate weights in SQL. The disadvantage: BI tools are not built for action — CSMs cannot easily turn a row into a task.

Build a custom internal app if you have signals nobody else handles (industry-specific usage data, custom integrations) and you have engineering capacity. Most teams should not start here. It is expensive and the V1 is rarely better than the CRM version.

A score with no playbook attached is a number. A score with a playbook attached is a system. Define what happens automatically when an account moves between bands. Here is the version most teams should run:

If your CS team already lives in Deelo CRM, the health score lives where they work. Each account has custom fields for engagement_score, feature_breadth, support_signal, nps_score, billing_status, and the calculated overall_score. A saved CRM view sorts every paying account by score ascending and color-codes the row red/yellow/green based on the band.

Deelo Analytics ingests product events from your app, support tickets from Helpdesk, NPS responses from Forms, and billing events from Stripe (or whichever processor you use). A weekly scheduled automation recalculates every account's score, updates the CRM custom field, and triggers the playbook: red accounts auto-create a CSM task with a 48-hour SLA, yellow accounts get an automated check-in email through the email app, green accounts with high breadth surface in an expansion-ready saved view.

The drill-down view lives on each account record — score history sparkline, signal breakdown, recent support tickets, last activity events, billing status. CSMs walk into save calls knowing exactly which signal moved and when. Cost is bundled into the Deelo subscription rather than a separate $50K/year BI seat. For SaaS teams under 50 employees who want a working health score system in a week instead of a quarter, this is the fastest path.