Estimated delivery dates on Shopify: promise what you control
“When will I get it?” is the question every product page is silently asked. The honest answer has two halves: how long until the parcel leaves you, and how long the carrier takes after that. You control the first completely and the second not at all — and most delivery-date advice goes wrong by mashing the two into one confident-looking number.
Delivery = dispatch + transit
The dispatch half is yours: processing time, working days, order cutoff, holidays, how deep your production queue is. Nothing about it is uncertain — it’s your own calendar, and you can state it as precisely as you like.
The transit half belongs to the carrier. Royal Mail, USPS or DHL publish a service window — “2-4 working days” — and their actual performance varies by lane, season and luck. You can’t promise their half; you can only repeat what they publish.
That asymmetry is the whole subject. A store that says “dispatches by Tuesday 20 January, then Standard delivery 2-4 working days” has made one precise commitment it can keep and passed the second on accurately. A store that says “delivered by 23 January” has fused them into a promise nobody is actually standing behind.
What Shopify gives you out of the box
At checkout, shipping rates can carry transit descriptions, and stores using Shopify Shipping in some regions can show carrier-calculated windows there. Shop Promise, where an order qualifies, shows a delivery estimate Shopify itself stands behind. All of that lives at checkout — after the buying decision.
The product page — where the decision actually happens — has nothing native: no handling time field, no delivery estimate. Whatever appears there is added by your theme or an app, which is why the quality varies from honest to invented.
Why estimator apps produce dates nobody stands behind
A whole category of apps paints “Get it by 23 January” on the product page. Under the hood, most add two configured paddings to today’s date: an assumed processing time and an assumed transit time. The app doesn’t know your production queue, and it doesn’t know what the carrier will actually do — it’s arithmetic dressed as knowledge.
The asymmetry of a broken date. A specific delivery date converts slightly better than a vague one — and every miss lands on you, not the app or the carrier. The refund email doesn’t say “the estimate was third-party”; it says you were late.
This is a deliberate line in how DispatchFlex is built: it computes and displays the dispatch promise, because that’s the half a store can actually keep, and it never invents a delivery date. If a tool offers you carrier-level precision it doesn’t have, the precision is the product being sold to you, not to your customers.
The honest pattern: precise dispatch, quoted transit
The version that survives contact with reality is one line near the buy button in two parts:
Dispatches by Tue 20 January · Standard delivery 2-4 working days after dispatch
The first half is computed from your real calendar — lead time, cutoff, working days, holidays — and updates itself daily. The second half is the carrier’s published window, stated as theirs. Shoppers do the addition effortlessly, and every part of the sentence has someone standing behind it.
Making the dispatch half precise is what DispatchFlex does: per-product lead times, a working calendar with cutoff and holidays, and a product page badge that always shows the current real dispatch date, with plain text as the fallback. What it deliberately doesn’t do is guess the carrier’s half.
The options side by side
| Approach | Specific | Someone stands behind it | Where it breaks |
|---|---|---|---|
| Nothing on the product page | No | — | Shopper assumes Amazon speed |
| Static “ships in 3-5 days” | Somewhat | You, loosely | Goes stale; ignores your calendar |
| Estimator app delivery date | Very | Nobody | Every miss is your refund |
| Computed dispatch + carrier range | Very | You + the carrier, each for their half | Holds |
Getting there in an afternoon
- Write down your real processing time per product or product family, in business days.
- Pick your cutoff — the time after which an order counts from the next working day — and stick to it.
- Copy transit windows from the carrier’s site, per service you offer, and use their wording.
- Name checkout rates to match: “Standard (2-4 working days after dispatch)” beats “Standard”.
- Keep the shipping policy in agreement — it’s what disputes get judged against.
If your products are made to order, the dispatch half has its own depth — the made-to-order lead times guide covers quoting production time honestly, and how to show handling time on Shopify covers the mechanics of putting any of this on the page.
Frequently asked questions
- Can Shopify show an estimated delivery date on the product page?
- Not natively. Shopify can show transit times on shipping rates at checkout, and Shop Promise shows delivery estimates for eligible orders in some regions, but the product page itself has no built-in delivery date. Anything shown there comes from your theme or an app.
- Are delivery-date estimator apps accurate?
- They're as accurate as their weakest guess. A delivery date is dispatch time plus transit time; estimator apps know neither your production queue nor the carrier's actual performance on a given lane, so most simply add configured paddings to today's date. That produces a confident-looking date nobody has committed to.
- What's the difference between dispatch date and delivery date?
- The dispatch date is when the parcel leaves you — it depends on your processing time, working days and cutoff, all of which you control. The delivery date adds the carrier's transit on top, which you don't control. A store can promise the first precisely and should quote the second as the carrier's own range.
- Should I promise a delivery date at checkout?
- Only if someone is actually committed to it. Shop Promise-eligible orders and premium carrier services with guarantees are commitments; a number an app invented is not. A promise you can't enforce becomes your refund conversation, not the carrier's.