The delivery date is a promise, so treat it like one
Checkout estimates are usually a static guess. That guess is doing more conversion damage than the shipping price.
Most checkouts show a delivery estimate that was typed into a settings field once and has not been revisited since. It ignores the cut-off time, the day of the week, the destination and the carrier's current performance. It is not a forecast. It is a decoration.
What a real estimate accounts for
- The cut-off: an order at 16:58 and an order at 17:02 do not ship on the same day.
- The calendar: Friday afternoon orders inherit the weekend.
- The lane: Amsterdam to Rotterdam and Amsterdam to Vienna are not the same promise.
- Recent reality: a service holding 71% of its window this month is not a two-day service this month.
Under-promise, but not by much
Padding every estimate by two days makes you accurate and uncompetitive. The useful move is narrower: promise the window the data supports, and be honest when it widens. Shoppers forgive a four-day delivery that said four days. They do not forgive a two-day delivery that took four.
The estimate outlives the checkout
The date you show at checkout should be the date on the confirmation email, the tracking page and the support screen. When those disagree, the customer contacts you, and the cost of the ticket usually exceeds whatever the faster service would have cost in the first place.
A missed delivery date is a support ticket you paid to create.