A CSM opens Monday's customer health dashboard and sees ten red accounts.
One has a renewal next month. Another has a serious support escalation. A third has falling usage, although the customer is seasonal and usually quiet at this point in the year.
The dashboard has surfaced risk. It has not yet helped the team decide what to do.
That gap matters. A useful customer health dashboard brings customer signals together so a team can identify risk, explain movement, assign ownership and review whether action is happening. The Customer Health Score may sit inside it, but the score is only a summary. The dashboard has to show the evidence behind the summary and the decision that comes next.
Start with decisions, not available data
Weak dashboards often begin with a data inventory. The team asks what it can track, then fills a page with usage, tickets, survey scores, renewal dates and account labels. The result can look comprehensive while changing very little.
Start with the decisions the dashboard must improve:
- Which accounts need attention this week?
- Which risks are becoming common across a segment?
- Which accounts need executive involvement?
- Where is renewal exposure concentrated?
- Which interventions are overdue or blocked?
- Which health signals are too stale or incomplete to trust?
This decision-first approach fits general dashboard design practice. Microsoft advises designing dashboards for the intended audience, showing the current state at a glance, avoiding clutter and placing important information prominently (Microsoft Learn).
Use this test before adding a metric:
| Question | Keep the metric when... | Remove or demote it when... |
|---|---|---|
| What decision does it support? | It changes priority, diagnosis, ownership or escalation | It is interesting but does not affect action |
| Who needs it? | A specific role uses it in a review or workflow | Everyone might want it someday |
| How fresh is it? | Its update rhythm matches the decision | It is old but still displayed as current |
| What can go wrong? | The team understands the definition and caveats | It can be misread without context |
The first screen does not need to answer every account question. It should make the next useful question obvious.
What a customer health dashboard should measure
A good dashboard balances breadth with clarity. Too few measures hide important risk. Too many make the page unreadable and encourage teams to debate the data rather than act on it.
For most SaaS Customer Success teams, the useful categories are health status and trend, adoption and value evidence, support experience, relationship strength, customer sentiment, commercial risk, data confidence and ownership.
| Dashboard category | Example measures | Decision supported | Common trap |
|---|---|---|---|
| Health status and trend | Current band, score movement, recent driver changes, accounts moving between bands | Where should attention go first? | Treating red, amber and green as self-explanatory |
| Adoption and value evidence | Meaningful usage, breadth of adoption, onboarding milestones, key workflow completion, outcome progress | Is the product still embedded in valuable work? | Counting logins as proof of value |
| Support experience | Ticket themes, escalations, unresolved high-severity issues, first reply time, resolution time | Is friction damaging confidence or blocking value? | Combining support measures without shared definitions |
| Relationship coverage | Sponsor status, meeting recency, stakeholder map, response gaps, champion change | Is the relationship resilient enough? | Assuming one friendly contact equals account health |
| Sentiment and voice of customer | NPS, CSAT, survey participation, comments, call and ticket themes | What is the customer saying, and who is saying it? | Treating sentiment as the whole health model |
| Commercial and renewal risk | Renewal date, revenue exposure, contraction requests, procurement blockers, billing issues | What is commercially exposed and when? | Confusing renewal proximity with preventable risk |
| Data confidence | Freshness, completeness, source coverage, missing measures, last update, known caveats | Can the team trust this account view? | Showing stale data as if it were reliable |
| Ownership and next action | Account owner, escalation owner, next step, due date, action status | Who is doing what next? | Creating alerts without accountability |
Support metrics show why definitions matter. Zendesk defines first reply time as the period between ticket creation and the first public agent comment, with channel and reporting details that affect interpretation (Zendesk). If one team measures first public reply and another measures any internal response, the dashboard may compare unlike things.
Sentiment needs the same discipline. NPS is based on a recommendation question and reported on a -100 to +100 scale, but Qualtrics warns against treating NPS in isolation (Qualtrics). A detractor response from an executive sponsor carries different weight from a passive score submitted by an occasional user. Both may matter, but neither tells the whole account story alone.
Commercial risk belongs on the dashboard when it affects customer decisions. Customer churn and revenue churn can tell different stories, as ChartMogul explains in its churn guidance (ChartMogul). Failed payments may also be recoverable operational issues rather than signs of product dissatisfaction; Stripe's revenue recovery documentation frames failed subscription payments as a billing problem that can often be addressed (Stripe).
Build separate views for separate jobs
One universal dashboard rarely serves everyone well. Leaders need patterns and exposure. CSMs need account evidence and next action. RevOps needs definitions, coverage and workflow quality.
Build separate views around the work each group performs:
| View | Primary user | Should show | Should avoid |
|---|---|---|---|
| Portfolio view | CS leaders, founders, revenue leaders | Risk distribution, revenue exposure, trend by segment, top drivers, capacity constraints, overdue escalations | Long account notes, raw event feeds, every source metric |
| Account view | CSMs and account owners | What changed, why it changed, evidence timeline, source freshness, open risks, next action, owner and due date | A score with no explanation, disconnected charts |
| Operations view | RevOps and system owners | Metric definitions, stale inputs, missing sources, sync failures, model coverage, workflow hand-offs | Customer storytelling that hides data-quality problems |
An executive should be able to see that enterprise onboarding risk is rising across a segment. A CSM should be able to open one account and see that onboarding progress slipped after two unresolved implementation tickets and a missed sponsor meeting. RevOps should be able to see that a support source has not updated for three days, which means the apparent improvement may not be real.
GitLab's public customer health material is useful here because it treats account health as a combination of multiple lenses, including product, risk, outcomes, voice of customer and engagement, and describes customer health in a portfolio dashboard (GitLab Handbook). The lesson is not to copy another company's model. It is to make the dashboard broad enough to explain risk without flattening every account into a single label.
Show evidence quality, not just evidence
Missing data is not neutral. A green account with fresh adoption, recent stakeholder engagement and resolved support issues is different from a green account whose usage feed has failed and whose last relationship update is three months old.
The UK Government Data Quality Framework describes data quality as fitness for purpose and highlights dimensions such as completeness, uniqueness, consistency, timeliness, validity and accuracy (UK Government Data Quality Framework). For customer health, "fitness for purpose" is the right standard. The question is not whether the dataset is perfect. It is whether it is good enough for the decision being made.
At account level, show:
- when each signal last updated;
- which expected sources are missing;
- whether a key measure is stale;
- whether the account health view has low confidence;
- whether a human override exists and why;
- what evidence most influenced the latest movement.
GitLab's handbook also makes stale and missing measures visible, including cases where measures become `NA` after defined periods (GitLab Handbook). That is a useful principle for any customer health dashboard. If a measure is too old to trust, the dashboard should say so rather than quietly pretending certainty.
| Weak dashboard pattern | More useful pattern |
|---|---|
| Green account shown with no caveats | Green account shown with fresh evidence and source coverage |
| Red account shown with no driver | Red account with top drivers and recent timeline |
| Every metric placed on the first screen | Exceptions and trends first, drill-down for detail |
| Alerts sent to a shared inbox | Named owner, due date and action status |
| Definitions hidden in someone's head | Definitions visible or linked from the dashboard |
Automation and judgement need to work together. Automated signals can spot movement, but human context still matters. A usage drop may indicate churn risk, seasonal behaviour, completed project work or a change in the customer's operating model. The dashboard should help the CSM validate the cause before the team acts.
Connect dashboard signals to workflow
A dashboard that does not change behaviour becomes a presentation. It may be opened in weekly meetings, discussed for an hour and then ignored until the next review.
For each material risk, the dashboard should answer five operational questions:
- What changed?
- Why does it matter?
- How reliable is the evidence?
- Who owns the next step?
- When will the action be reviewed?
Consider an illustrative account view. The health band has moved from amber to red. The top drivers are a stalled onboarding milestone, two repeated support issues and no sponsor meeting in six weeks. The usage chart alone would not explain the risk. The support trend alone would not either. Together, they suggest the account is struggling to reach value and may lack senior attention.
A useful dashboard would assign a named owner to validate the cause, confirm whether the stalled milestone still matters to the customer and agree the next customer-facing step. It would not simply send a red alert and assume the CSM can work out the rest.
The review cadence should match the portfolio and pace of change. A high-volume, digitally served customer base may need frequent operational review of exceptions. A lower-volume enterprise portfolio may need a weekly account-risk review and a monthly or quarterly dashboard-governance review. Treat these as professional starting points, not universal benchmarks.
Common mistakes to avoid
The most common dashboard mistakes are usually design and governance mistakes.
Starting with available data. Available data is not always decision-grade data. Begin with the decisions and add measures that improve them.
Using one dashboard for every role. Leadership, CSM and RevOps views have different jobs. Forcing them into one view creates clutter and compromise.
Trusting colour without evidence. Red, amber and green labels should open into drivers, freshness and owner information.
Over-relying on product usage. Usage is important, but product activity alone may miss relationship, support, sentiment and commercial risk.
Ignoring missing or stale inputs. Old evidence should lower confidence or trigger review. It should not quietly support a reassuring status.
Creating alerts without capacity. If every small movement creates an alert, the team will learn to ignore the dashboard. Prioritise material, actionable change.
Hiding definitions. A support leader, CSM and revenue leader should understand what each metric means. If they do not, the dashboard will create argument rather than alignment.
Skipping governance. Health dashboards drift. Products change, customer behaviour changes, data sources break and teams invent workarounds. A dashboard needs maintenance.
Keep the dashboard honest over time
Use this checklist in a monthly or quarterly dashboard review, depending on customer volume, model maturity and the rate at which your operating model changes.
- Are the top dashboard decisions still the right ones?
- Which alerts led to useful action?
- Which alerts were false positives or too noisy?
- Which risks were missed until late?
- Which sources are stale, incomplete or poorly defined?
- Which metrics are being ignored by CSMs or leaders?
- Are owners and next steps being completed, or merely recorded?
- Do segments need different thresholds or views?
- Has any product, packaging or process change made a measure less useful?
- What should be removed from the first view?
The final question matters. Dashboards tend to accumulate metrics because removing something feels risky. But a crowded dashboard hides the work. Keep the first view focused on decisions, movement, evidence quality and action. Let the detail sit one level down where it can support diagnosis.
Build a dashboard the team can operate
A customer health dashboard earns its place when it helps a team make better operating decisions. It should show where to look, why health changed, how reliable the evidence is and who owns the next step.
The Customer Health Score can help prioritise attention, but it should not be asked to carry the whole relationship story. Pair it with drivers, trends, source freshness, role-specific views and a review rhythm that keeps the dashboard honest.
The practical test is simple: if an account changes health today, can the right person see what changed, understand the evidence and know what to do next? If the answer is no, the dashboard needs less decoration and more operating discipline.