Delivery Time Prediction Customers Can Trust

Why the fixed promise keeps breaking

Most online shops and B2B suppliers promise the same thing for every order: dispatched within 24 hours, delivered in two to three working days. It is simple, and it is wrong in both directions. Orders placed at 3pm on a Friday with an item from the overflow warehouse going to the Scottish Highlands are not the same as a Tuesday morning order for a stocked item to Manchester.

When the promise is missed, customers phone or email. When it is too pessimistic, they buy elsewhere. Both show up in the numbers, just not in the same report.

What actually determines delivery time

Delivery time is the sum of several stages, and each has its own drivers. Predicting them separately is usually more accurate and far easier to explain.

A model per stage, typically gradient-boosted trees or quantile regression, combines into a full estimate. It also shows where delays come from, which is useful beyond the customer-facing date. The wider fulfilment picture is in our post on order-to-delivery automation.

Promise the date you will hit, not the average

This is the most important design decision and the one most often got wrong. If the model predicts a median of three days and you show three days, you will be late on roughly half of orders. That is how trust is lost.

• Predict a distribution, not a single point, using quantile models
• Choose the promise percentile deliberately; around 85% to 95% on-time is a common target
• Show a range for longer or riskier deliveries, such as Tuesday to Thursday
• Tighten the estimate as the order moves: at dispatch, at carrier collection, out for delivery

Customers forgive a later date they were told about. They rarely forgive an earlier date that was missed.

The percentile is a commercial choice. A furniture retailer with two-week deliveries can afford a wide, honest range. A same-day grocery service needs a tight window and accepts more operational cost to keep it.

A worked example for an online retailer

Imagine a homeware retailer shipping 1,500 orders a day from two warehouses through three carriers. The checkout currently says two to four working days for everyone. Where-is-my-order contacts are the largest category in customer service.

A model trained on six months of timestamps shows that most delays cluster in predictable places: orders after the 2pm cut-off on Fridays, items stocked only in the second warehouse, one carrier's performance into certain rural postcodes, and the week before a bank holiday. The checkout then shows a specific date per basket and postcode, set at the 90th percentile. Where an order is at risk after dispatch, an automated message goes out before the customer has to ask.

Precise gains depend on how poor the old promise was, but the mechanism is reliable: fewer missed promises generate fewer contacts, and proactive updates deflect many of the rest.

Keeping predictions honest over time

1. Measure on-time rate against the promise every week, split by carrier, warehouse and region
2. Watch calibration: a 90th percentile promise should be missed about one time in ten
3. Retrain frequently in peak season, when carrier performance changes quickly
4. Override manually for known disruptions, such as strikes or severe weather, and log it
5. Feed carrier exceptions back into the model rather than treating them as noise

Peak season is where delivery time models most often fail, because the last peak was a year ago and carrier capacity has changed since. Keep a manual adjustment available and do not be embarrassed to use it.

When a model is not the answer

If you ship a few dozen orders a day with one carrier to one country, a well-chosen fixed promise with a cut-off time clock and good tracking emails will do most of the job. The data is also too thin to model many combinations.

A model is also premature if timestamps are missing. Many businesses have order and dispatch times but no reliable delivered time because carrier tracking is not stored. Start by capturing carrier events through their APIs; that data is valuable on its own and needed for anything more.

How SpiderHunts would build it

SpiderHunts would first measure your current promise against actual delivery times, split by the drivers above. That report usually shows where the promise is wrong and by how much, and some fixes, like an honest Friday afternoon message, need no model.

Then we build stage models, expose the estimate through an API the checkout, order confirmation and customer service tools can call, and wire up proactive delay notifications. The modelling is machine learning work; the customer messaging and support deflection can connect to an AI support assistant that answers where-is-my-order questions with the same prediction.

Frequently asked questions