7 min read
A customer service team receives every Monday morning an update of at-risk customers generated by the churn model, whose objective is to activate a retention strategy before the customer formalises the departure. The previous Friday, the monthly billing cycle had processed renewals and cancellations. The day before, the model had correctly identified the customers who were not going to renew.
The model was working. The prediction arrived two days before the event it was predicting. The problem is that the only moment the team could intervene was before Friday, and the prediction arrived after the close of the week. That misalignment is a consequence of having configured the horizon without overlaying the two constraints that define when a prediction arrives on time — one from the customer process side and one from the model signal stability side.
What the intervention window is and its two boundaries
The intervention window is the period between the moment the model emits a prediction and the moment the event occurs. If the model predicts today that a customer has a high probability of not renewing in the coming weeks, the window is the time available to act before that event. That period has a floor and a ceiling that come from different sides of the project.
The floor is the minimum time the receiving team needs to convert a prediction into an executed intervention. If the prediction arrives on Thursday about a Friday renewal, the information exists but arrives too late, because the team's process cannot be activated in hours. The floor depends on how the team works (meeting cadence, decision speed, type of contact offered to the customer) — not on how the model is trained. It is a business constraint the technical team cannot negotiate.
The ceiling is the maximum horizon to which the model can predict with useful precision. Predicting six months in advance is technically possible and valid for some problems, but in the typical churn case customer behaviour at that horizon is less stable. The signal weakens because the customer has not yet started forming the decision that is being predicted. This ceiling is determined by the properties of the dataset and observable behaviour — not by the business team's constraints.
The useful window is the intersection of those two boundaries. When the ceiling falls below the floor (the signal degrades before the team can coordinate the intervention), there is no useful window available and the problem requires redefining the process or the type of intervention before attempting again with the same model.
What determines the floor and what determines the ceiling
The floor moves according to the type of intervention the receiving team activates. An automated communication can be triggered in hours and admits short windows. A personalised call from an account manager requires days of coordination. A process of negotiating contract terms can require weeks. Each type of intervention defines a different floor for the same customer. The same model, the same prediction, yet the necessary window changes because the response demanded from the team changes.
The ceiling moves according to two technical variables that act simultaneously: signal stability and volume of capturable events. Predictive stability is the first. It defines up to what time horizon the customer's observable behaviour continues to be a good predictor of the future event. But even where the signal is stable, there is a second constraint: the volume of positive events that the chosen window captures for training. A seven-day window captures fewer historical churn events than a sixty-day window, because it limits the observation to the last weeks before the event. If the minority class is very small, that volume constraint can make training a robust model infeasible even with oversampling. The real ceiling is the minimum of the two — up to where the signal stays stable and up to where there is enough data to model it.
The data team knows the two ceiling variables. The receiving team knows the floor. When they do not come together to overlay both limits, the horizon remains implicit in the data team's technical decisions, which tends to optimise for aggregate predictive accuracy without visibility into the receiving team's cycle. The result is a model that produces correct outputs and actions incoherent with the process. The prediction is valid, but arrives at a moment when it can no longer be converted into the intervention that would resolve the problem.
Examples by contract type
The contract type determines when the event occurs and with how much advance notice the customer's decision forms. That moves both limits differently.
In a monthly subscription, the cycle is short. The floor is between five and seven days — the minimum time for a customer service team to coordinate an automated or light-touch contact intervention. The ceiling is around two weeks, because beyond that the customer has not yet started forming their renewal decision and recent signals do not reflect the decision being predicted. The useful window falls between seven and fifteen days before the expiry.
In an annual contract, the floor is several weeks because coordinating an account manager call or a commercial review is not done in a day. The ceiling is further out because the signal stays stable over a longer horizon, sustained by usage patterns during the year, evolution of the account relationship and unresolved incidents. The useful window falls between thirty and sixty days before expiry, with the model working on signals accumulated over the period — not just the last few weeks.
In service models without a fixed expiry date, the event is diffuse. The customer gradually reduces usage or stops interacting without cancelling. The window is defined as days before usage drops below a threshold the business team defines. The floor still comes from the intervention time; the ceiling from the point at which the usage pattern starts to be predictively stable over sufficient volume.
What happens when one dimension is ignored
The most common error is leaving the horizon implicit in the data team's technical decisions, without explicit overlap with the receiving team's cycle. The technical team optimises for aggregate predictive accuracy, chooses the window where the model metrics are highest, and does not verify whether the team can consume that output at that cadence. A model that predicts more accurately at thirty days is not the one that generates most value if the team operates on weekly cycles.
The misalignment is hard to detect from the technical pipeline. The model metrics measure the quality of the prediction within the chosen window — not whether that window was appropriate for the process. An AUC of 0.85 and predictions that arrive systematically late are perfectly compatible. The technical report says the model works, and the receiving team confirms it is inapplicable.
The inverse case — ignoring the technical ceiling — is less frequent but produces the same effect by another route. If the receiving team asks for predictions two months in advance because their coordination cycle is long, without verifying whether the signal stays stable at that horizon and whether there are enough events in the base to train on, the model may produce low-precision predictions that exhaust the team's confidence before the process is adjusted. Both cases converge on the same symptom. The signal arrives, but it is not useful.
A conversation between two teams before configuring the model
Agreeing on the window is a conversation between the data team and the receiving team, where each contributes information the other does not have: what is the real coordination time per intervention type, up to what horizon the signal stays predictive, how many positive events the chosen window captures.
With that combined information, the model configuration, the delivery cadence to the receiving team, and the type of intervention assigned to each probability level are aligned from the start. That alignment is paid once, before starting; when it is not paid at that point, it is paid later with adjustments that cost retraining, re-validation and the receiving team's confidence. The window is an agreement between two teams about what makes a prediction useful — more than a property of the model.