Propensity models a CRM team can actually run

Most CRM teams we meet have a churn model somewhere. It was built by a data scientist who has since moved to another team, it scored the file once, and the scores are still sitting in a table that nobody refreshes. Nothing in the programme reads them.

The failure is rarely technical. The model was usually fine. It was built without a decision attached to it, so when the person who built it left, there was no campaign quietly breaking to alert anyone.

A propensity model earns its place when a specific send changes because of the score, and when somebody notices within a day if the score stops arriving. That is a lower bar than it sounds, and it rules out most of what gets proposed in planning meetings.

Start from the decision, not from the model

Before anyone writes a query, write one sentence in this shape: when this score is high, we will do X instead of Y, for this audience, at this moment.

If you cannot complete the sentence, the model is a report rather than a tool. Two examples of the finished version:

• When a customer's likelihood to lapse in the next sixty days is in the top decile and their value is above median, they enter the retention journey instead of receiving the weekly broadcast.
• When likelihood to buy in the next thirty days is low but category affinity is clear, the reactivation message leads with the category rather than a general offer.

Notice what both sentences contain. A threshold, an audience, an alternative action, and a window. Those four things also tell you how to evaluate the model, because they define the population it will actually run on.

They also expose the models that have no decision behind them. A score that tells you someone is likely to buy anyway usually leads to spending margin on a purchase you were going to get. That is why purchase propensity, on its own, is the model most likely to lose money when it is used naively.

Four models worth the maintenance

For a lifecycle team of two or three people, with an analyst who is not full-time on this, we recommend a short list.

Lapse propensity. The probability that an active customer will not purchase or use the product within a defined window. The label is simply derived from your own definition of lapsed, which is why that definition has to be settled before modelling starts. Used to select who enters retention treatment early, while it is still cheap.

Discount sensitivity. The probability that a customer buys only when there is an offer. Built from past response behaviour at different discount depths. Used in the opposite direction from the obvious one: to stop sending offers to people who buy at full price. This is usually the fastest model to pay for itself, because it saves margin rather than chasing revenue.

Category or product affinity. Not a single model but a set of scores, predicting engagement with a category in the next window. Used to pick the content block, the hero product, and the subject line angle. It degrades gracefully, which matters: a wrong affinity score produces a slightly less relevant email, not a damaging one.

Contact fatigue. The probability that a person unsubscribes or complains given their recent contact history. Used to set per-person frequency rather than applying one cap to everyone. It is the least common of the four and often the most useful.

Two models we usually argue against building early. A full customer lifetime value model is hard to validate and easy to argue about. A channel-preference model almost always reproduces what a simple recency rule already tells you.

Build the label before you touch the features

The label is the part that goes wrong. Most failed models in CRM are label problems wearing a modelling costume.

Define three windows explicitly and write them down:

1. The observation point: the day you pretend to be standing on when the score is produced.
2. The feature window: the history you may look at, which ends at the observation point and never crosses it.
3. The outcome window: the period after the observation point in which the event either happens or does not.

Then build the training set as a series of historical snapshots, one per observation point, going back far enough to cover a full seasonal cycle. This is the work that makes a data warehouse worth having, because reconstructing a customer's state as it was on a past date is close to impossible in a marketing platform.

Two rules save most of the pain. No feature may use data recorded after the observation point, including slowly changing attributes that were overwritten in place. And any feature that is a consequence of the outcome rather than a cause of it has to go, however good it makes the model look.

If your customer records break when someone orders without logging in, fix that first. The identity work we described for guest checkout is a prerequisite here, because a model trained on fragmented histories learns that your best customers are new.

Beat the baseline or ship the baseline

Every model needs a dumb competitor, scored the same way, on the same holdout period. For lapse propensity the baseline is a recency rule. For affinity it is last category purchased. For most things, RFM deciles are a strong and unfairly maligned opponent.

Compare on ranking quality first, since these scores are almost always used to select a top slice rather than to produce a calibrated probability. Then compare on the thing you actually care about: within the population the campaign will run on, how much better is the selection.

A model that beats the baseline by a small margin is often not worth the maintenance. Say so plainly and ship the rule. We have recommended exactly that more than once, and the team involved was relieved rather than disappointed.

The platform question comes after this, not before. Whether the scoring runs in your warehouse, in a notebook, or in something more substantial like the Databricks setup we have written about, the modelling discipline is identical. Infrastructure changes what you can do at volume, not whether the label is honest.

Get the score to the send, then prove it

A score that lives only in the warehouse changes nothing. Decide the cadence, write it into the pipeline, and treat a missing refresh as an incident.

• Score on a fixed schedule, daily for short-window models, weekly for slower ones.
• Write the score, the model version and the scoring date onto the customer profile in the platform, so campaign logic can read all three.
• Never let a campaign use a score older than an agreed limit. Stale scores cause silent failures that look like poor performance.
• Store every score in the warehouse as well, for the evaluation you will want later.
• Monitor the score distribution weekly. A sudden shift usually means an upstream data change, not a change in customer behaviour.

Then prove the value with a holdout group. Randomly exclude a share of the model-selected population from the treatment, and compare outcomes over the full outcome window. This is the only way to separate the model's contribution from the campaign's.

What stays hard is maintenance. A model drifts when your product mix changes, when a market launches, when a tracking change alters a feature's meaning. Put a quarterly re-fit in the calendar with a named owner, and agree in advance what result would make you retire the model. Deciding that in advance is far easier than deciding it about a model somebody is proud of.