# Customer Health Score Model: [Product or customer segment]

> A customer health score model that turns a few observable signals
> (product usage, adoption breadth, support experience, relationship
> and commercial standing) into one weighted score per account, with
> bands and the playbook each band triggers. Based on common customer
> success practice; no formal standard governs health scoring. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Fill sections 1 and 2 first: what the score is for, and which signals
  you can actually collect every week without manual effort. A model
  built on data you cannot refresh decays within a quarter.
- Keep it to four to six inputs. More inputs make the score harder to
  explain to the account team and rarely improve prediction.
- Validate the model against past renewals (section 6) before anyone
  uses it to forecast. Re-weight from evidence, not from opinion.
- Common pitfall: treating the score as the truth. It is a prompt for a
  conversation; the account manager's judgement and a written reason
  can override it (section 5.3).
- Related: success plan (`customer-success/success-plan`), renewal and
  churn risk plan (`customer-success/renewal-churn-risk-plan`),
  quarterly business review (`customer-success/quarterly-business-review`).
-->

## Document control

<!-- Guidance: The model is a controlled document because forecasts and team targets depend on it. Change the version whenever an input, weight or threshold changes. -->

| Field | Value |
|---|---|
| Document ID | [CS-HSM-001] |
| Version | [1.0] |
| Status | [Draft / Approved / Retired] |
| Owner | [@head-of-customer-success] |
| Reviewers | [@revenue-operations], [@product-analytics], [@support-lead] |
| Segment covered | [For example, mid-market accounts on annual contracts] |
| Data refresh | [Weekly, every Monday 06:00 UTC] |
| Last updated | YYYY-MM-DD |
| Next validation | YYYY-MM-DD |
| Classification | [Internal] |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-10-30 | Head of customer success | First model, five inputs, three bands |

## 1. Purpose and scope

<!-- Guidance: State the decisions the score supports. A score that tries to predict churn, expansion and advocacy at once usually predicts none of them well. -->

The health score answers one question: **which accounts need a
proactive conversation this week, and what kind?** It supports:

- prioritising the customer success manager (CSM) workload;
- early warning ahead of renewal (feeds the renewal risk review);
- a shared, explainable view of account status in [CRM name].

Out of scope: compensation, pricing decisions and any automated action
that affects the customer without a human review.

| Item | Value |
|---|---|
| Accounts in scope | [All accounts with an active subscription in segment X] |
| Excluded | [Accounts in their first 30 days; trials; partners] |
| Score range | 0 to 100 |
| Bands | Green, Amber, Red (section 4) |

## 2. Inputs

<!-- Guidance: Each input needs a definition, a data source, a refresh rate and a scoring rule that maps raw values to 0 to 100. Prefer leading signals (behaviour now) over lagging ones (a cancellation notice). -->

| ID | Input | Definition | Source | Refresh | Scoring rule (0 to 100) |
|---|---|---|---|---|---|
| HS-IN-01 *(Example)* | Product usage | Weekly active users divided by licensed seats, 4-week average | Product analytics | Weekly | 0% maps to 0, 80% or more maps to 100, linear between |
| HS-IN-02 *(Example)* | Adoption breadth | Share of the [5] core features used at least once in 30 days | Product analytics | Weekly | 20 points per core feature used |
| HS-IN-03 *(Example)* | Support experience | Open high-severity tickets and satisfaction with handling | Support desk | Daily | Start at 100, minus 25 per open P1 or P2 ticket, minus 10 per low CSAT response in 90 days, floor 0 |
| HS-IN-04 *(Example)* | Relationship | Executive sponsor named and met in last 90 days, champion active | CRM, CSM entry | Monthly | Sponsor met 50, champion active 50 |
| HS-IN-05 *(Example)* | Commercial | Invoices paid on time, no open dispute, contract not in downgrade | Billing, CRM | Weekly | 100 if all true, minus 40 per failed condition, floor 0 |
| HS-IN-[NN] | [Input] | [Definition] | [Source] | [Rate] | [Rule] |

Data quality rules:

- Missing data is shown as missing, never silently scored as 0 or 100.
  If more than one input is missing, the account shows "Insufficient
  data" instead of a band.
- Inputs entered by hand (HS-IN-04) carry the date of the last update;
  an entry older than 90 days counts as missing.

## 3. Weights and calculation

<!-- Guidance: Start with simple weights that sum to 100 and that the team agrees with, then adjust them in section 6 from evidence. Write the formula so that anyone can recompute a score by hand. -->

Health score = sum of (input score x weight) / 100.

| Input | Weight *(Example)* |
|---|---|
| HS-IN-01 Product usage | 35 |
| HS-IN-02 Adoption breadth | 20 |
| HS-IN-03 Support experience | 15 |
| HS-IN-04 Relationship | 15 |
| HS-IN-05 Commercial | 15 |
| **Total** | **100** |

### 3.1 Worked example

*Example:* fictional account Pellingham Tooling.

| Input | Score | Weight | Contribution |
|---|---|---|---|
| Product usage | 62 | 35 | 21.70 |
| Adoption breadth | 40 | 20 | 8.00 |
| Support experience | 80 | 15 | 12.00 |
| Relationship | 50 | 15 | 7.50 |
| Commercial | 100 | 15 | 15.00 |
| **Health score** | | | **64.20 (Amber)** |

The two weakest contributions, adoption breadth and relationship, tell
the CSM where to start: a feature adoption session and a meeting with
the sponsor.

## 4. Bands and thresholds

<!-- Guidance: Three bands are enough for most teams. Set thresholds so that the Red band is small enough to act on every week. Re-check them after validation. -->

| Band | Score *(Example)* | Meaning | Review cadence |
|---|---|---|---|
| Green | 75 to 100 | Healthy; look for expansion and advocacy | Monthly |
| Amber | 50 to 74.9 | At risk of drifting; act on the weakest input | Every two weeks |
| Red | 0 to 49.9 | Likely to churn or downgrade without action | Weekly, in the risk review |

A drop of [15] points or more in 30 days triggers a review whatever the
band, because the trend often matters more than the level.

```mermaid
flowchart LR
  A["Weekly data refresh"] --> B["Score each input 0 to 100"]
  B --> C["Weighted sum"]
  C --> D{"Band"}
  D -->|"75 or more"| G["Green playbook"]
  D -->|"50 to 74.9"| M["Amber playbook"]
  D -->|"below 50"| R["Red playbook"]
  C --> T{"Drop of 15 or more in 30 days?"}
  T -->|"Yes"| M
```

## 5. Playbooks per band

<!-- Guidance: Each band needs a named owner, a first action within a set time and an exit condition. Without playbooks the score is a dashboard nobody acts on. -->

### 5.1 Actions

| ID | Band or trigger | First action and timing | Owner | Exit condition |
|---|---|---|---|---|
| PB-G-01 *(Example)* | Green | Ask for a reference or case study; review expansion fit | CSM | Next quarterly review |
| PB-A-01 *(Example)* | Amber, low usage | Usage review call within 10 working days; re-train key users | CSM | Usage input at 70 or more for 4 weeks |
| PB-A-02 *(Example)* | Amber, low relationship | Sponsor meeting within 30 days; refresh the success plan | CSM, account executive | Sponsor met, plan signed off |
| PB-R-01 *(Example)* | Red | Open a renewal risk plan within 5 working days; manager review | CSM, CS manager | Score at 50 or more for 4 weeks, or renewal decided |
| PB-T-01 *(Example)* | Drop of 15 or more points | Find the cause within 5 working days and log it | CSM | Cause logged and action agreed |

### 5.2 Communication

Never show the customer their band label. Talk about the evidence
(usage, open tickets, outcomes) and the plan, not the score.

### 5.3 Overrides

A CSM may override the band for up to [60] days with a written reason
(for example, a known seasonal dip or a merger in progress). Overrides
are listed in the monthly review so that the model can learn from them.

| Account | Model band | Override band | Reason | Set by | Expires |
|---|---|---|---|---|---|
| *Example:* Pellingham Tooling | Amber | Amber (no change) | n/a | n/a | n/a |
| [Account] | [Band] | [Band] | [Reason] | [@csm] | YYYY-MM-DD |

## 6. Validation and recalibration

<!-- Guidance: Test the model on accounts whose renewal outcome you already know. If churn does not rise from Green to Red, the inputs or weights are wrong. Record the period, the sample and the result. -->

Back-test the score as it stood 90 days before each renewal date:

| Band 90 days before renewal | Accounts | Churned or downgraded | Rate |
|---|---|---|---|
| Green *(Example)* | 70 | 3 | 4.3% |
| Amber *(Example)* | 35 | 6 | 17.1% |
| Red *(Example)* | 15 | 7 | 46.7% |
| **Total** | **120** | **16** | **13.3%** |

*Example* reading: churn rises clearly by band, so the model separates
risk. Review every [6] months:

- Does each input still move with outcomes on its own? Drop inputs
  that add nothing.
- Are Red accounts a workable number for the team each week?
- How many overrides were right, and what did they know that the model
  did not?
- Has the product or segment changed (new features, new pricing) so
  that a scoring rule is out of date?

## 7. Governance and data protection

<!-- Guidance: Health data is about business customers but often includes named users' activity. Keep it proportionate and explainable. -->

| Topic | Rule |
|---|---|
| Model owner | [@head-of-customer-success] approves changes to inputs, weights and bands |
| Change log | Every change gets a new version in the revision history |
| Personal data | Use aggregated account-level usage; avoid ranking individual users. Check your privacy notice and data processing terms cover this use |
| Automated decisions | No price, access or contract change is triggered by the score alone |
| Access | CSMs see their accounts; managers see the portfolio |

## 8. Glossary

<!-- Guidance: Define terms the account team uses differently, especially "active user" and "churn". -->

| Term | Meaning in this model |
|---|---|
| Active user | A licensed user who performed [a core action] in the week |
| Churn | Contract not renewed, or renewed at less than [90%] of prior value |
| Leading signal | Behaviour that changes before the renewal outcome |
| Override | A documented, time-limited change to the band by a CSM |

## Standard and licence note

Based on common customer success and revenue operations practice for
account health scoring. No standard defines a health score; the inputs,
weights and thresholds here are illustrative and must be validated on
your own renewal history. All text is original. Template licence: MIT.