“When will it arrive?” is the question that drives more post-purchase support tickets than almost anything else in e-commerce. Customers place an order, stare at their email for a shipping confirmation, and then call or chat to ask what’s taking so long. The information existed in the system all along — carrier lead times, warehouse processing schedules, transit windows — but it never made it to the one place where it would actually reduce anxiety: the checkout page.
Odoo has fixed that. The e-commerce module now calculates and displays expected delivery dates directly in the checkout flow, giving customers a concrete arrival window before they complete their purchase.
How the Calculation Works
The delivery estimate isn’t a static number someone typed into a settings field. It pulls from three data sources that already exist in Odoo’s logistics configuration.
First, the carrier lead time. Each shipping method in Odoo already has a defined delivery window — the number of days the carrier takes to move a package from the warehouse to the destination. That data now feeds directly into the checkout estimate.
Second, the warehouse working schedule. If your warehouse ships Monday through Friday and a customer orders on Saturday afternoon, the estimate accounts for the fact that processing won’t start until Monday. This prevents the classic frustration where a customer sees “3-day shipping” and expects Wednesday delivery on an order placed Saturday — only to receive it the following Friday.
Third, a configurable customer selection period. Businesses can optionally let customers choose from a range of additional working days beyond the base estimate. If your standard delivery takes five working days and you configure two additional selectable days, customers see a window rather than a fixed date — giving them flexibility to plan for the delivery while keeping expectations realistic.
The Configuration Is Surprisingly Minimal
The expected delivery date feature lives in the eCommerce tab of the shipping method configuration. There’s no separate module to install, no third-party integration to set up, and no JavaScript widget to inject into the storefront template.
You define the expected delivery period in working days, link it to your working schedule (the same schedule your warehouse operations already use), and optionally set how many additional days customers can add to their selection window. The checkout page picks it up automatically.
The estimate displays per shipping method. If a customer is choosing between standard and express shipping, each option shows its own expected arrival date. This turns the shipping selection from a price-only decision into a price-versus-speed decision, which is exactly how customers think about shipping in the first place.
Why This Matters More Than It Sounds
Delivery date transparency is one of those features that sounds incremental until you measure its impact. Research from every major e-commerce platform consistently shows that visible delivery estimates increase conversion rates — customers who know when something will arrive are meaningfully more likely to complete checkout than customers staring at a generic “standard shipping” label.
The reduction in support tickets is equally significant. When customers already know the expected arrival window, they don’t need to contact support two days after ordering to ask whether their package has shipped. The information is right there in their order confirmation, matching what they saw at checkout.
For businesses running Odoo’s e-commerce alongside its inventory and shipping modules, the integration is particularly clean. The delivery estimate isn’t a guess that someone has to manually keep in sync with operational reality. It’s calculated from the same carrier configurations and warehouse schedules that drive actual fulfillment. When you change your carrier’s lead time or adjust your warehouse hours, the checkout estimate updates automatically.
What It Doesn’t Do (Yet)
The current implementation calculates estimates from static lead times and working schedules. It doesn’t factor in real-time inventory availability — if an item is backordered, the estimate won’t automatically extend to reflect the restock delay. It also doesn’t pull live transit estimates from carrier APIs the way Amazon’s “arriving Tuesday” badges do.
Those are reasonable limitations for a first implementation. The working-schedule-aware calculation already handles the most common source of mismatched expectations (weekend and holiday processing delays), and the per-carrier display eliminates the guesswork from shipping method selection. Real-time carrier integration would be the logical next step, but what shipped today solves the problem that generates the most support tickets right now.