Seven Things to Know About Locus Delivery Promise Management in 2026

Delivery Promise Management is a Locus capability that connects checkout to a retailer’s live logistics data, so a delivery window is offered to a customer only after every leg behind it has been checked as feasible. It verifies the cutoff at the origin warehouse, the linehaul feeding the delivery station and the vehicle’s route at the door, and returns an answer in under a second. That is a different design from the common approach of showing a window computed from historical averages and discovering afterwards whether the network can serve it. Locus launched it for implementation planning ahead of peak season 2026, and the seven points below cover what it does, what the testing showed and where it fits.

Why Promise Feasibility Matters: The Business Case

The commercial stakes sit with the customer’s perception rather than with the operations report. Locus cites research that 93% of shoppers say delivery performance affects brand perception, and that 51% of US shoppers expect holiday shipping to be as fast or faster than normal. Those two together describe a season in which expectations do not relax and judgement is harsher.

The gap being addressed is one of credibility. In the launch Q&A with Locus Chief Product Officer Pradyumna Chowdhary, the starting observation is that fewer than one in ten US consumers believe retailers always meet their delivery commitments. A promise shown at checkout is the most consequential number in the transaction and the least verified one.

The cost exposure compounds it. With last mile running 60% to 70% of total parcel delivery cost by McKinsey’s estimate, a window sold that the network cannot serve produces recovery activity in the most expensive leg, on top of the support contact and the reputational effect the research above describes.

Peak concentrates all of it. Adobe recorded a record $257.8 billion spent online across the 2025 holiday season, with Cyber Week alone at $44.2 billion, and NRF put total holiday sales above $1 trillion for the first time. Demand of that size does not arrive evenly, and the days when a promise is hardest to keep are precisely the days when the most customers are being given one.

That concentration is why the decision point matters more than the accuracy of any single estimate. On an ordinary week a generous promise is usually survivable because slack absorbs it. In the weeks that carry a disproportionate share of annual revenue, the same generosity becomes a commitment the network was never able to meet, made to more customers than at any other point in the year.

Seven Things to Know

1. It is called Delivery Promise Management, and it sells slots rather than forecasts them

The product name is Delivery Promise Management. The product page states the design intent in one line: sell only the delivery slots you can serve. The distinction from ETA prediction matters. A predictive ETA estimates when something will arrive. This decides whether a window should be offered at all, which is a capacity question asked before the sale rather than a forecasting question asked after it.

The two also fail differently, which is the clearest way to tell them apart in an evaluation. A predictive ETA fails by being wrong, and the fix is a better model. A promise fails by having been unkeepable from the moment it was made, and no model improves that, because the constraint was capacity rather than knowledge.

2. It checks every leg, back to the first mile

The capability checks the full chain behind a slot: the cutoff at the origin warehouse, the linehaul feeding the delivery station, and the vehicle’s route at the door. A window reaches checkout only when every leg clears. Most slot logic checks the final route alone, which is why a slot can be routable and still unservable because the order will miss a cutoff two legs upstream.

The practical consequence is where availability problems get diagnosed. An operation checking only the route sees a delivery failure and investigates the route, because that is the only leg it has visibility into at the point the promise was made. If the binding constraint was a warehouse cutoff, the route investigation finds nothing wrong and the same failure recurs. Checking back to the first mile means the constraint is identified where it actually sits rather than where the symptom appeared.

3. A booked window stays booked

This is the property that separates a feasibility check from a guarantee. Plans change during the day, and a system that validates at the moment of sale but not afterwards will quietly break commitments during re-planning. In Locus testing, 100% of re-planning passes maintained previously committed windows. The commitment is treated as a constraint on subsequent plans rather than as an output of the first one.

It is worth being precise about why this is the harder half of the problem. Checking feasibility once is a query. Holding the answer through every subsequent re-plan is a constraint, and constraints reduce the solution space available to the optimizer. A system that treats committed windows as suggestions will always produce a marginally cheaper plan than one that treats them as binding, which is exactly why the cheaper behavior is the common one and why the resulting broken promises are attributed to operations rather than to the planning rule that caused them.

4. The testing was run against a real order book, not a sample

Locus tested it against a full week of a retailer’s order book rather than a synthetic set. Across that week, 98.5% of orders received keepable delivery windows. Testing against real order composition matters because slot feasibility fails on the awkward orders, and a sampled test tends to dilute exactly those.

A full week also captures the shape of demand rather than its average. Order books are not uniform across days, and the orders that arrive on the busiest afternoon are the ones most likely to find every nearby slot already committed. A test run against a representative sample of orders would have included those cases in proportion, but a test run against a full consecutive week encounters them in sequence, with each day’s commitments constraining the next. That sequencing is the part a sample cannot reproduce.

5. It produced more sellable slots from the same fleet

Orders arriving at checkout with no available slot fell from 3.6% to 1.5%, a 58% reduction, without adding vehicles. That is the commercially interesting number, because the intuitive assumption is that checking feasibility more strictly must reduce what you can sell. Checking it properly did the opposite: fewer slots were refused because the system could identify the ones that genuinely worked rather than applying a conservative blanket rule.

The mechanism is worth understanding because it generalizes. A rule written without live capacity has to be safe across every condition it might encounter, so it is calibrated for the worst plausible day and applied on all of them. A check run against live state is calibrated for the actual day. The difference between those two is recoverable capacity that was always present and never sellable, which is why the gain arrives without a vehicle being added.

For a retailer the two percentages translate directly into an order-level number. On a hundred thousand orders, the difference between 3.6% and 1.5% refusal is roughly 2,100 orders that previously found no window they could book at the moment of highest intent.

6. When the answer is no, it tells you why

A refusal carries a reason. That converts an unexplained gap in availability into a diagnosable constraint, which is what allows an operations team to decide whether the binding limit is a warehouse cutoff, a linehaul, vehicle capacity or a service-level rule. Availability problems are otherwise very hard to attribute, because the only visible symptom is an absent option on a page.

This also makes the capability a planning input rather than only a checkout control. A refusal reason aggregated across a week tells a network planner which constraint is costing the most sellable slots, which is a different and more useful question than how many orders were refused. The constraint that binds most often is rarely the one an operations team would have nominated, and it changes by depot and by season, so it is worth measuring rather than assuming. That diagnosis belongs alongside the rest of the live operations view rather than in a separate report.

7. It fits the stack you already run

Chowdhary describes the system as designed to work with existing systems rather than replace them, using APIs to connect checkout with data retailers already hold. It supports exact appointment scheduling for white-glove, high-value and big-and-bulky deliveries, broader date-only windows for standard e-commerce, tiered pricing for premium service levels and consolidated or lower-impact options, across owned fleets, third-party carriers and hybrid networks. Speed is part of the integration requirement rather than a benchmark: feasible slots return in under a second, because a checkout page cannot wait longer than that.

The service-level range matters more than it first appears, because a single retailer usually needs several at once. A two-person sofa delivery and a parcel of shoes are not the same promise, and an operation that can only express one kind of window ends up applying big-and-bulky caution to parcel orders or parcel optimism to appointment orders. Being able to offer an exact appointment on one order and a date-only window on the next, from the same capacity check, is what allows the promise to match the product rather than the lowest common denominator of the catalog.

Historical-Average Promising vs Capacity-Checked Promising

The last two rows are the ones that change the commercial argument. Conservative promising protects the operation by making the offer worse for every customer, including the large majority whose order was always servable. Checking the specific slot lets the operation be strict where it needs to be and generous everywhere else.

The behavior-during-re-planning row is the one to test in an evaluation, because it is the least visible and the most consequential. Any vendor can demonstrate a feasibility check at the moment of sale. The question worth asking is what the system does at two in the afternoon when volume has shifted and the cheapest available plan would break a window committed that morning. A platform that cannot answer that has validated the promise rather than protected it.

Where It Fits: Real-World Context

The tested results are the primary evidence. Against a full week of a retailer’s order book, 98.5% of orders received keepable windows, slot refusals fell from 3.6% to 1.5%, every re-planning pass held previously committed windows, and responses returned in under a second. Those four are worth reading together rather than separately: high coverage with no re-planning breakage is a materially different claim from high coverage alone.

A leading North American retailer across multiple hundred stores provides the execution-side context for why this is possible. Consolidating six legacy systems onto Locus produced $1M+ in savings with exceptions resolved in under two hours, alongside 99%+ on-time delivery and 95%+ route compliance. A promise can only be checked against a network whose state is held in one place, which is why promise feasibility is a property of the execution layer rather than a checkout feature.

The timing is deliberate. Locus made the capability available for implementation planning ahead of peak season 2026. As Founder and CETO Nishith Rastogi framed it in the launch, peak season is no longer just about moving products quickly, and retailers are being judged on whether they can deliver the experience they promise.

The word to notice in that availability statement is planning. A promise capability has to be connected to order systems, hub cutoffs, fleet capacity and carrier availability before it can check anything, and that integration work sits on a calendar rather than a switch. An operation that decides in November has decided for the following year, because the weeks when the capability is worth the most are the weeks when nobody is integrating anything.

Common Mistakes in Delivery Promise Programs

Treating promise accuracy as an ETA problem. A better arrival estimate improves what you tell a customer after the sale. It does not change whether the window should have been offered, which is a capacity decision taken earlier.

Validating at checkout and never again. A window checked once and then left out of subsequent planning will be broken by ordinary re-planning, and the customer will experience that as a broken promise rather than as an operational event.

Widening windows to protect on-time rate. Widening is the blunt instrument that improves the metric by degrading the offer for everyone. It also hands a competitive advantage to any retailer willing to check the specific slot instead.

Checking only the final route. Most slot logic asks whether a vehicle can reach the address in the window. The constraint that actually binds is frequently a warehouse cutoff or a linehaul upstream of the route being checked.

How Delivery Promise Management Fits the Locus Platform

Locus, the world’s first Decision-Intelligent, Agentic TMS, treats the promise as a commitment the rest of the platform is obliged to honor rather than as a message sent at checkout. Because the same decision layer holds order state, hub cutoffs, linehaul, fleet capacity and carrier availability, a slot can be tested against all of them in one pass, and the committed window then becomes a constraint that subsequent planning must respect. That is why the re-planning result matters more than the coverage result: it is evidence that the commitment is structural rather than advisory.

The platform reasons across more than 250 real-world operating constraints over 1.5B+ deliveries for 360+ enterprise customers in 30+ countries at 99.99% uptime, with $320M+ in aggregate logistics cost savings. Locus has been recognized by Gartner for seven consecutive years, including the 2026 Gartner Hype Cycle for Supply Chain Execution and Logistics Technologies and the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions, where ShipFlex is featured as a Representative Vendor. Locus holds Leader designation in the QKS SPARK Matrix for Transportation Management Systems 2025 and the #1 position for Route Planning in G2’s 2026 Best Software Awards.

In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Delivery Promise Management is best understood as a change in where feasibility is decided. Instead of showing a window drawn from historical averages and finding out afterwards whether the network can serve it, every leg behind the slot is checked before the customer sees it, in under a second, and the resulting commitment constrains the plans that follow. Locus testing against a full week of a retailer’s order book returned keepable windows on 98.5% of orders, cut slot refusals by 58% without adding fleet, and held every previously committed window across re-planning. It connects by API to the systems a retailer already runs, across owned, carrier and hybrid networks. See Delivery Promise Management run against your own order book or request a Locus assessment ahead of peak season.

Frequently Asked Questions

What is Locus Delivery Promise Management?

It is a Locus capability that connects checkout to live logistics data so a delivery window is only offered once every leg behind it has been verified as feasible, covering the origin warehouse cutoff, the linehaul feeding the delivery station and the vehicle route at the door. Feasible slots are returned in under a second.

How is it different from a predictive ETA?

A predictive ETA estimates when an order will arrive, after the sale. Delivery Promise Management decides whether a window should be offered at all, before the sale, by checking capacity across every leg. One improves what you tell the customer; the other changes what you commit to.

What did the testing show?

Run against a full week of a retailer’s order book, 98.5% of orders received keepable delivery windows, orders with no available slot fell from 3.6% to 1.5%, a 58% reduction, and 100% of re-planning passes maintained previously committed windows.

Does stricter checking mean selling fewer slots?

The testing found the opposite. Refusals fell 58% without adding fleet, because checking the specific slot allows the system to identify the windows that genuinely work rather than applying a conservative rule across all of them.

Does it replace our existing systems?

No. Locus CPO Pradyumna Chowdhary describes it as designed to work with existing systems rather than replace them, connecting checkout by API to data retailers already hold, and operating across owned fleets, third-party carriers and hybrid networks.

When is it available?

Locus made it available for implementation planning ahead of peak season 2026. Because the value is concentrated in the period when capacity is tightest, the implementation runway matters more than the go-live date.