How to Know Which Customers Are About to Churn Before It's Too Late
Most Customer Success teams find out an account is at risk once it's too late to save it. Here's the road that took me from a static Excel traffic light to a master's degree in predictive modeling, and how tools like Pendo Predict shift the unit of work from "reviewing accounts" to "responding to signals."
What this post is about
Every Customer Success team has lived some version of the same scene: a big account gives notice, and when you look back, the warning signs had been there for months. Nobody was watching them.
This post is about why that keeps happening. Why most teams still find out too late that a customer is leaving, why throwing more data at the problem doesn't fix it (spoiler: it was never a data problem), and why only now, with AI, is it possible to shift from "reviewing accounts" to "responding to signals."
To explain it properly, I first need to tell you how I got here myself. It took me two failed attempts, four years apart, and a master's degree in between.
2015. My first static model, in Excel.
In 2015 I was on the performance marketing team of a used-goods marketplace startup in Brazil. Our job was deciding where to put the money: we spent a lot on Google Ads, on Search.
And the same question kept coming up: of all the ads we had running, which ones were worth pushing further, and which ones should we turn off?
We'd pull all the Google Ads data into a spreadsheet. We'd look at each ad's CTR, its conversion rate, and its impression volume, to figure out whether that CTR was a real signal or just noise from a small sample. And with that we built something that felt incredibly sophisticated at the time: a traffic light. Green for the best performers, red for the worst, yellow for everything in between.
Looking back, it was anything but predictive. It was a snapshot of what had already happened the week before. If an ad broke on a Tuesday, we wouldn't find out until the following Monday, when we rebuilt the spreadsheet. Completely static. Completely reactive.
That traffic light lasted me until I wanted to do things properly. And for that, I had to go back to school.
2019. Predicting clicks to move a company's real revenue.
Four years later I was doing a master's in data, and that's where I actually started learning real predictive models: logistic regression, decision trees, random forests, neural networks. A whole toolbox that didn't exist in my performance-marketer brain.
In one of the courses, the professor set up an in-class competition. He split us into groups and gave us a dataset with real ad data from a real company in the industry. The goal was to predict whether an ad would get a click or not. It sounds small, but for that company it meant real money: better prediction, more revenue.
With my group, the first thing we had to do was clean that dataset: variables with values that made no sense, bizarre categories, a lot of noise to filter out before we could do anything else. Then we built the features we'd feed the model, picked a model, trained it on part of the data, and ran it against the rest to see how well it predicted. That was the loop we repeated for weeks: train, run, check how well it predicted, adjust, train again.
We ended up with a solid model. But between cleaning the data, choosing the features, training and retraining, it took us weeks, across several people, to solve a single problem, with the dataset already built and handed to us in one file.
For years I thought this was just my own story. It isn't.
The two paths almost every company takes to fight churn
The Excel traffic light and the data science team are, almost word for word, the two paths most companies take to keep track of their accounts and try to predict which ones will churn.
The manual, static measurement approach (the spreadsheet) is quick to build and doesn't depend on anyone. But it uses a tiny fraction of the data actually available, and it goes stale on its own: something changes in the product and the spreadsheet is already lying to you. You have to keep fixing it by hand, constantly.
The data science approach (what I did in my master's, what an internal team does today) is genuinely powerful. But it takes nine months to build on average, and 85% of these projects never make it to production.
One is fast and weak. The other is strong and painfully slow. Neither one works on a Monday morning.
So why do both fail? For the same reason, and it's not the one most people think.
The problem isn't a lack of data
Everyone wants to be more data-driven. And data isn't scarce. What's scarce is clean, centralized data that can actually be turned into something usable. And that's rare, for four reasons:
1. Data lives in silos across tools and teams: the product on one side, the CRM on another, the ticketing system on another. Every tool with its own version of the truth.
2. Prep and cleaning eat up 80% of the effort, before you get a single insight. With the master's dataset, which had already been handed to us built into one file, most of those weeks didn't go into the model: they went into understanding and cleaning the data. With data scattered across five different systems, it's worse.
3. Every change depends on a data scientist. You want to add a variable, change a rule, and you're in a priority queue you don't control.
4. When something finally ships, the result is so complex, and lives so far from the tools the team actually works in, that nobody can act on it.
It's not that the data is missing. It's the path from data to action that's broken. And when that path is broken, the cost isn't technical: it's that key business questions simply can't be answered.
Which accounts are at risk, today? How does each rep prioritize their book of business on a Monday? Who should get an upsell, and why that one and not another? Where do you need to invest more in support? All four can be answered with product usage data most teams already have. The problem is that, without the right signals, none of them get answered.
And this isn't an efficiency problem, it's a money problem: in the US, customer churn is estimated to cost the industry $136 billion a year. The underlying point holds in any market: acquiring a new customer will always cost more than retaining and expanding one you already have. Everyone talks about net retention, but to get there you first need to protect gross retention: not losing what you already have.
The honest question
Think about the last account that tried to cancel on you this quarter. A real one, with a name attached. Did you see it coming? Or did you just react?
For most teams, by the time risk finally shows up on the dashboard, it's not a save conversation anymore: it's a renewal conversation. And those are two very different conversations.
Anyone who's worked in Customer Success knows the feeling: opening your inbox on a random Tuesday and finding a cancellation notice for a big account you never saw coming. And the worst part isn't losing the account: it's realizing, looking back, that the signals were there. They'd been there for months. Nobody was watching them.
That's what everything below is about: not reacting better, but having margin. Finding out with enough lead time to actually do something.
A static health score is an autopsy
It tells you what happened, weeks late, based on rules someone wrote months ago and nobody has touched since. It's a look backward: useful for explaining, not for changing the outcome.
What you need is the opposite: a stethoscope. The thing that listens continuously, all the time, and alerts you the moment something changes.
The difference between the two is concrete, not philosophical. Yesterday's health score runs on hand-tuned rules written months ago; it updates once a week or once a quarter; it applies the same logic to every account alike; and it tells you what happened. The model that's coming learns patterns from your own churn history (not from rules someone guessed at); it updates every day; it adjusts account by account and explains the reason in language your team understands; and it tells you what's about to happen.
That's the leap: from explaining the past to anticipating what's next. And it's not a tool swap: it's a change in what counts as a unit of work for the team.
From reactive retention to proactive revenue protection
In the old model, the unit of work is the account review: manual, weekly, exhaustive, and late. The CSM opens up Monday morning and has to read through eighty dashboards to catch something that may have happened ten days ago, and does it the same way for all eighty accounts even though seventy-five of them are fine.
In the new model, the unit of work is the signal: one specific thing that changed, caught the moment it happens, and routed straight to the person who can act on it. The CSM stops being a dashboard reviewer and becomes someone who responds to signals. It's a different role, and a considerably more interesting one.
What does that look like in practice on a Monday morning? Three principles:
1. Continuous monitoring: the system checks every account every day, so people don't have to. It's not the weekly check-in where you find out something from the customer directly, which is usually already too late to act on.
2. Contextual prioritization: the question isn't "which accounts are at risk" (that returns a list of thirty accounts and no idea where to start), but "which account do I need to call first, today, and why."
3. Action inside the workflow: the next step shows up where the work already happens (CRM, Slack, inbox), not in another tab you have to remember to open. And not everything needs a human in the loop: some things can go straight to the customer, freeing up the CSM's time for what actually requires human judgment.
Think about what we're asking a human to do here: watch every account, every day, correlating hundreds of signals at once, and explain the reasoning behind each one. No human team can do that. It's not a matter of effort: the math doesn't work.
A model can. Finding patterns across hundreds of variables (patterns a human wouldn't spot at a glance) is exactly the kind of task where AI massively outperforms us. And it doesn't just return a score: it can surface the drivers, what's pushing that number, so the CSM knows where to step in. That's where AI stops being a buzzword and becomes the piece that makes this operating model possible.
Enter Pendo Predict
Pendo Predict is an AI engine that ingests signals from three sources: product usage (from Pendo or whatever source you already have), CRM data (calls, activities, renewal dates), and third-party signals (emails, support interactions). With all of that, it learns from your own real churn, upsell, and cross-sell history (not from rules someone guessed at a year ago) and scores every account daily.
Three numbers matter here:
- More than 150 data points per account. For comparison: a hand-built health score typically runs on five or six variables, whichever ones someone thought mattered.
- When it flags an account as critical, that account is 3x more likely to churn than the rest of the book. It's no longer a generic risk list: it's a real order of who to call first.
- It updates every day, not once a quarter.
In more mature implementations, the signal volume climbs well past the typical 150: in Emburse's case, which I'll get to below, it reached over 700.
Think of it as having an AI data scientist and an AI data analyst working together around the clock, automating exactly the part that cost me weeks back in 2019: cleaning the data, finding the patterns, keeping the model current as things change. That frees up the team's time for the part that actually needs human judgment: what to do with the prediction, what the playbook is, what to ask the team to do. That's what actually moves the number. The prediction alone doesn't save any account.
Under the hood, the flow is: connect the sources (Pendo, CRM, BI), let the AI clean, normalize, and optimize all of it (the box that eats the 80% of the effort I mentioned earlier), build the predictive model through guided, no-code steps, and push the prediction straight into the workflow: Slack notifications, embedded guides in the CRM, automated in-app or email journeys. The rep doesn't have to go looking for the data: the data comes to them, with the recommended next action attached.
The Emburse case
Emburse, a travel and expense management software company (500 to 1,000 employees), had its customer health data spread across four disconnected systems. Its CSMs had to manually stitch those signals together, with no unified view. By the time churn risk surfaced, it was already too late to act: the team lived in firefighting mode, and leadership was flying blind on renewals.
As Kelly Causey, VP of Customer Success at Emburse, put it: "I was spending my days explaining surprises to leadership instead of preventing them."
Pendo Predict unified more than 700 signals into a single predictive model and started pushing risk scores directly into Salesforce, giving the team 90 days of forward visibility on at-risk accounts, without adding a single headcount. The result: 3.1x faster time-to-action on at-risk accounts, and cost to serve dropped to 2% (down from 3-4% of ARR).
Three questions to bring to your next meeting
These aren't meant to be answered here. They're for your next team meeting, or your next conversation with leadership:
1. How does a CSM on your team actually find out an account is in trouble? Not how it should work: how it works today. And more importantly, how many days of lead time does that give them to do something about it?
2. If you doubled every CSM's book of business tomorrow (which could easily happen this year), what part of their week breaks first?
3. What would your team do if every Monday morning, instead of a dashboard, they got a prioritized list of accounts, with the reason attached?
That's your real diagnosis of how far you are from the model described here.
The leap doesn't have to take years
It took me years to go from the Excel traffic light to understanding this could be done differently. You don't have to take that long: today, with tools like Pendo Predict, that leap happens in weeks, not years, and without needing to build an internal data science team.
At Bildung we implement Pendo (and the rest of the growth and retention stack) for Customer Success and Product teams across Latin America. If you recognized yourself in any of the three questions above, email me at guido@bildungdata.com and let's work through it together.
