Most businesses that ask for a churn model are really asking a different question: is it worth knowing who is about to leave, given we may not be able to stop them anyway? Here is how to work that out before you spend anything.
The number that decides everything
Before any modelling question, there is an arithmetic one. A churn model earns its keep only if three things are true at once: you can identify at-risk customers earlier than you do now, you can do something about it, and the something works often enough to cover its own cost.
Write down four numbers about your business:
- Customers at risk per month. How many accounts would realistically be flagged — not your total base, but the slice a model would surface as worth contacting.
- Value of a saved customer. Not lifetime value in the marketing-deck sense. The margin you actually collect from an average account over the next twelve months.
- Cost of an intervention. The discount, the call, the account manager's hour, the free month.
- Save rate. What fraction of contacted customers stay who otherwise would have left. If you have never measured this, assume something modest — 10 to 20 per cent is a defensible starting point for most subscription businesses.
Monthly return is roughly: customers flagged × save rate × value per customer − customers flagged × intervention cost. If that number is smaller than a few lakh rupees a month, a custom model is probably not your best next investment. That is a genuinely useful answer, and it costs nothing to reach.
A B2B SaaS business with 2,000 accounts flags 60 a month. Average annual margin per account is ₹90,000. An intervention costs ₹2,500 in account-manager time and discount. At a 15 per cent save rate: 60 × 0.15 × ₹90,000 = ₹8.1 lakh recovered, against 60 × ₹2,500 = ₹1.5 lakh spent. Net ₹6.6 lakh a month — a pilot pays back inside the first quarter.
Change one number — drop the save rate to 5 per cent — and the return falls to ₹1.2 lakh. Still positive, but the payback period roughly triples. This is why the save rate is the number worth arguing about first.
Where the cost actually sits
Teams new to this expect the model to be the expensive part. It rarely is. A gradient-boosted classifier on tabular data is a few days of work, and much of that is evaluation rather than training. The expensive parts are upstream and downstream.
| Stage | Typical share of effort | Why |
|---|---|---|
| Getting the data out | 35–45% | Billing, product usage and support live in three systems that disagree about what a customer is. |
| Defining churn | 10–15% | Non-renewal, downgrade, and ninety days of silence are three different labels with three different models. |
| Training and evaluation | 15–20% | The modelling itself, plus honest benchmarking against your current process. |
| Deployment and monitoring | 25–30% | Scheduled scoring, getting predictions in front of the people who act on them, drift alerts. |
If a proposal spends most of its budget on modelling, the person who wrote it has not built one of these before.
Define churn before you define features
This is the step that quietly sinks projects. "Churn" means something specific and unglamorous, and the definition has to be one your business can act on.
A contractual business has it easiest: a customer churns when they do not renew. But even then you must decide whether a downgrade counts, and how you handle accounts that lapse and return two months later. A non-contractual business — retail, marketplaces, most consumer apps — has no renewal event at all, so churn has to be invented: no purchase in ninety days, no login in sixty. Pick a window that matches how your customers actually behave, then check it against history. If half your "churned" customers in last year's data came back on their own, your window is too short and your model will spend its capacity predicting normal seasonality.
The second half of the definition is timing. A model that tells you someone is leaving on the day they leave is a report, not a prediction. Decide how much warning your team needs to act — usually two to six weeks — and build the training data so the model only sees information available at that point. Features computed after the fact are the single most common cause of a model that scores brilliantly in testing and does nothing in production.
What to compare against
Every churn model should be benchmarked against the thing you do today, even when today's process is an account manager's instinct. Ask three of them to name the twenty accounts they are most worried about, seal the list, and check it in three months. That is your baseline, and it is often better than people expect.
Then judge the model the way you will use it. Overall accuracy is close to meaningless when 5 per cent of customers churn — a model that predicts "nobody leaves" scores 95 per cent. What matters is precision within the group you can afford to contact. If your team can work fifty accounts a month, the only question is how many of the model's top fifty actually churn, compared to the top fifty from the account managers' list.
The part everyone skips
A prediction that no one sees changes nothing. Before the model is built, decide where the score lands: a column in the CRM, a weekly list in the team's inbox, a dashboard tile. Decide who owns the follow-up and what they are authorised to offer. Decide how you will know whether the intervention worked — which usually means holding back a small control group who get no contact at all, so that in six months you can measure the save rate rather than estimate it.
That control group is uncomfortable to agree to and it is the only thing that will ever tell you whether the model earned its money. Build it in from day one.
A reasonable first step
If the arithmetic at the top of this article looks promising, the sensible first engagement is small: two to four weeks, one clearly defined churn label, a model trained on your history and scored against your current process, with the results delivered as a ranked list your team can work from. No deployment, no pipelines, no retraining schedule. If it does not beat what you already do, you have spent a modest amount to learn something valuable and you stop.
If it does beat your baseline, the productionising work is well understood and can be scoped with real numbers rather than optimism.