“Ships in three days” and “arrives in three days” describe different promises. A customer buying a gift needs the second answer, while a store may have supplied only the first. Google Merchant Center calculates delivery expectations from cutoff, handling and transit time; leaving one of those out can make a short shipping estimate mean something quite different on a calendar.
The product page does not need to teach logistics. It does need to make clear which interval it is showing and when a destination-specific arrival estimate becomes available.
Separate the wait at the store from the journey with the carrier
Fulfillment or handling time covers work before the carrier takes the parcel. Shopify defines fulfillment time as the interval between the order and handing the shipment to a carrier. Transit time begins with the carrier’s part of the journey.
A phrase such as “3–5 business days” is incomplete until the reader knows which interval it names. If it means transit after dispatch, it excludes any wait for packing or stock. If it is an arrival estimate, it needs to account for both parts and the relevant calendars.
Make the location dependency visible too. A range for one destination may not apply to another. When the store needs a postal code to estimate arrival, explain what supplying it will resolve rather than presenting a universal date first and revising it late in checkout.
The platform rules are similar, but their settings differ
Published documentation checked October 15, 2026. This comparison concerns Google Merchant Center estimates and Shopify’s manual delivery dates.
| Question | Google Merchant Center | Shopify manual delivery dates |
|---|---|---|
| What contributes to arrival? | Handling plus transit; the maximum estimate uses their maximum values | Fulfillment time plus carrier transit time |
| What does the cutoff change? | Whether processing starts that day; the merchant specifies the cutoff | Documentation specifies noon at the shipping origin’s local time |
| Which days count? | Configured handling/transit business days, with supported holiday adjustments | Documentation defines business days as Monday–Friday; its worked fulfillment example skips weekends and a holiday |
| What should be checked beyond the wording? | Product-level handling values can override the account setting | Rate and country eligibility; an unsupported rate mix can suppress dates |
Sources: Google’s delivery-time rules and Shopify’s manual-date guidance.
Do not assume the date shown in an ad and the date shown at checkout share the same configuration. Compare the actual product, destination and order time. A mismatch can come from a cutoff or fulfillment setting even when both screens use sensible language.
Shopify also offers automated delivery dates, based on shipping performance. Keep that distinct from a manual promise assembled from the times the merchant enters.
A weekend makes the missing time visible
Consider a hypothetical store with the following explicit rules: handling and transit run Monday–Friday, there are no holidays in the illustrated period, and orders at or after 3 p.m. use the next business day as their processing start. The eligible start is day zero. Carrier handoff happens one business day later. Transit then takes three to five business days, counted from the next business day after handoff.
These are assumptions for this worked merchant calendar, not a claim to reproduce Shopify’s date engine.
| Order placed, origin local time | Processing day zero | Carrier handoff | Estimated arrival |
|---|---|---|---|
| Wednesday, October 14, 2026, 11 a.m. | Wed, Oct 14 | Thu, Oct 15 | Tue, Oct 20–Thu, Oct 22 |
| Wednesday, October 14, 4 p.m. | Thu, Oct 15 | Fri, Oct 16 | Wed, Oct 21–Fri, Oct 23 |
| Friday, October 16, 11 a.m. | Fri, Oct 16 | Mon, Oct 19 | Thu, Oct 22–Mon, Oct 26 |
| Friday, October 16, 4 p.m. | Mon, Oct 19 | Tue, Oct 20 | Fri, Oct 23–Tue, Oct 27 |
The final row is the easiest to misread from a bare “3–5 days” label. The order misses Friday’s cutoff, starts processing Monday and reaches the carrier Tuesday. The three transit days are Wednesday, Thursday and Friday. The five-day endpoint crosses another weekend and lands on the following Tuesday.
Every row uses the same handling and transit durations. The calendar changes because the order enters the process at a different time.
Write the promise at the level you can support
For the hypothetical Friday-after-cutoff order, an arrival message could read: “Estimated arrival October 23–27.” A nearby explanation could say that the estimate includes processing and standard delivery to the selected destination. The interface should show that range only if its calculation has the information needed to support it.
If the page knows only the processing commitment, say so: “Dispatches within one business day after processing starts. Enter your postal code for an arrival estimate.” That copy also requires a clear explanation of when processing starts; otherwise the cutoff remains a hidden extension to the promise.
Avoid placing the long explanation everywhere. Put the arrival expectation beside the delivery choice, with the relevant qualification close enough to be read. A detailed shipping policy can explain exceptions, but it should not be the first place a buyer discovers that the displayed duration excludes handling.
Change the estimate when the order changes
A useful check starts with a real product selection and the actual delivery destination. Change a variant, choose another delivery service and cross the order cutoff. Compare the resulting estimate on the product page, checkout and confirmation. Where one screen cannot yet calculate a date, it should say what information is missing.
Include an unavailable configuration in that check. Shopify’s manual-date documentation lists restrictions on supported rates; a store needs a coherent fallback when its date display is unavailable. An old range left in place can look more definite than an honest explanation that the estimate is not available for that option.
The final promise belongs to the order the buyer is about to place. Keep it attached to that product, service and destination, and use a calendar date when the system can calculate one. A customer should not have to reconstruct the warehouse’s working week to decide whether the purchase will arrive in time.