Churn Prediction: You're Modeling the Wrong Moment

Churn prediction is a standard insurance analytics project. Build a model that scores which customers are likely to leave at renewal, so you can intervene with a retention offer. Nearly every carrier has tried it. Most are disappointed with the results.

The disappointment isn't because the models are bad. It's because they're pointed at the wrong moment.

The renewal is where you find out, not where it happens

Most churn models predict, a few weeks before renewal, who won't renew. That's useful for triage — but it's late. By the time renewal approaches, the customer has usually already decided. The claim that soured them happened eight months ago. The competitor's ad landed last quarter. The rate increase that broke the relationship was applied at the last renewal.

Predicting churn at renewal is like a doctor predicting a heart attack in the ambulance. Technically a prediction; not much use for prevention. The decision to leave is made continuously, throughout the policy period, in response to events — and events are where intervention actually works.

The events that actually predict churn

Churn is caused by moments, and the moments are scattered across the very systems that don't talk to each other:

  • A bad claim experience. The single biggest driver. A claim that was slow, disputed, or underpaid is a churn event — and it happens mid-term, in the claims system, invisible to the renewals team.
  • A rate increase. Especially a large or unexplained one. This is in billing.
  • A frustrating service interaction. Long hold, unresolved issue, repeated calls. This is in the contact-centre logs.
  • A life event. Moving house, a new car, a child — moments when people re-evaluate all their cover. Often visible in your own data if you're watching.
  • Digital disengagement. Someone who stops opening emails or logging in has often already mentally left.

Notice these live in claims, billing, contact-centre, and behavioural systems — each of which is a different silo, none joined to a single customer view. So the renewal model can't see them. It sees policy attributes and a renewal date, and tries to predict a human decision from the least informative data available.

Why this makes the standard model underperform

A model trained on policy attributes and prior renewals learns weak, generic patterns — "older policies churn less", "higher premiums churn more". True on average, useless for the individual. It can't see the claim that just went badly, because that data isn't in front of it.

So the model's best customers to "save" are often ones who were never going to leave, while the genuinely at-risk customer — the one whose claim was mishandled last month — isn't flagged, because the signal that would have flagged them lives in a system the model doesn't reach.

The reframe: churn is an event-detection problem

Stop thinking of churn prediction as a renewal-time scoring exercise. Think of it as continuous event detection:

1. Detect the churn events as they happen. A poor claim outcome, a big rate jump, a bad service interaction — flag these in real time, mid-term, the moment they occur.

2. Intervene at the event, not at renewal. The time to save a customer whose claim went badly is right after the claim, when you can still fix the experience — not eight months later with a discount that reads as an admission you knew and didn't care.

3. Use renewal scoring as a backstop, not the strategy. A renewal-time model is fine as a final safety net. It just shouldn't be the whole programme.

What has to be true

All of it comes back to the same foundation. To detect churn events you need claims, billing, service, and behavioural data joined to one customer identity, updating continuously. The claim that soured the customer has to connect, in real time, to the renewals and retention process. Without the customer key and the real-time join, event-based retention is impossible, and you're stuck predicting the heart attack in the ambulance.

The point

Your churn model isn't underperforming because it's the wrong algorithm. It's underperforming because it's asking "who will leave at renewal?" when the useful question is "who just had an experience that will make them leave — and can we still fix it?"

The first question you can answer from a policy table. The second requires seeing the whole customer as things happen to them. That's harder, and it's the only version that actually retains anyone.

We unify claims, billing, service, and behavioural data into the real-time customer view that event-based retention needs. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Why Insurance Fraud Rings Are a Graph Problem (And Your SQL Database Can't See Them)

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work. They're nearly blind to organised fraud — and organised fraud is where the money goes. The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer. What a fraud ring actually looks like A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months. Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolati...
Read more

Claims Leakage: The Quiet Loss AI Can Close

Claims leakage is the money your company pays out that it didn't have to. Not fraud — leakage. The extra amount on legitimate claims that got overpaid because someone missed something, applied the wrong rule, or lacked the information to know better. Industry estimates put it at 3–10% of claims spend. For a mid-size insurer that's a rounding error you could retire. And almost nobody manages it directly, because it's nearly invisible — every individual leaked rupee looks like a normal payment. Why leakage is so hard to see Fraud has a villain. Leakage doesn't. It's the accumulation of small, defensible, individually-reasonable decisions: An adjuster settled at the reserve figure because they were busy, and the reserve was set high. A repair was authorised at shop rates when a network rate applied. A subrogation opportunity was never flagged, so recovery never happened. A policy limit or deductible was applied wrongly because the coverage detail was buried...
Read more

The Subrogation Money Insurers Leave on the Table

Subrogation is the least glamorous word in insurance and one of the most profitable. It's the process of recovering money from the party actually responsible for a loss, after you've paid your customer. Done well, it flows straight to the bottom line — recovered money is nearly pure margin. Most insurers leave a lot of it on the table. Not because they don't try, but because the opportunities are identified too late, by the wrong people, from incomplete information. It's a data problem, and it's an unusually clear one. Why subrogation is a timing game you're losing Recovery potential decays fast. The evidence that establishes another party's liability — the scene, the witnesses, the vehicle, the maintenance records, the CCTV — degrades or disappears within days. The other party's insurer gets less cooperative once they've closed their own file. So the single biggest lever in subrogation is identifying the opportunity early , ideally at first ...
Read more