IN Brief:
- Delivery Promise Management checks capacity from the origin warehouse through linehaul and the final mile route before offering a slot.
- A historical retailer test produced feasible windows for 98.5% of orders and reduced orders without slots by 58%.
- The capability connects through APIs with existing inventory, fulfilment, carrier, and capacity-planning systems.
Locus has launched Delivery Promise Management, a capacity-aware planning capability that checks whether delivery windows can be supported by the logistics network before those slots are offered at checkout.
The system works backwards from the requested window, checking the final mile vehicle and route, the linehaul feeding the delivery station, and the cut-off at the origin warehouse. Locus says feasible options are returned in under a second, allowing retailers to display dates and time windows according to current operating capacity rather than a fixed service calendar.
The capability supports exact appointment slots for white-glove and high-value deliveries, broader date windows for standard ecommerce orders, tiered pricing for premium services, and lower-impact delivery choices. It is designed for networks that combine owned fleets and third-party carriers, reflecting the fact that many retailers do not control every transport leg behind the promise shown to a customer.
In a test using one retailer’s full week of historical order data with fleet capacity deliberately constrained, Locus says the system found feasible delivery windows for 98.5% of orders. Live re-optimisation reduced the proportion left without a slot from 3.6% to 1.5%, a 58% reduction. The remaining orders were refused a window because the route was full, the cut-off had passed, or no fleet was rostered.
The figures come from vendor testing rather than independently audited live operations, but the test reproduces a familiar failure point in retail logistics. Checkout systems can make delivery promises from inventory, postcode, and service rules without knowing whether enough transport capacity remains. Dispatch teams then discover the constraint after the order has been accepted, turning a planning problem into a service exception.
Delivery Promise Management moves that capacity check further upstream. Once a slot has been committed, Locus says subsequent replanning has to preserve it before a revised route can go live. An optimisation run therefore cannot improve vehicle efficiency by quietly moving a delivery window that has already been sold to the customer.
The same logic can expose extra capacity created through replanning. If a route becomes more efficient and can absorb another stop without breaking existing commitments, the system can make that capacity available for another order rather than holding a conservative static limit for the entire day. Route optimisation then affects commercial availability directly instead of operating as a separate back-office process.
The technology connects through APIs to existing inventory, fulfilment, carrier, and capacity-planning systems rather than requiring a retailer to replace its operating stack. That matters because no single application normally holds all the information behind a delivery promise. The warehouse knows whether an order can leave before cut-off, transport planning knows route capacity, and carrier platforms hold service rules for outsourced legs.
Keeping those signals synchronised is more difficult than adding another slot selector to a website. Inventory readiness, linehaul departures, vehicle capacity, carrier acceptance, and local route conditions can all change after an order enters the system. A credible promise depends on each stage remaining feasible as the network replans around new demand and operating exceptions.
That makes data latency as important as optimisation logic. A capacity check based on an outdated route plan or a warehouse cut-off that has already moved can still produce the wrong answer quickly. The value of the approach therefore depends on how reliably connected systems update the delivery engine and how clearly exceptions are returned when one leg no longer supports the requested window.
Recent network-led fulfilment orchestration has applied a similar principle across collections, linehaul, and final mile activity, connecting stages that are often managed separately. Locus is applying that integration at the point where the commercial promise is made, using network capacity to decide what a customer can actually book.
Peak demand will provide a more demanding test than historical data. Warehouse delays, traffic, driver absence, carrier failures, and late order changes can occur together, while customers continue to expect the slot displayed at checkout to remain valid. Locus says its system flags orders that fall behind milestones so they can be prioritised before the promised window is lost.
The capability is available now for enterprise retailers planning peak operations. Its practical measure will be whether it can preserve committed windows while continuing to expose usable capacity as conditions change. If that balance holds in live networks, delivery availability becomes a continuously managed transport decision rather than a static promise created before the logistics operation has been consulted.
