Customer Health Score Template: See Subsidiary Risk Behind the Group Average

What a customer health score should tell an enterprise team

A customer health score is a structured summary of the condition of an existing customer relationship. It brings together evidence about whether the customer is using the service, achieving the intended outcome and receiving the support needed to continue. In a corporate group, the relevant customer may be a particular operating entity, deployment or business unit rather than the parent company named on the account.

The practical question is whether a team can explain the condition of each important deployment before discussing additional scope. A healthy parent relationship can coexist with an unresolved implementation problem at a subsidiary. Equally, a local team can be succeeding while the central sponsor is changing. A single group colour cannot explain both situations unless the underlying evidence remains visible.

Use a health score to organise a review, not to replace it. The score should help the customer team identify what needs attention, what evidence is missing and who owns the next action. A numerical result does not establish renewal intent, customer satisfaction, buying authority or a willingness to purchase another product. Each of those conclusions needs its own evidence.

This guide provides a customer health score template for that operating task. It differs from predictive account scoring, which evaluates a model used to rank prospective outcomes. It also differs from account penetration, which measures coverage against a defined universe. Health describes the current relationship; coverage describes where a relationship exists.

Choose the entity, deployment and period before the metrics

Write the scope at the top of the scorecard: the customer group, operating entity, offering, deployment and observation period. Include the person responsible for interpreting the result. An entity can operate two products with different conditions, while one deployment may serve several subsidiaries. The reporting unit should reflect the decision the customer team needs to make rather than whichever identifier is easiest to export.

Distinguish the legal entity from the commercial account and the user workspace. A central buyer might hold the agreement while local teams own adoption. Record the supported relationship between those objects, and retain a shared-deployment label where local attribution is not available. Do not copy a group-level usage figure into every subsidiary and call the resulting rows local health.

The CRM account hierarchy guide covers the structural model. The customer data integration guide covers joining billing and usage without multiplying facts. Treat those as prerequisites. A health scorecard should consume correctly scoped evidence and disclose its limits, rather than silently repair ambiguous relationships through a scoring formula.

Use a stable comparison period. A monthly score based on thirty complete days is not directly comparable with an incomplete week after a migration. Record the observation window and data cutoff separately from the review date. Where an acquisition changes the group boundary, explain whether the view follows the original set of deployments or the current group, so readers understand what changed.

A customer health score template that keeps evidence visible

The template below is an operating specification, not a universal scoring formula. For every measure, keep a definition, scope, observation, source date, interpretation and owner. The fields make the scorecard useful even before the team agrees a numerical weighting. A blank field should produce a review question, rather than an assumed favourable or unfavourable value.

Start with a small set of measures that reflects the service promised to this customer. Product activity matters only when it relates to the intended workflow. A batch-processing service can deliver value with few logins; a collaboration product might need active participation by several roles. Ask what behaviour would demonstrate the agreed use case, then preserve that definition with the measure.

If a numerical local index is useful, define each dimension’s scale and direction before combining it. Explain what each endpoint means for the agreed workflow, normalise only genuinely comparable measures and document the weights. For illustration, three fully observed dimension values of 60, 80 and 100 on comparable zero-to-one-hundred scales would average to 80 under equal weights. This is a proposed arithmetic example, not a validated health model. If a required dimension is unknown, retain an incomplete status rather than silently dropping it and inflating the remaining average. Keep the critical-issue rule separate from this calculation.

Include customer-confirmed outcomes where available. An internal activity count is evidence of activity, not automatically evidence of customer value. Record the stated objective, the agreed way to assess progress and the latest customer discussion. When an outcome has not been confirmed, label it unconfirmed and assign a follow-up instead of substituting a convenient engagement metric.

Separate support condition, stakeholder continuity and commercial administration. A severe unresolved service issue should remain visible even if usage is high. A missing sponsor is a relationship question, while an invoice dispute can require a billing owner. Combining them into one number before identifying their owners makes the scorecard harder to act on.

Why a healthy group average can hide a weak subsidiary

Consider two fictional deployments: Aster UK has an illustrative health index of 80 and Aster Germany has an index of 30, each on a zero-to-one-hundred scale. These numbers are invented to explain aggregation. They are not customer data, vendor ratings, validated thresholds or probabilities of renewal. The underlying index definitions are assumed comparable only for this arithmetic example.

If the UK receives 80% of the aggregate weight and Germany receives 20%, the weighted result is 70: 80 multiplied by 0.8, plus 30 multiplied by 0.2. An equal-weight average would be 55. Both calculations are arithmetically correct, but they answer different aggregation questions. Neither makes the German deployment healthier or explains why its condition requires attention.

The interactive comparison lets you change the UK weight. At zero, the weighted average equals Germany’s 30; at one hundred, it equals the UK’s 80. Germany still appears with its local index when its aggregate weight is zero. Excluding its influence from a management summary should not erase it from the account team’s responsibility or conceal an unresolved customer problem.

Choose weights for a documented reporting purpose. Revenue weighting may describe financial exposure, while deployment weighting gives each included deployment equal influence. Neither is automatically the right measure of customer condition. Do not interpret corporate ownership percentages as health weights. Keep the local values, the chosen basis and the limitations alongside any summary so that a reviewer can challenge the result.

Keep critical issues and missing evidence outside the average

A useful scorecard needs decision rules in addition to arithmetic. An unresolved critical issue can require immediate service review regardless of the average. Missing evidence requires investigation, even if the available signals look positive. Treat these as explicit states with named owners, rather than forcing every situation into a red, amber or green score.

The evidence gate below is a fictional review policy with three requirements: current usage evidence, evidence about the customer outcome and a confirmed local owner. It also asks whether a critical issue remains unresolved. These requirements illustrate how to make a decision explainable; a real implementation must define the evidence and escalation rules appropriate to its own customer workflow.

The order matters. A critical unresolved issue routes the case to issue resolution first. Without such an issue, an incomplete evidence set routes it to evidence collection. Only when all three requirements are present and no critical issue remains does the case become ready for customer review. Ready means the team can discuss the evidence; it does not mean an expansion has been qualified.

Define what qualifies as critical before using the gate. Give the relevant service or account owner authority to open and close the condition, with a reason and date. A closed ticket does not necessarily establish that the customer’s problem is resolved. Record the agreed resolution evidence and any remaining limitation, especially when several subsidiaries depend on the same service.

Distinguish engagement, product use and customer value

Current sales-intelligence documentation reinforces the need to distinguish signals. Demandbase’s Engagement Points guidance, updated on 31 July 2026, describes engagement measurement. Engagement can inform a customer discussion, but it is not a complete assessment of product outcomes or service condition. Cognism’s customer-growth guidance likewise discusses usage, customer feedback and expansion work as different inputs. The practical lesson is to preserve the meaning of each signal.

A webinar attendance, a site visit and a support interaction may all create visible activity. They should not be interpreted as equivalent demonstrations of customer value. A support spike could reflect adoption, a product problem or a change in reporting. Record the context and the person responsible for interpretation before converting an event count into a health change.

Survey responses also need scope. Feedback from the central sponsor may not describe the experience of a local operator. A single response cannot speak for every deployment, and a missing response is not a negative answer. Keep the respondent’s relevant role, the question and the observation date available to authorised reviewers without exposing unnecessary personal information.

Use comparison groups cautiously. A newly launched deployment, a mature account and a seasonal workflow may have different expected activity patterns. Compare each with its agreed operating context before interpreting a decline. If the service or instrumentation changes, document the break in comparability. A clean trend line should never conceal a change in how the metric was collected.

Work through a subsidiary review before proposing expansion

Imagine the fictional Aster group is considering a discussion about a second workflow. The account team sees the weighted index of 70 and initially plans a group-wide proposal. The local scorecard reveals that Germany’s index is 30 and that the customer outcome has not been confirmed there. That finding changes the next action: investigate the local condition before treating the group summary as a reason to expand.

The team checks whether the UK and German deployment definitions are comparable, whether their observation periods are complete and whether a shared workspace has distorted attribution. It then asks the local owner to explain the customer’s intended workflow. If the data is incomplete, the team records that uncertainty. It does not infer dissatisfaction, churn risk or a commercial opportunity from a low unexplained number.

Suppose the review confirms an unresolved service issue in Germany. The service owner agrees the recovery action and what evidence will demonstrate resolution. The account lead records the dependency in the group plan. The UK can continue its own evidence-based customer conversation where appropriate, but success in the UK is not used to overwrite Germany’s unresolved condition.

Once the issue is resolved and the required evidence is current, the German case becomes ready for customer review. The team can then ask whether the original objective has been achieved and whether an additional workflow is relevant. Use the white-space analysis method for that separate qualification step. A health improvement is useful operational evidence, not an automatically created opportunity.

The fixed comparison below returns to the original illustrative values. It places both local indices beside the weighted and equal-weight summaries. The purpose is to make the aggregation choice visible. It does not recommend a universal health threshold, claim that equal weighting is fairer or suggest that a particular index predicts a sales result.

Make the scorecard part of a review process

Assign an owner to every required input and an owner to the final customer review. These may be different people. Product operations can verify the usage window; customer success can confirm the outcome discussion; a service lead can own the critical issue; the account lead can coordinate the next conversation. A shared dashboard does not remove the need for those responsibilities.

Set a freshness rule appropriate to each measure. A usage extract may refresh daily, while an outcome review may be agreed monthly or at a milestone. Show the actual source dates rather than one reassuring overall timestamp. When required evidence becomes stale, change its status and explain which conclusion can no longer be supported. Do not keep an old positive result indefinitely.

Preserve an audit trail for overrides. If an authorised reviewer changes an interpretation, record the reason, supporting evidence, effective date and next review. An override should be visible to the people who use the scorecard. Otherwise a manual adjustment can make the index appear precise while hiding an unresolved disagreement about the customer’s condition.

Keep access proportional to the task. A sales user may need an approved aggregate and the next action without seeing individual product activity or private support details. Apply the organisation’s data-use and retention requirements to the scorecard and its exports. Corporate affiliation does not grant unrestricted access to every subsidiary’s customer information.

Evaluate a customer health dashboard with real acceptance cases

Ask a provider or internal team to demonstrate the cases that could mislead your account team. Include a strong parent relationship with a weak local deployment, a shared tenant with incomplete attribution, stale outcome evidence, a critical issue hidden by positive activity and a subsidiary with zero aggregate weight. Specify the expected visible status and next action before the demonstration.

Check whether the dashboard preserves local values, exposes the weight calculation and keeps missing evidence distinct from zero. Confirm that reviewers can inspect definitions and source dates, see the reason for a status change and identify the owner of an exception. A polished group overview is insufficient if the team cannot explain the condition of the underlying deployments.

If a vendor describes a health score as predictive, assess that claim separately. Ask what outcome was predicted, over which period and for which population, and what independent validation supports the claim. Use the existing account-scoring evaluation guide for model testing. A descriptive operating index should not be relabelled as a calibrated probability without supporting evidence.

AI can help summarise a review or suggest which missing evidence to collect. Keep those suggestions tied to inspectable records and the defined workflow. Do not allow a fluent summary to invent customer value, close a critical issue or infer expansion readiness from a parent’s name. The responsible team should retain control of consequential interpretation and customer commitments.

Start with one group and a reviewable scorecard

Choose one existing customer group and a small set of important deployments. Complete the scope and evidence fields before selecting weights. Ask the owners to review whether the template describes the actual customer experience, including cases where the system cannot support local attribution. Preserve those limitations instead of making the pilot look complete by filling gaps with assumptions.

Run the scorecard alongside the existing review process and examine disagreements. Investigate whether the definition, source coverage, observation window or interpretation explains the difference. A disagreement is useful feedback about the method; it should not be removed simply to make the dashboard match a preferred narrative. Update the documented rule when evidence supports a change.

Judge the first version by whether the team can identify missing evidence, assign an appropriate owner and explain the next customer action. Track how exceptions are resolved and whether reviewers can reproduce the summary. These are operational checks. Improved retention or expansion would require separate outcome evidence and cannot be attributed to the scorecard merely because it was introduced.

Use company-group context to understand where the customer relationships sit, then maintain the local evidence needed to interpret health. Bring the resulting review into the strategic account plan. The useful result is a team that knows which deployment needs help, which needs evidence and which is ready for a substantive customer discussion.