How to predict churn in B2B SaaS

Most B2B SaaS teams have a customer health score. Few would say it actually prevents churn. The pattern is familiar: the score turns yellow, the team plans an intervention, the customer churns three weeks later. Everyone agrees, in retrospect, that the signs were there earlier. But the health score didn't show them.

That's not a bug in the implementation. That's the math of how most health scores are built.

Health scores are lagging indicators by design — they aggregate things that have already happened. By the time they go yellow, the decay is well underway. The customers you save are the lucky ones. The ones whose decay was slow enough that "yellow" still left a window to act.

The fix isn't a better health score. It's a different category of signal entirely: leading churn risk scores that surface risk before the lagging indicators register it.

This post breaks down the difference, then gives five tactical practices you can apply this week — whether you build the leading indicator yourself or use a tool that does it for you.

Health score vs churn risk score: the categorical difference

Most customer health scores are weighted formulas combining a handful of inputs:

• Last login date
• Number of seats / active users
• Monthly revenue or contract value
• NPS or CSAT score
• Open support ticket count

The formula outputs a number, the number maps to a color, and the color tells the CSM whether to act.

The problem is what these inputs share: they all describe state, not motion. "Last login was 14 days ago" tells you where the customer is right now. It doesn't tell you they were logging in 5x/week last month and dropped to twice a week three weeks ago. The score went yellow when the absolute number crossed a threshold — which is weeks after the trend that led to it.

A leading churn risk score works differently. It looks at change — the second derivative, the velocity, the deviation from the customer's own historical baseline:

• Not "how many sessions" but "how much did session frequency change relative to last month"
• Not "is the power user active" but "how does this user's behavior compare to their own pattern 60 days ago"
• Not "revenue per account" but "is the rate of feature adoption tracking with peers, or flat-lining"

The point isn't that absolute values don't matter — they do. The point is that change leads state. By the time the absolute value crosses a yellow threshold, the change that caused it happened weeks earlier. A model that watches change catches risk earlier than one that watches state.

Classic health scores aren't wrong. They're just answering a different question: "is this customer healthy right now?" Leading churn risk asks: "is this customer's trajectory pointing toward churn?" Two questions. Two answers. Different timing.

Five tactical practices that work

Whether you build this yourself or use a tool, these are the practices that consistently move the needle on churn detection:

1. Track velocity, not levels

The single highest-leverage change you can make: stop tracking "did the customer log in this week" and start tracking "is this customer's login frequency declining versus their own historical baseline."

Concretely, for any usage metric you care about (logins, core feature events, API calls, seats), compute three things weekly:

• Trailing 30-day average — the customer's current state
• Trailing 60-day average — the customer's recent baseline
• Velocity — the percentage change between the two

Velocity below -20% is a yellow signal. Below -40% is red. The absolute level may still look fine — but the trajectory is pointed at churn. By the time the level drops to "looks bad," the velocity will have been showing the warning for weeks.

2. Combine signals; never trust one alone

Any single signal is noise. A customer who didn't log in last week might be on vacation. A failed payment might be a card replacement. A drop in support tickets might mean the product is getting better.

The signal is in the combinations. A customer who's logging in less and stopped using the core feature and hasn't responded to the last two product emails has a story you can read. None of those data points alone would justify intervention. Together, they're an obvious flag.

The practical rule: any single signal should never trigger an alert. Require at least two correlated signals before flagging an account — ideally three. False positives kill CSM trust in the system faster than false negatives kill retention.

3. Compare each customer to their own baseline, not a global average

"This customer logs in 4 times a week" tells you nothing without context. If their baseline is 20 times a week, they're at risk. If their baseline is twice a month, they're more engaged than usual.

The mistake most health scores make is using global thresholds (e.g., "less than 5 logins per week = yellow"). That punishes high-engagement customers for normalizing to average behavior — which is itself a churn signal. And it gives free passes to low-engagement customers whose trajectory is fine for them.

Track each customer's own pattern over their tenure. Flag deviations from their own baseline, not deviations from a population average. Customers churn relative to themselves.

4. Weight risk by revenue when prioritizing action

Two customers, both 80% churn risk. One is paying $50/month. The other is paying $5,000/month. Your CSM doesn't have time for both. The one that gets the call shouldn't be a coin flip.

The right priority signal isn't risk score — it's risk score × MRR. The $5K customer has 100× the financial impact of the $50 customer at the same risk level. Sort the at-risk queue by that product, not by risk alone.

This sounds obvious. Most teams don't do it. They sort by risk, work top-to-bottom, and waste hours on small accounts while six-figure customers churn untouched. If a CSM has bandwidth for ten interventions a week, those ten should always be the highest combined impact — risk and revenue together.

5. Match the intervention to the specific reason — not the score

"This customer is at risk" is not a playbook. "This customer is at risk because their power user stopped logging in" is a playbook. Different reasons demand different responses:

• Usage decline — re-onboarding offer or training session, not a discount
• Power user disengagement — outreach to the new user, not the original buyer
• Failed payment — billing fix or grace period, not a Zoom call
• Champion change — reintroduction email and value re-pitch, not a renewal pre-call
• Support friction — route to senior support, not to CS

The risk score tells you who. The risk reasons tell you what to do. Without the reasons, every intervention defaults to a generic "checking in" email — which converts at terrible rates and trains your customers to ignore your CSMs.

Anti-patterns: what most teams do that doesn't work

Three patterns we see consistently — and they're worth flagging because the people running them usually think they're doing churn prediction:

"Last login = 30 days" as the churn flag. This is the single most common health score implementation. It catches obvious cases too late and misses the silent decline cases entirely. A customer who quietly drops from daily to weekly to monthly logins is showing the trajectory three months before "30 days" triggers.

NPS as the leading indicator. NPS is a survey response. It arrives every 6 months at best, after the customer has already formed an opinion you could have detected in their behavior weeks earlier. NPS is useful for product feedback. It's a terrible leading indicator for individual-account churn risk.

"Has open ticket = at risk." Open tickets correlate with engagement, not churn. Customers who file support tickets are using the product. The customers who churn silently usually file fewer tickets in the 60 days before they leave — they've stopped trying to make it work. A ticket-volume drop is the leading signal. Volume itself is noise.

Where Revenue Plumber fits

Revenue Plumber is built around exactly this distinction: not a better health score, but a leading churn risk score that catches risk earlier than lagging health scores can.

The agent's risk score combines velocity-based signals across product usage, billing events, support patterns, and email engagement — weighted per customer against their own baseline, prioritized by risk × MRR, with the specific reasons attached so the right intervention is obvious.

Concretely:

• Risk score 0–100 updated daily, with a velocity-based component that catches change earlier than a static health threshold
• Per-customer reasons attached to each score — not just "at risk" but "usage velocity dropped 38% over the last 30 days plus failed payment last week"
• Action queue sorted by risk × MRR, so CSM time goes to highest-impact interventions first
• For the long tail of SMB accounts no CSM has time for, the agent drafts personalized retention emails and proposes actions in Stripe / HubSpot — with your approval before anything ships

None of this is rocket science. The math is straightforward. The hard part is the data plumbing: joining Stripe, HubSpot, product events, support, and email signals, then building the velocity calculations and the action workflows. That's the part that takes months in-house. Plug in Stripe, plus optionally HubSpot, Gmail, and Slack — the agent runs the rest.

Bottom line

Customer health scores are useful. They give you a snapshot of where each account is right now. But they're built from inputs that lag the trajectory you actually want to detect — which is why churn keeps surprising teams that have a health score in place.

Leading churn risk scores look at change instead of state. They catch the trajectory weeks before the snapshot turns yellow. Whether you build that yourself with the five practices in this post, or use a tool that does it for you, the categorical shift is the same: stop measuring where customers are. Start measuring where they're going.