A customer health score combines usage, support tickets, engagement and sentiment into one number that predicts renewal or churn risk before it happens. Customer success teams use it to decide which accounts get attention this week. In most models usage carries the most weight, and it is also the input nobody on the success team can check: the score is only as trustworthy as the events feeding it.

How it works

A typical score weights a few signals: active users against seats bought, use of the features that predict renewal, support ticket volume and tone, survey answers, and contact with an executive sponsor. Each signal maps to a band, the bands add up to a score, and the score maps to red, amber or green. The colour drives action, so a wrong colour is a wrong action. A healthy account gets a save call, or a failing one gets left alone.

AmirBahador Bahadori, interviewed in The Question, keeps database state, observability and behavioural analytics apart because each deserves a different amount of trust. A health score often blends database state, such as seats bought, with behavioural analytics without saying so, which is why it is hard to tell which part moved.

What it assumes your events already do

Event	What the framework uses it for	What it reports when the event breaks
Return visit `session_started`	Active users against seats bought.	A change to session tracking moves every account's activity band on the same day.
Core value action `report_viewed`	Adoption of the features that predict renewal.	If the event fires from an embed or an automated job, accounts look healthy while nobody uses the product.
User-to-account join `account_id on every event`	Rolls user activity up to the account being scored.	Users who lose the account property disappear, and the account drifts toward red with no change in behaviour.

Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.

The green account that churned

Illustrative example. The company and the figures are invented to show the mechanism.

An account sits green for six months. Its usage score comes from dashboard_viewed, which the account's users trigger every morning through a dashboard embedded in another tool.

They migrate that tool and the embed disappears. The event stops, and the score finally turns red, but real usage had been falling for a quarter underneath the embed traffic. The renewal call is the first time anyone hears about it.

Checks before you trust it

List every usage signal in the score and the event behind it.
Alert when an account's usage signal drops to zero overnight; real disengagement is gradual and tracking breaks are sudden.
Test the score against past renewals and churns before trusting its colours.
Show the components next to the score, so a reviewer can see which part moved.

Heard in The Question

Interviews in The Question that bear on this framework:

AmirBahador Bahadori: product data is three layers, not one. Product data is three separate layers that answer different questions, and a dashboard pattern is a hypothesis until a person confirms it.
Arash Farhani: the first data he trusts is a testimonial. Before a few hundred users, intuition and testimonials lead, and a number earns authority only once direct contact with clients confirms it.
Marc Olivier Meunier: why Astra runs without a dashboard. Trust lives in an evidence chain a person can check, so at ten months the team keeps its own analytics near zero and talks to customers instead.

Check the events under it

Before Customer health score goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.