What belongs in a customer success dashboard (and what doesn't)

Start with the decision, not the metric

The usual process is backwards: list the available metrics, put them on a screen, arrange them nicely. You get something that describes the past accurately and changes nobody's day.

Invert it. Write down the decisions a CSM makes in a week: who to call, what to say, what to escalate, which renewal to worry about, where to push for expansion. Then work backwards to the smallest number of signals that inform those five decisions.

You almost always end up with fewer widgets and a tool people actually use.

The five that earn their place

1. Health, with the reason attached

A score on its own is useless. "Acme: 62" tells a CSM nothing actionable. "Acme: 62, down 14 since the admin left and weekly active users fell by a third" tells them who to call and what to open with. Always ship the score with its top contributing factors.

2. Renewal runway, with the work required

Not a list of dates. A view that shows what needs to happen before each date and whether it has happened: has the business review been booked, is the economic buyer engaged, are there open escalations. A renewal date without the work attached is a calendar, not a dashboard.

3. Engagement change, not engagement level

Absolute usage tells you how big an account is. The derivative tells you what is happening. A heavy user dropping 30% in three weeks is the most valuable signal in customer success, and it is invisible on any dashboard showing only current totals. Show the delta, and show it against the account's own baseline rather than a global average.

4. Open risk, in one place

Every unresolved thing that would embarrass you in a renewal conversation: escalated tickets past their expected resolution, unmet commitments, bugs affecting this account, unanswered exec emails. Scattered across four systems, these get missed. Together, they are a call list.

5. One expansion signal

Exactly one, chosen to match how your product actually grows: seat utilisation against entitlement, a module used by a neighbouring team, usage bumping a plan limit. CS teams are increasingly measured on growth, and one well-chosen signal beats a whitespace matrix nobody has time to read.

What to leave out

• NPS as a headline number. Lagging, sparse, and easily moved by who happened to respond. Useful as a trend at company level, near-useless for deciding who to call on Tuesday.
• Raw ticket volume. A high-volume account might be deeply engaged or badly onboarded. Without context, the number causes wrong conclusions. Show tickets breaching expectations instead.
• Logins. Presence is not value. Someone logging in daily to export a CSV they need because your reporting is poor is not a healthy account.
• Anything nobody can act on. If a CSM cannot change it, it belongs in a leadership report, not a working dashboard.
• Fourteen widgets. Every additional tile costs attention. If a metric has not changed a decision in three months, remove it.

Building a health score that isn't fiction

Most health scores are invented weights on convenient data, which is why nobody trusts them and everyone keeps a private spreadsheet instead.

A defensible one is built like this:

1. Start from churned accounts. Take everyone who left in the past 12–18 months and look at what was observable 90 days before they gave notice. Not at the end, when it was obvious. Ninety days out, when it was still preventable.
2. Find the two or three signals that actually preceded it. Usually a mix of usage decline, champion departure, and a support pattern. Rarely more than three that matter.
3. Weight by observed predictive power, not opinion. If champion departure preceded churn far more reliably than ticket volume, it should dominate.
4. Test against accounts that renewed. A score that flags everything is as useless as one that flags nothing. Check the false-positive rate before shipping.
5. Publish the formula. CSMs trust a score they can explain and argue with. An opaque number gets ignored, and so does the dashboard around it.

Recalibrate roughly annually. What predicted churn last year drifts as the product and the customer base change.

Getting it opened

A dashboard nobody opens is a failed project regardless of quality. What actually works:

• Replace something. If the dashboard sits alongside the spreadsheet the team already maintains, the spreadsheet wins. Make it strictly better and retire the spreadsheet deliberately.
• Push, don't wait. A Monday digest of accounts that changed status beats hoping people remember a URL.
• Sort into a call list. Default the view to "accounts needing attention, ranked", not an alphabetical account table.
• Let CSMs disagree with it. Let them dismiss a flag with a reason. You get better data and they stop resenting the score.
• Use it in the weekly meeting. If the manager runs pipeline review off the dashboard, adoption solves itself. If the manager keeps their own spreadsheet, nothing you build will get used.

Build notes

Practical constraints worth deciding early:

• Data sources. Typically CRM for the commercial picture, product analytics or the application database for usage, support desk for tickets, billing for contract values. Four sources is normal and is usually why a platform cannot do this out of the box.
• Refresh rate. Daily is almost always enough. Real-time is expensive and changes no CS decision.
• Permissions. CSMs see their book, managers see their team, executives see the roll-up. Decide this before building, because retrofitting per-user scoping is significantly harder than designing it in.
• Write-back. If a CSM logs a risk in the dashboard, it should land in the CRM. Otherwise you have created a second system of record and made the original problem worse.

For how this fits alongside sales and AM tooling, see our guide to custom GTM tools. If you are weighing this against a health-scoring platform, our build-vs-buy framework has the five tests.