A churn model is an easy analytics project to approve and an easy one to abandon. The model itself is rarely the problem. A competent team can usually build a reasonable risk score from usage, billing and support data. What fails is everything after the score: nobody owns it, nobody knows what to do with it, and it lives in a dashboard that the people who talk to customers never open.

A churn model is worth building only if you can say, before the first line of code, who will act on its output, when, and with what options.

Start from the intervention

Work backwards. Before discussing features or algorithms, write down what the business can actually do for an at-risk customer. In B2B the options typically look like this:

  • An account manager calls to review the relationship.
  • Customer success schedules a usage review or training.
  • Service prioritizes the customer’s open tickets.
  • Sales prepares the renewal offer earlier than usual.
  • Management brings in an executive sponsor.

Each of these has a cost, a capacity limit and a lead time. If your account managers can make a handful of extra calls a week, a model that flags fifty accounts is not helping. If a renewal offer takes a month to approve, a warning two weeks before renewal is too late. The intervention tells you what the model has to deliver: how many accounts, how early, and with what explanation.

Questions to settle before modeling

  1. Who receives the signal? A named role, not “the business”.
  2. Where do they see it? In the CRM record they already open, in their task list, or in a weekly review. Not in a separate tool.
  3. How many signals can they act on? This sets the threshold. Team capacity, not statistics, decides where to cut.
  4. What lead time do they need? This sets the prediction horizon.
  5. What reason do they need? A bare score is easy to ignore. “Usage dropped after the main contact left” gives the account manager something to say on the call.
  6. How will you record what they did? Without this you can never learn which interventions work.

Define churn precisely

In subscription businesses churn is fairly clear: the contract ends and is not renewed. In much of B2B it is not. A wholesale customer does not cancel; it orders less, then less again. A manufacturing client moves one product line to a competitor and keeps the rest.

Decide which of these you are predicting. Full loss, partial loss and downgrade call for different interventions and need different data. A model that mixes them produces scores nobody can interpret.

Close the loop

What separates a working churn program from a one-off project is the feedback loop. Every flagged account should end with a recorded outcome: contacted or not, what was done, and whether the customer stayed. That record does two jobs. It shows whether the interventions help, which is the question leadership actually cares about. And it gives the model new information to learn from.

Be careful when reading the results. If the team acts on every high-risk account and those customers stay, the model can look wrong when it was in fact useful. Where it is commercially acceptable, leaving a small group of flagged accounts without special treatment is the cleanest way to tell the difference. Where it is not, compare against flagged accounts the team had no capacity to reach, and be honest about how weak that comparison is.

Failure patterns

  • The orphan dashboard. The score exists, but only the analytics team looks at it.
  • The black box. Account managers get a number without a reason and quietly stop trusting it.
  • The flood. Too many flags, so people pick the accounts they were already worried about, and the model adds nothing.
  • The late warning. Accurate predictions that arrive after the customer has already decided.
  • No memory. Actions are not recorded, so a year later nobody can say whether any of it worked.

All five come from the same root: the analytics was designed around the data, not around the people and the workflow that consume it. Reverse that order and most of them disappear.

A practical way to begin is one working session with the people who would receive the signal. Map what they do today when they sense a customer drifting away, how much time they have for it, and what they wish they had known earlier. That conversation tends to shape the model more than any choice of algorithm.