Estimated Delivery Dates: Setting Realistic Expectations for Customers

"When will I get it?" is the question every product page has to answer before a customer will commit. The trap is that there are two wrong ways to answer it. One is silence — no date at all, so the customer guesses, hesitates, and often leaves. The other is worse: a confident date you can't actually hit, which converts the order today and then generates a "where is my order?" ticket, a one-star review, and sometimes a refund on Thursday. This guide is about the narrow, unglamorous skill that sits between those two failures: producing a delivery estimate that is specific enough to win the sale and honest enough that you actually meet it. That is what "realistic expectations" means — not a marketing date, a date you can stand behind.

If what you're after is the why — the psychology of how a visible delivery date calms a nervous buyer — that's a sibling topic and we cover it properly in estimated delivery dates: the feature that reduces customer anxiety. This post stays on the harder mechanical question: how the number is calculated, where the estimate quietly goes wrong, and how to set it in PrestaShop so it holds up.

The estimate is a sum of three numbers — and only one is under your control

Every delivery date a store shows is built from three components added together. Get the breakdown straight and the rest of this article follows from it:

So what? The only component you fully control is processing time, so that's the one where over-promising is unforgivable — if you say "ships same day" and you actually batch shipments every other morning, that gap is entirely self-inflicted. Transit time you can only estimate from carrier averages. Non-working days are the silent killer: they're completely predictable and yet they're the single most common reason a calendar-day estimate is wrong.

The mistake that breaks most estimates: calendar days vs business days

Carrier transit times are quoted in business days, almost without exception. "2-day delivery" means two working days, not two squares on a calendar. A store that adds "2 days" to a Friday afternoon order and tells the customer "arrives Sunday" has just promised a date on a day its carrier doesn't deliver and its warehouse isn't open. The customer reads "Sunday," nothing arrives, and the trust is gone before the parcel even moves.

Worked through honestly, that same Friday order looks different. Order lands Friday after your cutoff → processing starts Monday → handed to carrier Monday → two business days of transit → arrives Wednesday. Same inputs, two days apart, and only one of them is a date you can keep. Any estimate worth showing has to skip weekends, skip public holidays, and skip your own closures — which is exactly why a hand-typed "3-5 days" on a product page drifts out of sync the moment a bank holiday lands midweek.

Where PrestaShop already holds the raw numbers

You don't have to invent every input from scratch — PrestaShop core holds the display text and some product availability data you can build on. But core stores none of the structured rules a dated estimate actually needs: the processing, transit, cutoff and non-working-day logic has to live in a module. Here's what core gives you to start from:

• Carrier transit time. Every carrier has a free-text Transit time field on its edit page under Shipping → Carriers. PrestaShop displays this string to customers as-is at checkout (its own help text reads "the delivery time will be displayed during checkout"). Treat it as exactly that — customer-facing copy. A module can't reliably do business-day arithmetic by parsing free text like "3 to 4 business days," so if you want a calculated date, configure the structured transit days separately rather than trying to read them out of this field.
• Product availability dates. On a product's Stock tab, the Availability date and the "when out of stock" behaviour can inform your availability messaging — a made-to-order or pre-order product shouldn't carry the same line as something sitting in the bin. They don't, on their own, encode restock lead time or made-to-order handling, though: a realistic dispatch estimate still needs explicit processing and lead-time rules layered on top.
• Stock and warehouses. If you fulfil from more than one location, the origin changes transit time. We cover that wrinkle in multi-warehouse management in PrestaShop.

What PrestaShop does not do out of the box is turn that transit-time string into an actual dated promise on the product page — "Get it by Wednesday, 18 June" — that accounts for your cutoff and skips non-working days. The carrier field is descriptive text; it never becomes a real, weekend-aware date. That conversion is the job an estimated-delivery feature does.

Cutoff time: the lever that decides whether "order now" means anything

The cutoff is the hour after which an order rolls to the next processing day. It's the difference between "Order in the next 3 hours, get it Wednesday" and a quiet extra day no one told the customer about. Set it to match reality — if your last carrier collection is 3 PM and packing takes an hour, your honest cutoff is around 2 PM, not midnight.

Two things make a cutoff dangerous if you ignore them. First, timezone: the cutoff has to be evaluated in your warehouse's clock, not the server's or the customer's, or a buyer in another country sees a countdown that's wrong by hours. Second, the rollover: an order placed at 2:01 PM on a Friday doesn't just lose "same day" — it lands on the weekend wall and doesn't start processing until Monday. A cutoff that's only aware of hours and blind to weekends will quietly promise Saturday dispatch that never happens.

The discipline that separates a realistic estimate from a hopeful one: under-promise

Here's the asymmetry that should drive every decision you make about delivery dates. A parcel that arrives earlier than promised produces a small, pleasant surprise. A parcel that arrives later than promised produces an angry email, a support ticket, and sometimes a chargeback. The downside is far larger than the upside, so the correct bias is always conservative:

• Pad the estimate, not the marketing. If your carrier usually delivers in two days but occasionally takes three, show three. You lose almost nothing on conversion (Wednesday vs Thursday rarely loses a sale) and you gain a date you'll beat most of the time.
• Use a range on routes you don't trust. "18-20 June" beats a single date you miss a third of the time. False precision erodes trust faster than honest uncertainty.
• Widen it for the unpredictable parts. Cross-border orders pick up customs clearance — anywhere from a day to a week of delay you don't control. A wider window there isn't vague, it's accurate.

This is also where the international case diverges. Customs holds, destination-country holidays that differ from yours, and a local last-mile carrier you've never heard of all add variance you can't pin down. "Estimated delivery: 2-7 July" for a cross-border order is more honest — and therefore more useful — than a confident single date you'll miss whenever a parcel sits in customs.

Show the estimate where the decision is being made

An accurate estimate hidden in the footer does nothing. It has to appear at the moments a customer is actually weighing the purchase:

• Product page, next to add-to-cart. The highest-value position — this is where hesitation turns into a click or a bounce. In PrestaShop this slots naturally into the displayProductAdditionalInfo hook, right under the buy button, so it appears without theme surgery.
• Checkout, beside each shipping option. "Standard — arrives by 18 June" next to "Express — arrives by 16 June" lets the customer trade speed against cost with real dates instead of abstract service names. That date is far more persuasive than the bare carrier string PrestaShop shows by default.
• Order confirmation and emails. Restating the date gives the customer a reference point — and a reference point is what stops the "where is it?" email landing two days early.

For deciding whether you can credibly promise the fast end of the spectrum at all, the realistic limits of small-store fulfilment are their own subject — see same-day and next-day delivery: is it realistic for small stores?. And once the parcel is moving, the estimate hands off to tracking — keeping the customer informed after dispatch is covered in tracking numbers and delivery notifications.

Setting it up in PrestaShop without hand-maintaining dates

You can technically type a static "delivery in 3-5 days" line into a CMS block or product description, but the moment a holiday lands or your cutoff slips, that line is lying and nobody remembers to update it. The point of a calculated estimate is that it recomputes itself for every visitor, on the day they're looking. Our Estimated Delivery Date module does exactly that on PrestaShop, and deliberately keeps the configuration to the levers that actually move the date:

• Processing days — how many working days you need between order and dispatch, so the estimate starts from your real workflow rather than an optimistic "we ship instantly."
• Cutoff hour (24h) — orders after this hour add one processing day, turning a vague promise into an honest "order before 2 PM" line.
• Exclude weekends — the estimate counts in business days and steps over Saturday/Sunday automatically, which is precisely the calendar-vs-business-day mistake that catches hand-typed estimates.
• Date format — render the result as a concrete day customers can plan around ("Wednesday, 18 June") instead of a countdown they have to do mental arithmetic on.

So what does that get you? A specific, weekend-aware date appears under the add-to-cart button (via the product-page hook, no template editing), it updates itself every day, and it's driven by settings you control from the back office instead of a developer ticket every time a holiday moves. Set the processing days and cutoff to numbers you can genuinely hit, and the module turns your real fulfilment reality into a date the customer trusts.

On the carrier side — getting the right carriers configured in the first place, with the delivery-time strings that show as checkout copy (separate from the dates the module calculates) — start with setting up carrier modules in PrestaShop, or the integration specifics for DHL, DPD and UPS. The broader shipping setup that all of this sits inside is in our complete PrestaShop shipping configuration guide.

Measuring whether your estimates are actually realistic

"Realistic" isn't a feeling — it's a number you can audit. The metric is simple: of the orders you delivered, what percentage arrived on or before the date you promised? Pull a month of completed orders, compare the promised date against the actual delivery date, and compute the hit rate. Aim for the high 90s.

The direction of the miss tells you what to fix. If you're consistently late, your estimate is too aggressive — add a buffer day to processing or transit, or move your cutoff earlier so fewer orders sneak into the next day unannounced. If you're consistently very early, you're leaving conversions on the table by scaring off buyers with a date that looks slower than you really are; tighten it. Either way it's a fixable dial, not a fact of life. And it's worth dialling in, because the customers most likely to come back are the ones whose first parcel arrived exactly when you said it would.

That's the whole discipline of realistic delivery dates: treat the estimate as a promise you've decided in advance you can keep, calculate it from numbers PrestaShop already holds, bias it conservatively, show it where the buying decision happens, and then measure the hit rate and adjust. Do that and the delivery date stops being a guess on a product page and becomes one of the quieter reasons customers buy from you twice.