Churn prediction: knowing who is leaving before they leave

Customer churn prediction means estimating, for every account in your book, the probability that they will stop buying from you over the next few months. It is not fortune telling: it is looking at what the customers who already left did before they left, and finding that same pattern in the ones who are still here. The hard part is not the model. The hard part is getting someone to take the list of at-risk customers and do something with it before the loss is already a fact.

This guide is for management, marketing and sales teams at companies that already have enough history — a CRM with years of activity, an ERP with invoicing, a platform with subscriptions — and suspect they are losing customers they could have kept. You will find which signals genuinely anticipate attrition, how to choose the prediction window, what data you need, how to tell whether the model is any good and, above all, what happens the following Monday with the list.

What is churn prediction, and how is it different from measuring churn?

Measuring churn is counting backwards: how many customers left last quarter, how much revenue went with them. It is a KPI, and you should have it. But by definition it arrives late: by the time it shows up in the report, the customer has already cancelled, already moved the contract elsewhere, or has been silent for eight months.

Predicting churn is looking forward: given what I know about this account today, what is the probability that in the next 90 days they stop being a customer? The output is not an aggregate number, it is a named list, ranked, with a person's name and a percentage next to it.

That difference changes who uses the data. Measured churn is reviewed by management once a month. Churn prediction is reviewed by a sales rep, an account manager or someone in customer service every week — and acted on.

Before you build anything there is a prior question most people skip: how do you define that a customer has left? In a subscription business it is easy: there is a cancellation with a date. In a transactional business — distribution, services, B2B retail — the "churn" event does not exist. There, you have to invent the definition, and that definition conditions everything else.

One rule that works: look at each customer's historical purchase frequency and define attrition as "no orders for a period that 90% of their previous gaps never exceeded". If a customer ordered every three weeks and has been silent for four months, they are gone, even if nobody has cancelled anything in any system.

If you cannot express in a formula which customer counts as lost, you cannot predict churn. The first thing is not the model: it is the definition.

Which signals actually predict customer attrition?

Some signals go into every model and contribute little; others nobody collects and they are the ones that matter. The difference is whether they reflect recent behaviour or merely describe the account.

Signals that tend to work, roughly in order of what we have seen contribute most:

• Change of pace. Not volume, but the derivative. A customer who ordered €10,000 a month and drops to €6,000 two months running tells you more than one who always ordered €6,000.
• Widening gaps between orders. The cheapest signal to compute and one of the strongest in transactional businesses.
• Narrowing of the product range. A customer who bought five product families and is down to one is trying another supplier for the rest.
• Support tickets and how they were closed. Not the number of tickets: how long you took to close them and whether the issue came back. Two tickets resolved in a day matter less than one open for three weeks.
• Usage decline in subscription or software products: active users, sessions, features used. A customer who pays and never logs in is a customer who leaves at the next renewal.
• The end of human contact. Months with no visit, no call, no replies to emails. It is both a signal and a cause.
• A change of contact person on the customer side. When the decision-maker changes, inherited suppliers get reviewed.

Signals that tend to contribute less than you would expect: industry, company size, region, tenure on its own. They describe rather than anticipate. They are useful for shaping the response — you do not treat a €200,000 account like a €3,000 one — but they rarely raise the alarm. If that part interests you, we cover it in the customer segmentation guide.

And one important warning: beware of signals that are a consequence of leaving rather than a cause. If you feed in "stopped receiving the newsletter" and it turns out you unsubscribe people when the contract ends, your model will show spectacular accuracy and be useless. That is the classic leakage of future information, and it happens more often than people admit.

Which prediction window should you choose?

The window is the horizon: are you predicting they leave within 30, 90 or 180 days? The right answer is not technical, it is operational: the window has to match, or slightly exceed, the time it takes you to do something about it.

If your team needs three weeks to arrange a sales visit, a 30-day prediction arrives tight. If you sell on annual contracts negotiated two months before renewal, what you need is a signal at 120 days.

| Type of business | Sensible window | Why | |---|---|---| | Monthly subscription (software, services) | 30-60 days | Renewal is frequent; the action is an email or a quick call | | Distribution / B2B consumables | 60-90 days | There is room for a visit and a proposal before the next order | | Annual contract with negotiated renewal | 120-180 days | The decision is cooked months before the signature | | Retail / ecommerce with repeat purchase | 30-45 days | The cycle is short and the action is automatic (campaign, voucher) |

Too short a window gives you a list of customers you can no longer reach. Too long gives you an enormous list in which hardly anybody actually leaves, and the team stops paying attention within three weeks. If in doubt, start with the window closest to the typical gap between orders in your book.

What data do you need, and in what shape?

The honest minimum for this to make sense:

• Two or three years of transaction history. Less than that and you do not have enough losses to learn the pattern. A model needs to watch a decent number of customers leave, not four.
• A stable customer identifier that joins CRM, ERP and, where it exists, the product platform. If the same customer appears as three different records, nothing else matters.
• A date on every event. Orders, tickets, contacts, payments. No date means no sequence, and no sequence means no prediction.
• A reasonable number of losses. If you lose 1% of customers a year and you have 300 accounts, that is three losses: there is nothing to train on. What you need there is a set of explicit rules, not a model.

What you do not need: a data warehouse in place, a data lake, or forty integrations. The first case is built with two extracts and a cut-off calendar. What you do need is for those two extracts to be clean; if you are not sure they are, start there — we cover it in data quality.

One technical detail that matters more than it looks: the history has to be reconstructed "as it looked back then". If you train using the customer's current balance or current category, you are using information you did not have at the time. The model will look brilliant in testing and mediocre in production.

How do you know whether the model is worth anything?

Forget overall accuracy. In churn it is almost always misleading: if 7% of your book leaves each year, a model that says "nobody leaves" is right 93% of the time and completely useless.

What you look at is performance at the top of the list, which is the only part the team will ever work:

• How many of the 50 highest-risk customers actually left within the window. If 18 of the top 50 left and the base rate is 7%, the model multiplies your aim by five. That is already useful.
• How much at-risk revenue that list covers. A model that nails small accounts and misses large ones is worse than one with lower overall accuracy that never drops a hundred-thousand-euro account.
• How many false positives the team can absorb. That is a business decision, not a statistical one. If a call costs half an hour and keeping the customer is worth €20,000, you can afford plenty of false alarms. If the action is a 15% discount, very few.

And the one number that truly closes the loop: the retention rate of the contacted group against a control group that was left untouched. It is uncomfortable, because it means leaving at-risk customers alone for a quarter, and the temptation to skip it is enormous. Without that control you cannot tell whether you retained them thanks to the model or because they were never going to leave. The same baseline logic is explained in measuring AI ROI.

What does the team do with the at-risk list?

This is where most churn prediction projects die. The model works, the list is generated every Monday, and nobody opens it. Six weeks later the project is dead even though it technically works.

What makes it get used:

• The list lives where the person already looks. A "churn risk" field on the CRM record, a filtered view, an assigned task. Not an email with a spreadsheet attached.
• It has an owner. Every at-risk customer is assigned to a named person, not "to the sales team".
• It carries a reason. "83% risk" is not enough. You need "order pace down 40% and an open ticket for three weeks". Without the reason, the rep does not know what to call about and ends up not calling.
• The play is agreed in advance. Three or four prepared moves: a visit, a review of terms, a service call, closing the outstanding ticket. Deciding what to do customer by customer does not scale.
• The loop gets closed. What was done, what happened. Without that record neither the model nor the script can improve. And it is exactly what tends to be missing: we cover it in change management for AI projects.

One more thing, and it is unpopular: not every at-risk customer deserves the effort. Some accounts are leaving because the fit was wrong from day one, and holding on to them with a discount is buying next year's problem. The list prioritises; it does not oblige.

How do you build a first case without launching a year-long project?

A first churn prediction case takes six to eight weeks of real work, not a year. This is how we sequence it:

| Phase | Output | Time | |---|---|---| | Define churn and the window | A written formula validated with the business | 1 week | | Extract and reconcile the history | One table per customer and month, with correct dates | 1-2 weeks | | First model and evaluation | Risk list plus performance in the top 50 | 2 weeks | | Pilot with one team and a control group | Actions executed and logged | 4-6 weeks | | Decision | Move to production, adjust, or stop | — |

Start with a segment, not the whole book. One rep, one product line, one branch. The goal of the pilot is not the best possible model: it is to check that when the model raises a flag, somebody acts and that changes the outcome. If that chain does not work at small scale, it will not work at large scale with a better model.

And if in week one you discover you cannot define churn, or that the customer identifier does not join across systems, you have learned the cheapest lesson available. That groundwork is exactly what explains why so many AI pilots go nowhere.

Frequently asked questions

How much history do you need to predict churn?

At least two years of transactions and enough real losses to learn the pattern: below roughly 50-100 churn events in the history, a model has nothing to generalise from. With less than that it is more honest to start with explicit rules — pace decline, open ticket, no contact in X months — and review them each quarter.

Does churn prediction work in a business without subscriptions?

Yes, but first you have to define what "leaving" means when nobody cancels anything. It is done with a rule over each customer's gap between orders, comparing their historical pace against their current silence. That definition is the most delicate part of the project and should be agreed with the business in writing.

What accuracy is acceptable in a churn model?

Overall accuracy is not a usable criterion because losses are a minority class. What matters is how many customers at the top of the list genuinely leave, and how much at-risk revenue you cover with a number of alerts the team can realistically work. A model that triples or quadruples the base rate already changes how people work.

Can the model discriminate against some customers?

It can, if it is used to allocate discounts or service levels by risk score. It is worth reviewing which variables carry weight, documenting the logic and keeping the model out of commercial decisions. The practical rule: the model prioritises who you call; decisions on price or service stay with a person.

If you have the history and the nagging sense that you are losing customers you could have saved, the first step is not picking a tool: it is checking whether your data supports a useful prediction and whether your team has room to act on it. That is part of what we look at in the audit, and if you would rather talk it through in half an hour, let's talk.