A regional logistics company running three thousand deliveries per day across a six-state territory had a late-delivery rate of fourteen percent. The cost of a late delivery was not just the apology. Each missed window triggered a re-delivery attempt, which consumed driver time, fuel, and vehicle capacity. The re-delivery cost averaged $38 per occurrence. At fourteen percent of three thousand daily deliveries, the company was spending roughly $16,000 per day on failures it could not predict.

The operations team tracked failures in retrospect. A delivery was marked late after the window had passed. The team reviewed late-delivery reports weekly to identify patterns — bad routes, unreliable drivers, problematic zip codes — and adjusted accordingly. The adjustments were always backward-looking. By the time a pattern was identified and a fix applied, the conditions that caused the failures had already changed.

The company wanted to move from reactive analysis to predictive intervention. If they could identify which deliveries were at risk before the driver left the warehouse, operations could reroute, reassign, or reschedule proactively. The question was whether the data they already collected was sufficient to build a prediction system.

The Data They Already Had

The company collected more data than they realized. Every delivery had an associated order record with customer address, order size, delivery window, and priority level. The fleet management system tracked vehicle GPS, driver assignment, and route sequences. Weather data was available from a public API. Historical delivery records going back four years contained timestamps for dispatch, arrival, and completion, along with failure codes when deliveries were late.

The failure codes were the most valuable asset. Each late delivery was tagged with a reason: customer not available, traffic delay, vehicle breakdown, incorrect address, weather, or unknown. Four years of tagged failures — roughly four hundred thousand records — provided the target variable for a prediction model. The model did not need to predict failure from scratch. It needed to recognize the conditions under which each failure type occurred.

The challenge was that the failure codes were applied inconsistently. Drivers chose the code from a dropdown, and the dominant selection was “unknown” because it was the fastest to choose. Forty-two percent of failures were coded as unknown. The operations team suspected that most unknown failures were actually traffic delays or customer-not-available incidents, but the data did not confirm this.

Building the Prediction Pipeline

The prediction system was designed in three layers: feature engineering, model training, and intervention routing.

The feature engineering layer transformed raw data into signals that correlated with failure. Raw GPS coordinates were not useful. But the ratio of planned route distance to actual route distance at the time of dispatch was useful — a high ratio meant the route was inefficient, which correlated with late deliveries. The number of delivery attempts to the same address in the past thirty days was useful — repeat attempts meant the customer was difficult to reach. The difference between the delivery window and the driver’s estimated arrival time at dispatch was useful — a narrow gap meant the driver had no buffer for delays.

Weather was a strong predictor but a noisy one. Rain increased failure rates by eighteen percent, but only for deliveries with narrow time windows. Rain on a delivery with a four-hour window was irrelevant. Rain on a delivery with a one-hour window was a significant risk factor. The feature engineering captured this interaction: weather severity multiplied by window tightness.

The model itself was a gradient-boosted tree, chosen for two reasons. First, the feature set was tabular and mixed — categorical features like zip code and driver ID, continuous features like distance and time gaps, and binary features like weekend and holiday flags. Tree-based models handle mixed feature types without the normalization that neural networks require. Second, the operations team needed to understand why a delivery was flagged. Tree-based models produce feature importance rankings and SHAP-style explanations that show which features contributed to each prediction. A neural network would have been a black box that the operations team could not interrogate.

The model was trained on three years of historical data and validated on the fourth year. The validation showed a precision of sixty-eight percent for high-risk deliveries — meaning that when the model flagged a delivery as high risk, it was correct sixty-eight percent of the time. The recall was seventy-four percent — meaning the model caught seventy-four percent of actual failures. Neither number was exceptional. But the intervention cost was low: rerouting a delivery cost $4 in additional fuel and driver time. The failure cost was $38. At a precision of sixty-eight percent, every dollar spent on intervention saved $5.60 in avoided failures.

The Intervention System

A prediction that does not change a decision is an expensive dashboard decoration. The intervention system was the part that actually reduced failures.

When the model flagged a delivery as high risk, the system generated a specific intervention recommendation based on the dominant risk factor. If the primary risk was route inefficiency, the recommendation was to reorder the delivery sequence. If the primary risk was a narrow weather interaction, the recommendation was to widen the delivery window by contacting the customer. If the primary risk was a repeat-visit address, the recommendation was to assign a driver who had successfully delivered to that address before.

The operations team reviewed interventions on a morning dashboard. Each flagged delivery showed the risk score, the dominant risk factor, and the recommended intervention. The team could accept the recommendation, override it, or dismiss the flag. Over the first three months, the team accepted seventy-two percent of recommendations, overridden nineteen percent, and dismissed nine percent.

The overrides were informative. The most common override was for deliveries flagged as high-risk due to weather that the operations team knew would clear before the delivery window. The model used the weather forecast at the time of prediction — typically 6 AM — but the operations team had access to updated forecasts and local knowledge. This feedback was used to retrain the model with a feature that captured forecast update recency, which improved weather prediction accuracy by twelve percent.

What the System Could Not Do

The prediction system had clear boundaries that the operations team learned to respect.

It could not predict novel failure modes. When a bridge closure rerouted an entire zip code’s deliveries, the model had no feature for infrastructure events. The model had been trained on historical patterns, and bridge closures were rare enough to be absent from the training data. The system flagged deliveries in the affected area as medium risk due to route changes but could not predict the severity. Operations handled these events manually, as they always had.

It could not predict customer behavior reliably for new addresses. The repeat-visit feature was one of the strongest predictors, but it required historical data for that specific address. For first-time deliveries, the model relied on zip-code-level aggregates, which were weaker signals. The precision for new addresses was twelve percentage points lower than for repeat addresses.

It could not operate without human judgment. The model was a signal generator, not a decision engine. Every intervention recommendation required human review because the model could not account for context that was not in the data — a customer who had called to complain that morning, a driver who was new to the route, a vehicle that had a mechanical issue the previous day that might recur. The operations team’s contextual knowledge was the difference between a useful intervention and a counterproductive one.

The Outcome

After six months of operation, the late-delivery rate dropped from fourteen percent to 9.7 percent — a thirty-one percent reduction. The daily cost of re-deliveries dropped from $16,000 to $11,000. The prediction system’s operating cost — compute, weather API, maintenance — was $2,800 per month. The net savings was approximately $147,000 per month.

More valuable than the cost savings was the shift in operations team behavior. The team moved from reviewing failures after they happened to reviewing risks before they materialized. The morning dashboard meeting replaced the weekly failure review. Problems were addressed at dispatch rather than at the customer’s doorstep.

The operations team also gained a vocabulary for risk. Before the system, a delivery was either on time or late, and the cause was identified after the fact. After the system, each delivery had a risk profile with specific contributing factors. This vocabulary changed how the team talked about performance. Instead of “our late rate is fourteen percent,” the conversation became “we have forty-two high-risk deliveries today, twenty-six due to weather, eleven due to route efficiency, and five due to repeat-visit addresses.” The specificity made interventions targeted rather than generic.

When Predictive Systems Work

Predictive systems work when three conditions are present: the cost of intervention is lower than the cost of failure, the prediction window is long enough to act on, and the humans in the loop have contextual knowledge that complements the model.

If the intervention cost exceeds the failure cost, prediction is waste. If the prediction arrives too late to intervene, prediction is trivia. If the humans cannot interpret the prediction, prediction is noise.

The logistics company’s system worked because rerouting cost $4 and failure cost $38, the twelve-hour prediction window gave operations time to adjust, and the operations team had thirty years of combined route knowledge that the model lacked.

Test these three conditions before building. If any one is missing, fix it first or do not build the prediction system. A model that cannot be acted on is a liability, not an asset.