Delivery promise: the date that changes conversion

Be precise about what is known, because this area is thick with numbers nobody can trace. Baymard Institute maintains an aggregate of around fifty cart abandonment studies and reports an average abandonment rate of roughly 70%. When they exclude people who were only browsing, the leading fixable reasons are extra costs at checkout, then delivery being too slow, then payment trust, forced account creation and checkout length.

Read that carefully. It says slow delivery loses orders. It does not say that *displaying a date* wins them. Those are different claims, and the second one is mostly evidenced by case studies published by companies that sell delivery date widgets — which is not evidence, it is a brochure.

The mechanism that does hold up is uncertainty. A shopper with a deadline — a birthday, a holiday, a job that starts on Monday — is doing arithmetic your site refused to do for them. Some of them guess wrong and leave. Some open a competitor's tab to compare, and comparison is never free. Answering the question on the page removes a reason to leave, which is the same mechanism that makes shipping cost transparency work.

So the honest framing is not "add a date and conversion goes up". It is: you already have a delivery speed, your shoppers are already estimating it, and they are estimating it worse than you could.

Here is the advice that loses us work. If your real delivery is five to seven working days and your competitors are next-day, showing the date will reduce conversion on some products. That is not a bug in the display, it is the display working — you have made a weakness legible.

We still recommend showing it, for three reasons. Customers who abandon because of a seven-day date were largely going to cancel, refund or complain anyway, and those orders cost you more than they earn. Support load drops, because "where is my order" tickets are overwhelmingly from people whose expectation was never set. And the customers who do buy start the relationship with a promise you kept, which is the only durable input to repeat rate.

The alternative — hiding the date until the order confirmation email — converts slightly better and produces a customer who feels misled. That trade looks good in a monthly conversion report and bad in a twelve-month cohort.

What we would not do is inflate the promise. Showing an optimistic date to close the sale is the one variant of this that is straightforwardly worse than doing nothing, and it is common.

The date belongs where the decision happens, and the decision mostly does not happen at checkout.

Product page, near the buy button. This is where the deadline question is live and where most of the value is. It also means the estimate has to work without knowing the customer's address, which is the practical constraint everyone hits — you show a date for a default region and refine it later rather than showing nothing.

Cart and checkout. Now you know the shipping address, so the date gets specific, and it can differentiate the shipping methods. A checkout that presents "Standard — arrives Thursday 19th, £3.95" against "Express — arrives Tuesday 17th, £7.95" is selling on the thing the shopper actually cares about. A checkout listing "Standard" and "Express" with two prices is asking them to guess.

Collection pages, sparingly. A "next day" badge on a filtered listing is useful. A computed per-product date across a 60-item grid is a lot of machinery for a page nobody is making a deadline decision on.

The confirmation email and the account page. Repeating the promised date after purchase is what prevents the support ticket, and it costs nothing.

Shopify has a native delivery promise system, but its provider objects are documented as restricted to approved delivery promise partners, so it is not currently a thing most merchants switch on. In practice you are choosing between an app and a small piece of your own logic.

An app is the right call when your fulfilment is simple — one location, one carrier, a fixed cut-off — because the whole job is a configuration screen and somebody else maintains the bank holidays. Buy it and move on.

Build it when the rules are yours: multiple locations with different cut-offs, split shipments, made-to-order or backordered lines, or a 3PL whose real dispatch behaviour does not match the contract. The logic ends up living in one service that answers "what date, for this variant, to this destination, right now", and the product page, cart, checkout and emails all ask that one thing. What ruins these projects is the same rule implemented four times in four templates, drifting apart over a year.

Either way, the calendar is where the bugs live. Weekends, public holidays that differ by country, the warehouse's own shutdown between Christmas and New Year, and the fact that a cut-off at 4pm local is not 4pm for the customer. Write tests for the dates, not for the component.

Measure it as a proper test rather than by looking at conversion the following week, because delivery date rollouts are usually shipped in peak season when everything else is moving too.

Watch four numbers, not one. Conversion rate on the pages that show the date. Shipping method mix — a good date display usually shifts people towards the cheaper, slower option, which raises margin even where conversion is flat. "Where is my order" contact rate. And promise accuracy: the percentage of orders that actually arrived by the date you showed, which is the only number that tells you whether to trust the other three.

If promise accuracy is below about nine in ten, stop optimising the display. You do not have a conversion problem, you have a fulfilment problem wearing a conversion problem's clothes.

• Shopify conversion rate optimisation
• Shopify UX and checkout audit
• The product page audit: twenty things worth checking