Customer health score, no CS team.

How to calculate a customer health score

A customer health score is a weighted average. You turn each signal into a sub-score from 0 to 100, multiply each one by its weight, and add them up:

Health score = (weight 1 × signal 1) + (weight 2 × signal 2) + … with the weights adding up to 100%.

Five steps get you there:

1. Pick signals you can refresh without typing anything in. If a signal needs someone to update it by hand, it goes stale, and a stale input is worse than none.
2. Turn each signal into a 0–100 sub-score with simple bands. For example, for payments: no failed payment in the last 90 days scores 100, a failure that was later paid scores 60, and an open failed invoice scores 0.
3. Weight and add. Start simple and let your own data correct you, as shown below.
4. Set bands. For example: 75 and above is healthy, 50 to 74 needs watching, and below 50 is at risk.
5. Test it against customers who left. Score last year's leavers as they looked a month before they canceled. If most of them didn't land in your lowest band, the score isn't measuring what matters yet. Then check how many customers who stayed landed there too.

Note the direction. In a health score, higher means healthier. That is the opposite of a churn risk score, where higher means more likely to leave. Pick one direction and keep it everywhere, or your team will misread the list.

Which metrics to use

Use what you already have and can refresh automatically. Many health score templates assume a CS team that logs calls, rates sentiment and runs surveys. Without that team, those inputs go stale. Your two reliable sources are Stripe billing and product usage.

From Stripe billing:

• Payment health. Failed payments, open past-due invoices, hard declines, and a card that expires before the next charge.
• Plan direction. Seats or plan going up, staying flat or going down over recent months. Contraction often comes before a cancel.
• Discounts ending. A repeating discount with an end date coming up means a price rise the customer will notice.
• Tenure. Customers in their first billing cycles who never got set up carry more risk than settled ones.
• Cancel status. A subscription with cancel_at_period_end set to true isn't a sub-score. It overrides everything else, as the next section explains.

From product usage:

• Active days, compared with the account's own baseline.
• Days since the last core action, the one thing they pay you for.
• Features in regular use, and whether that number is shrinking.

Leave out what you can't keep fresh or read clearly. Surveys you run now and then are out of date most of the year. Support tickets cut both ways, because engaged customers file tickets too. And login counts alone reward habit, not value.

These are the same signals behind a churn risk list, so the work carries over whichever one you build.

How to weight them

Start with weights that favor usage and payments, then let your own leavers correct them.

Example: starting weights for a seat-priced product, with one customer scored.

This customer pays on time and has been around a while, but usage has slid. With the example bands above, 55 means "needs watching", and the reason is usage, not payment. That reason is what you'd write to them about.

Four rules make the weights work:

• Let decisive signals override. A scheduled cancel, or an invoice still open after Stripe's retries end, should drop a customer to the bottom band whatever else is true. An average hides them: a customer with great usage who scheduled a cancel isn't 80% healthy.
• Don't count the same thing twice. Active days and the core action tend to move together. If both are in the score, keep their combined weight in check.
• Match the weights to the pricing model. On usage-billed plans, usage is the bill, so weight usage higher. On seat plans, seat cuts deserve more weight.
• Re-check against who actually left. Each quarter, compare how often each signal showed up among leavers and among customers who stayed. Move weight toward the signals that separate the two.

Why a risk score ranked by money works better without a CS team

A health score was designed for a CS team that works through a book of accounts every week. It answers "how is everyone doing?" Without that team, you need a different answer: who should I act on today, and what should I do? A churn risk score ranked by money at risk answers that more directly, for three reasons.

• It points at leaving. A risk score rates how likely a customer is to leave, so decisive signals like a scheduled cancel rise to the top instead of being averaged away.
• It is ranked by money. Sorting by MRR × risk score puts, for example, a $3K/mo account that is slipping ahead of a $40/mo account that is nearly gone. Your few hours a week go where the money is.
• It comes with reasons and a move. A number alone doesn't tell you what to say. Each flagged customer needs up to three plain reasons with dates, and the move that fits: a check-in for a usage drop, a card-update note when Stripe's retries end, a save email when a cancel is scheduled.

That is how North Metric works. Every paying Stripe customer gets a 0–100 risk score, a level (Likely, Possible or Safe) and up to three reasons, ranked by MRR × risk score. Each one at risk gets a drafted move you approve, or rules you set once. If you're weighing tools, see what to look for in churn prediction software.

Whichever you build, the score is only the start. The guide on how to reduce SaaS churn covers the moves that work and how to tell whether they did.