Customer health score alerts work when they fire on meaningful movement, not on every wobble. The practical answer: alert on a sustained drop in the score (for example, 15 or more points over 14 days), on a crossing into a risk band, or on a single critical signal such as a lost executive sponsor. Everything else belongs in a weekly digest, not a CSM's inbox.
In the previous part we built a transparent health score formula. This part turns that score into an early-warning system your team will actually trust.
Why most health score alerts get ignored
Most teams wire an alert to a static threshold: "notify the CSM when health drops below 60." Within a month, CSMs are muting the channel. Three problems cause this:
- Noise from normal variance. Usage dips during holidays, fiscal close, or a customer's own reorganization.
- No context. An alert that says "score = 58" does not say what changed or what to do.
- No ownership. Alerts go to a shared channel where everyone assumes someone else acted.
An alert is only useful if it changes what someone does in the next 48 hours.
The goal is not more visibility. It is fewer, better-timed prompts that each carry a clear next action.
The three alert types that matter
A dependable early-warning design uses three distinct triggers, each with a different purpose.
1. Trend alerts (velocity). These fire when the score falls quickly, regardless of its absolute level. A healthy account dropping from 88 to 70 in two weeks is often a stronger warning than an account that has sat at 55 for a year.
2. Band-crossing alerts (level). These fire when an account moves from one risk band into another, such as Healthy → Watch or Watch → At Risk. They fire once per crossing, not every day the account stays in the band.
3. Critical-signal alerts (events). Some events justify immediate attention regardless of score: a champion leaves, a renewal is within 90 days and usage is falling, or an escalated support ticket stays open past its SLA.
Early-warning triggers at a glance
Velocity (14-day) = Score today − Score 14 days ago. Here: 64 − 82 = −18, so the trend alert fires even though the account is above the At Risk band.
How to calculate score velocity
Velocity is simply the change in health score over a fixed window. A simple version:
Velocity (14-day) = Score today − Score 14 days ago
Imagine an example account with these readings:
- 14 days ago: 82
- Today: 64
- Velocity: 64 − 82 = −18 points
If your trend threshold is −15 points over 14 days, this account triggers an alert even though 64 is still above a typical "At Risk" line of 50.
To smooth out daily noise, compare 7-day rolling averages rather than single-day values:
Smoothed velocity = avg(last 7 days) − avg(7 days, two weeks earlier)
In our example, if the last seven days average 66 and the earlier window averages 81, smoothed velocity is −15. The alert still fires, but a single bad day would not have triggered it on its own.
Setting thresholds without drowning your team
The right threshold depends on your book of business, so calibrate it on history instead of guessing. A practical method:
- Pull 6 to 12 months of historical daily scores.
- Mark the accounts that churned or downgraded.
- Test several velocity thresholds (for example −10, −15, −20) and count, for each, how many alerts would have fired and how many churned accounts they caught in advance.
- Choose the threshold that catches most at-risk accounts while keeping alert volume manageable per CSM.
A useful guardrail: target an alert budget of roughly two to four actionable alerts per CSM per week. If your chosen threshold produces fifteen, it is too sensitive, or your score needs refinement.
Weekly alerts per CSM by velocity threshold
Lower thresholds catch more risk but create noise.
Here is how to read the example comparison above. At −10 points, the illustrative model catches more churned accounts but floods the team. At −20, alert volume is comfortable but too many risks slip through. In this example, −15 is the balanced choice. Your numbers will differ; the process is what transfers.
Designing an alert people act on
Every alert should answer four questions in one 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; ARR tier: Enterprise."
- Now what? "Recommended play: executive check-in within 5 business days."
Name the owner explicitly — usually the assigned CSM, with the CS manager copied for Enterprise accounts. Route alerts to where work happens: your CRM or CS platform task queue, not a general chat channel.
| Alert type | Trigger (example) | 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 |
Closing the loop: measure alert quality
An early-warning system needs its own scorecard. Track three metrics monthly:
- Alert precision = alerts that led to a confirmed risk ÷ total alerts. Example: 18 confirmed of 30 alerts = 60%.
- Coverage = churned accounts that received an alert beforehand ÷ total churned accounts. Example: 9 of 11 = 82%.
- Time to action = median hours between alert and first logged CSM activity.
If precision falls, tighten thresholds or add context filters. If coverage falls, your score is missing a signal. Revisit both each quarter, alongside the score weights from Part 1.
Measuring the early-warning system
Finally, give CSMs a one-click way to mark an alert as "not useful." That feedback is the fastest way to improve precision and to keep the team's trust in the system.
Key takeaways
- Alert on movement, band crossings, and critical events — not on a static score threshold alone.
- Use smoothed 14-day velocity to avoid reacting to daily noise.
- Calibrate thresholds on historical churn data and respect an alert budget per CSM.
- Every alert must state what changed, why, the business impact, and the recommended play.
- Measure precision, coverage, and time to action to keep the system honest.
Coming next in this series
In Part 4, we will turn these alerts into repeatable save plays, with a playbook library matched to each risk signal.
