Health Scoring
Customer health scoring
Build an explainable customer health score from relevant signals, show missing data and use score changes to guide account decisions.
A customer health score is a structured view of evidence that may affect an account’s ability to keep getting value from a product. Use it to decide what to check and who should act. It is not a renewal forecast and does not replace speaking with the customer. A useful score shows its component signals, their dates and the uncertainty behind them.
Decide what the score is for
Choose the decision before the indicators. A success team might use a score to prioritise account reviews, notice a change in a key workflow or identify an unresolved relationship concern.
Those purposes overlap but need different evidence. If the question is whether a customer achieved a business result, ask for evidence of that result. Product activity alone cannot answer it.
Define the account unit too. A group with several divisions may have strong use in one division and a failed rollout in another. Decide whether to score the whole customer, a contract line or a particular relationship, and show that unit beside the result. Avoid averaging away a problem that needs a named owner.
GitLab’s framework illustrates why one organisation may keep separate scores for different jobs and audiences. Its Customer Health Score is for internal teams assessing customer health, while other scoring approaches serve distinct purposes. Keeping those views separate helps prevent an adoption measure from being treated as a complete account-health picture.
Build a small, inspectable set of signals
Choose observations relevant to the decision. Examples include product activity, progress on customer outcomes or relationship concerns.
| Signal | What it might reveal | Check before interpreting it |
|---|---|---|
| Use of the intended workflow | Whether eligible users complete the work the customer bought the product to support | Did the task arise during the period, and are the right users and account recorded? |
| Customer-confirmed progress | Whether the intended result is improving | Is the measure current, comparable and confirmed by someone who owns the outcome? |
| Service experience | Whether an issue prevents useful work | What is the customer’s impact, beyond a ticket count or status? |
| Relationship continuity | Whether the people who own the goal and decision are still engaged | Has a sponsor changed, or is contact simply less frequent by agreement? |
Keep observations separate from interpretations. An unanswered message is an observation; dissatisfaction is one possible explanation. A completed workflow is evidence of use; it does not establish that the wider business result improved. Record the source, period and account owner for each signal.
Use the customer’s task cycle when setting review periods. A quarterly task can look inactive on a weekly chart. New accounts may also lack enough history for measures used on established accounts. Mark a signal unavailable when it cannot yet be assessed.
Review Period Alignment with Customer Task Cycles
- Quarterly Task CycleA quarterly process may appear inactive on a weekly chart—use appropriate review intervals.
- New AccountLacks sufficient history for mature metrics—mark signals as unavailable until data accumulates.
- Mature Daily-Use ProductCan use consistent weekly or monthly monitoring due to stable usage patterns.
Make the calculation explainable
A scorecard can give each component a defined scale and weight, then combine the available components. Write down what a high or low value means, how it is calculated, when it refreshes and who can correct it. Choose weights for the decision the score is meant to support, then review them against account experience.
Check how your system handles missing data. An unavailable measure may affect the total, depending on the system and configuration. Show missing components and data coverage alongside the total. A stale assessment should not quietly carry the authority of a recent one.
Imagine a customer whose eligible users continue to complete the core task, while its process owner reports that a critical handoff fails. A blended number may look steady. The useful account view shows the healthy usage signal and unresolved outcome concern separately.
In Gainsight NXT, a scorecard can consist of measures, measure groups or both. It can be created for a Company or a Relationship, and its measures must match that entity type. This is a practical reason to decide and label the account unit before building the calculation.
Gainsight NXT allows an overall score to use an automatic weighted roll-up or manual entry. Its available score schemes are Numeric, Color and Grade. State which scheme is in use and whether the total is calculated or entered, so users know what the displayed result represents.
Gainsight also supports reports based on scorecard data. Use a report to inspect the underlying scorecard information alongside the overall result, rather than relying on a total detached from its component measures.
Check the score against decisions and outcomes
Before relying on a score, review past account snapshots as they would have appeared at the time. Compare their signals with later renewal decisions and customer-confirmed outcomes. Keep information learned after the snapshot out of the earlier score. Look at false alarms and missed concerns, including cases where the customer continued but reduced scope.
Review comparable accounts together. A new implementation, an infrequent workflow and a mature daily-use product should not automatically share thresholds. If there are too few comparable decisions to judge a pattern, describe the score as an operating aid under review, not a validated predictor. Recheck it after product, customer mix or data definitions change.
A concrete validation target can make score adoption and score quality distinct checks. GitLab’s stated success criteria included a health score for more than 95% of customers, aligned to FY24 Yearlies, and a framework backtested and validated as effective and beneficial. These are GitLab criteria, not a universal threshold for other organisations.
Turn a change into a specific question
Give the account owner the total, the component that changed, the observation period and the data limit. Then ask what account fact would confirm or overturn the concern.
A fall in workflow completion may call for an instrumentation check or a question to the process owner. A reported service problem calls for its impact and response owner. The score indicates where to look; the account investigation determines the action.
Record the decision: investigate, act, monitor or correct the data. Name an owner and a review point. When the customer’s explanation changes the interpretation, update the account record rather than forcing it into an old colour.
Decide whether a score is an internal working view or something intended for customers. GitLab distinguishes its internal Customer Health Score from a customer-facing Value Stream Management dashboard. That example supports keeping audience and purpose visible, rather than assuming every account score is suitable to present as a customer-facing measure.
In this guide
- Choosing health indicators from observed renewal behaviourUse past renewal decisions and earlier account snapshots to choose health indicators, while checking missing data and false alarms.
- Combining usage and relationship signals carefullyCombine product use and customer relationship evidence while keeping missing data, stale assessments and conflicting signals visible.
- Explaining a health score to an account ownerExplain what changed in a customer health score, where the evidence is limited and what the account owner should verify next.
