Delivery promises on a product page you can actually keep

Promised date =
    the next cutoff you genuinely hold
  + pick and pack working days
  + the first delivery day with spare capacity
  + buffer = your own 90th-percentile lateness

The promise is made by the website, before the operation gets a vote

The sequence in most operations: a customer adds an item at 16:50, the product page says "order within 1 hour 10 minutes for delivery Thursday", the order lands in the warehouse queue. At 19:00 somebody builds Thursday's routes and finds Thursday already has 140 drops against a sensible ceiling of 120.

Nobody lied. The website did not know. It was reading a static rule written months ago, and the rule has no idea what Thursday looks like.

That is the whole problem. The promise is made by a system with no view of capacity, and kept or broken by a system with no say in the promise. Closing that gap does not need live capacity integration to start. It needs honest numbers in the static rule.

Ecommerce delivery dates: work backwards from four numbers

1. The cutoff you actually hold. Not the published one. Walk the floor and find the time the last pick of the day genuinely goes out the door. If the site says 17:00 and picking actually closes at 16:15 because the carrier collection is at 16:40, your real cutoff is 16:15. Publish that. A 45-minute lie at the front of the chain turns into a whole day of lateness at the back.

Do this per fulfilment site, and per product type where handling differs.

2. Pick and pack time, in working days. Measure from order received to parcel ready, excluding weekends and days you do not dispatch. Use the p90, not the average: the average is a Tuesday in February, and the promise has to survive the Thursday before a bank holiday.

3. The first day with spare capacity. This is the number almost nobody puts in the promise. Capacity is not a single figure. It is drops per van per day for a given area, and it varies by area more than most people expect, because drop density is the thing that actually governs it.

Daily capacity for an area =
    vans available
  x productive hours per van
  / (average travel time per drop + average dwell time per drop)

Dwell time is the minutes at the door, and it is the figure most often left out. Flats with intercoms, offices with a reception and signature-required items all cost minutes the route plan may not allow for. Measure your own: the arrival and completion timestamps in your field app contain the answer. Planning the route and running the day are different jobs, and promisable capacity comes from the second one.

4. The buffer. Covered next, because it is the number most often set by hope.

Size the buffer to your own failure rate, not to optimism

Take 60 days of completed orders. For each, compute:

Lateness = actual delivery date - promised date

Sort the list and read off the median and the 90th percentile.

If your median lateness is 0 and your p90 is +2 days, then a promise with no buffer will be missed on more than 10% of orders. A one-day buffer still misses some. A two-day buffer catches roughly 90% of them.

Pick the percentile you want to hit and set the buffer to match. Then stop arguing about it: the number came from your own operation, not from anyone's ambition.

Two refinements worth making:

• Split the distribution by area. The tail is almost always concentrated somewhere specific: a rural postcode group, one depot, one subcontracted leg. Two or three zones with their own promises beat one national average.
• Split it by season. The p90 in November is not the p90 in June. Either hold the November buffer all year and accept being conservative in summer, or change the rule on a date you pick in advance rather than during the week it breaks.

A buffer is not padding. It is the price of being believed.

What missing the date actually costs

The argument for a tighter promise is always conversion. The argument against it is the cost of missing, and that cost is usually estimated badly because most of it sits outside the delivery budget.

Cost of one missed date =
    WISMO contacts per missed order x cost per contact
  + redelivery cost, where the miss causes a second attempt
  + refunds, discounts and shipping refunds given to settle it
  + (share of those customers who do not reorder x their value)
  + the review, where it gets written

Three of those five land on customer service, finance and marketing, not operations, which is why operations is rarely the department arguing for a longer promise.

Work out the last line yourself. Take customers who had a missed date in a given month and customers who did not, and compare how many ordered again within 90 days. It is a query against data you already hold, and usually the biggest term in the formula.

Which gives the plain comparison:

Nobody can tell you the exact trade for your catalogue without testing it. But a kept promise compounds and a missed one is a cost you pay repeatedly, and most operations sit further left than they would choose if they had priced it.

Say the window, and tell them before they ask

Two things make an identical delivery feel either accurate or late.

The first is a range rather than a point. "Thursday between 14:00 and 18:00" landing at 17:40 reads as on time. "Thursday at 15:00" landing at 17:40 reads as nearly three hours late, for the same van and the same parcel.

The second is who speaks first. If the customer finds out it has slipped by chasing you, you have had a complaint. If you tell them the morning you know, you have had a message and some goodwill. That turns on whether anyone in the office can see a slipping job before the customer does, which means the day's state has to be visible while it is happening, not reconstructed afterwards. Structured proof capture is what lets you measure the promise honestly once it is over.

One last discipline: review the rule on a schedule. Cutoffs drift, carriers change collection times, a new depot shifts the capacity numbers, and a rule written in March is quietly wrong by October. Put a quarterly date in the diary to re-run the p90 and reset the buffer.

OkPilot gives the office that live view and takes typed instructions — pull tomorrow's overflow into Friday, tell these twelve customers the window has moved — with a person approving each change before anything is sent. Mechanics on the delivery management software page.