# How to Set Up Customer Health Score Alerts That Catch Risk Early

> When customer health score alerts should fire, how to calculate score velocity, and how I pick thresholds that catch risk without flooding CSMs.

Source: https://clarivoxx.com/articles/customer-health-score-alerts · Author: Abdessamad Ghanem · Clarivoxx · Customer Success · Updated 2026-02-26

Here is how I set up customer health score alerts that catch risk early. Customer health score alerts are automatic notices that fire when an account's score moves in a way that predicts risk. I use three triggers: a sustained drop (for example 15 or more points in 14 days), a crossing into a worse risk band, and a single critical event such as losing the executive sponsor. Everything else goes into a weekly digest, not a CSM's inbox.

To rebuild past scores and test thresholds, use the free [health score calculator](https://clarivoxx.com/tools/health-score-calculator). This is Part 3 of the Retention Analytics Playbook series. Part 1 built a transparent [health score formula](https://clarivoxx.com/articles/customer-health-score-formula) and Part 2 placed it inside [retention analytics](https://clarivoxx.com/articles/retention-analytics-from-churn-to-action).

## Why do most health score alerts get ignored?

A static threshold ("notify the CSM below 60") gets muted within a month. Three things go wrong:

- **Noise.** Usage dips during holidays or fiscal close.
- **No context.** "Score = 58" does not say what changed or what to do.
- **No owner.** Alerts land in a shared channel and everyone assumes someone else acted.

In travel, partner activity drops every year in the low season. The first alert setup I worked with flagged a large share of our hotel partners as at risk at the same point each year. After two of those waves, nobody read the alerts, including the few that mattered.

## Which alerts should a customer success team set up?

**1. Trend alerts.** These fire when the score falls fast, whatever its level. A drop from 88 to 70 in two weeks often matters more than a year spent at 55.

**2. Band-crossing alerts.** These fire once when an account moves from Healthy to Watch, or from Watch to At Risk. Once, not every day it stays there.

**3. Critical-signal alerts.** Some events need attention regardless of score: a champion leaves, renewal is within 90 days and usage is falling, or an escalation breaches its SLA.

## How do I calculate health score velocity?

```
Velocity (14-day) = Score today − Score 14 days ago

Smoothed velocity = avg(last 7 days) − avg(the 7 days that ended 14 days ago)

Score today        = the account's health score on the day you check
Score 14 days ago  = the stored score from exactly two weeks earlier
avg(last 7 days)   = mean of the last seven daily scores
```

Worked example: an account scored 82 fourteen days ago and 64 today. Velocity is 64 − 82 = **−18 points**. With a trend threshold of −15, this account triggers an alert even though 64 is still above a typical At Risk line of 50.

Smoothed version: the last seven days average 66 and the matching window two weeks earlier averaged 81. Smoothed velocity is 66 − 81 = **−15**. The alert still fires, but one odd day would not trigger it on its own.

| Check | Value | Threshold | Alert? |
|---|---|---|---|
| Raw 14-day velocity | −18 | −15 | Yes |
| Smoothed velocity | −15 | −15 | Yes |
| Current band | 64 (Watch) | Below 50 | No |

You need stored daily scores for this to work. The [health score calculator](https://clarivoxx.com/tools/health-score-calculator) helps you rebuild past scores if you only kept the inputs.

## What threshold should trigger an alert?

Pull 6 to 12 months of daily scores, mark the accounts that churned or downgraded, and test a few thresholds (−10, −15, −20, −25). For each one, count how many alerts would have fired per CSM per week and how many churned accounts they caught early.

In this illustrative comparison, −10 floods the team with about nine alerts per CSM per week and −20 or −25 stay quiet but miss risk. −15 lands inside the budget. Your numbers will differ.

I keep an alert budget of about two to four actionable alerts per CSM per week. Fifteen means the threshold is too sensitive. Google's SRE teams apply the same rule to on-call pages: every page should be actionable, or people stop responding.

## What should an alert message say?

Each alert should answer four questions at a glance:

- **What changed?** Health dropped 18 points in 14 days.
- **Why?** Weekly active users down 40%, two P1 tickets open.
- **So what?** Renewal in 74 days, Enterprise tier.
- **Now what?** Executive check-in within 5 business days.

Name one owner and send alerts to a task queue, not a chat channel.

| Alert type | Example trigger | Owner | Response window |
|---|---|---|---|
| Trend | −15 pts in 14 days | CSM | 5 business days |
| Band crossing | Watch → At Risk | CSM + manager | 3 business days |
| Critical signal | Champion departed | CSM + AE | 48 hours |

## How do I measure whether the alerts work?

```
Precision = alerts that led to a confirmed risk ÷ total alerts
Coverage  = churned accounts that got an alert beforehand ÷ all churned accounts
Time to action = median hours from alert to first CSM activity
```

Example: 18 of 30 alerts led to a confirmed risk, so precision is **60%**. 9 of 11 churned accounts had an alert beforehand, so coverage is **82%**. Coverage is what machine learning people call recall. The trade-off is the same: push one up and the other usually drops.

Low precision means tighten thresholds. Low coverage means the score is missing a signal. I review these on the monthly dashboard:

| Metric | Target | This month | Last month | Change |
|---|---|---|---|---|
| Alert precision | 60%+ | 60% | 52% | +8 pts |
| Coverage of churned accounts | 80%+ | 82% | 75% | +7 pts |
| Alerts per CSM per week | 2–4 | 3.5 | 6.1 | −2.6 |
| Median time to action | <24 h | 19 h | 30 h | −11 h |

## What I've seen in practice

- **The "not useful" button paid for itself.** On one team, a one-click "not useful" button showed us within a few weeks that about a third of our trend alerts came from one data feed that refreshed late. Fixing the feed beat any threshold change.
- **Seasonal partners need seasonal baselines.** For hotel partners, I compared velocity with the same weeks last year, not with the previous two weeks. The low-season wave of false alarms stopped.
- **Band alerts that repeat get muted.** An account sitting at 48 for a month should not alert 30 times. One alert on the crossing, then it lives in the weekly digest.
- **Critical signals beat the score.** The alert that saved the most renewals for me was "champion left", which the score itself picked up weeks later.

This week, pull the last six months of scores, list your churned accounts, and check how many would have triggered a −15 alert in advance. Next, read how to give every alert a [playbook with an owner and a deadline](https://clarivoxx.com/articles/customer-health-score-playbooks-turn-alerts-into-action).

## Frequently asked questions

### When should a customer health score alert fire?

On three kinds of triggers: a fast drop in the score (velocity), a crossing from one risk band into another, and critical events such as a champion leaving or an escalated ticket open past its SLA. Everything else belongs in a weekly digest.

### How do you calculate health score velocity?

Velocity is the score today minus the score 14 days ago. An account that went from 82 to 64 has a velocity of −18. To avoid reacting to daily noise, compare the 7-day average with the 7-day average from two weeks earlier.

### How many alerts should a CSM receive?

Aim for roughly two to four actionable alerts per CSM per week. If a threshold produces far more, it is too sensitive or the score needs refinement.

### How do you measure the quality of health score alerts?

Track precision (alerts that led to a confirmed risk ÷ total alerts), coverage (churned accounts alerted beforehand ÷ all churned accounts) and the median time from alert to first CSM action.

## Sources

- [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/), Google SRE book
- [Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/), Google SRE workbook (precision, recall, detection time)
- [Classification: accuracy, recall, precision](https://developers.google.com/machine-learning/crash-course/classification/accuracy-precision-recall), Google Machine Learning Crash Course