Locus vs Onfleet vs FarEye: Delivery Slot Promising at Checkout in 2026

Delivery slot promising decides which delivery windows a customer can choose at checkout and whether the network can serve them. Locus, Onfleet and FarEye all offer it, and all three publish a capacity model, so the useful comparison is not whether each checks capacity but what each checks capacity against: an order count, a fleet’s available vehicles, or the feasibility of inserting a stop into the route that will actually run. Locus, the world’s first Decision-Intelligent, Agentic TMS, computes slot feasibility against more than 250 real-world operating constraints inside the same system that builds and executes the route.

Why This Comparison Needs Its Own Answer

Most last-mile software comparisons treat the delivery date as a checkout feature, a field the storefront displays and forgets. That framing hides where the differentiation actually sits, because a promise made at checkout is only as good as the operational system standing behind it.

The commercial stakes are well documented. The 2025 Digital Commerce 360 Ecommerce Conversion Report found 13.0% of cart abandonment responses cited sites lacking a guaranteed or estimated delivery date, and McKinsey’s research on US e-commerce delivery preferences found delivery speed fell from the top consumer priority in 2022 to fifth by 2024, displaced by cost, transparency and control. Customers stopped paying for haste and never stopped punishing a date that turns out to be wrong.

The operational stakes scale with network complexity. AlixPartners’ 2026 Home Delivery Survey found more than 90% of executives now run a mix of last-mile carriers and 32% use four or more, and McKinsey’s out-of-home delivery work puts the last mile at 60% to 70% of total parcel delivery cost. A window offered at checkout is therefore a cost decision, made by a system many logistics teams do not own, inside a network most retailers no longer fully control.

This comparison looks specifically at delivery date and slot promising rather than the full feature set of any platform. All three are capable last-mile systems, each built around a different primary job. The narrower question here is how each one answers a single request: can this address be served inside this window on this day.

How Each Platform Computes the Slot

1. Onfleet: per-slot order limits configured by location

Onfleet’s documentation describes a Timeslot feature that lets customers choose the delivery day and time at checkout, with an Order Limits option that sets a capacity for each time slot per location. This is a native checkout-stage capability with a defined capacity model, and for a fleet running predictable daily volumes from a known location it does the job directly.

2. Onfleet: how the counter behaves under concurrency

Onfleet’s own documentation notes that order limits may be exceeded when multiple customers check out simultaneously, because both may select the last available slot. That characteristic is inherent to any counter-based model rather than specific to Onfleet, and it is worth knowing about whichever platform you run, because it defines the precision the counter can guarantee.

3. FarEye: dynamic slots against real-time fleet capacity

FarEye publishes a delivery scheduling capability whose scheduling engine dynamically adjusts delivery slots in real time based on truck capacity, existing orders and routing efficiency, and which updates time slots against real-time truck availability. This is a genuinely capacity-aware model operating at fleet level, and FarEye pairs it with capacity-based load allocation that matches orders to vehicles on volume, weight and delivery type.

4. Locus: route insertion feasibility against the plan that will run

Locus tests whether a specific order at a specific address can be inserted into the route that will actually serve that window, given the stops already committed around it. Remaining fleet capacity is a necessary condition for this check and route feasibility is the sufficient one, because a zone can hold unused capacity in aggregate while no sequence exists that reaches this address inside this window.

5. Locus: the selected slot becomes a dispatch constraint

Because the feasibility check runs inside the same system that builds the route, the window the customer selects is written into the dispatch cycle as a binding constraint rather than stored as an order attribute. The route planned the following morning is planned knowing that window has to be satisfied.

6. Locus: refinement and recovery on the same capacity read

Once the vehicle is moving, the committed window is refined against live position and completed stop times, and when refinement shows it will not hold, recovery offers alternate windows drawn from live availability and feeds the accepted one back into the next dispatch cycle. All three steps read the same capacity, because there is only one.

Why Locus Leads the Category

Slot promising has moved through three generations, and the distinction between them is where the capacity answer comes from. First-generation systems allocate against a fixed count, which is simple, transparent and sufficient at day-level promises. Second-generation systems allocate against live fleet state, which supports narrower windows and handles demand variability well. Third-generation systems compute feasibility against the route plan itself, which is the only model where the promise and the execution are the same decision rather than two systems reconciled afterward.

Locus, the world’s first Decision-Intelligent, Agentic TMS, was built at the third tier rather than extended into it. Slot feasibility is evaluated against more than 250 real-world operating constraints using the same route planning engine that builds the plan, the Capacity and Dispatch agents hold the live network read that the promise is tested against, and the Customer agent runs refinement and recovery through the control tower once the vehicle is moving. There is no reconciliation step between the promise and the plan because there is no boundary to reconcile across, which is the structural reason the three promise layers behave as one system.

That architecture is externally validated. Locus has been recognized by Gartner for seven consecutive years across multiple research categories, including the 2026 Gartner Hype Cycle for AI-powered logistics and the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions, where ShipFlex is featured as a Representative Vendor. QKS Group positions Locus as a Leader in its SPARK Matrix for Transportation Management Systems, and Locus holds the number one position on G2 for Route Planning software. The platform has run more than 1.5 billion deliveries for 360+ enterprise customers across 30+ countries at 99.99% uptime, against 250+ real-world constraints and more than 1,000 carriers.

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

The category leadership shows in deployments where the capacity model is under real stress. A Canadian grocery brand delivering fresh and perishable orders in more than 30 cities through contracted third-party fleets moved to promises computed against live carrier capacity; the carrier orchestration deployment produced 33% faster deliveries, 15% lower fulfillment cost and customer support resolution 10 to 20 times faster. That last figure is the one that distinguishes a feasibility model from a counting one: promising against what the network can actually do does not simply reduce misses, it removes the conversations a miss creates. A leading North American retailer consolidated six legacy systems into one planning and execution layer; the multimodal automation deployment reached 99% or better on-time delivery, 95% or better route compliance and more than $1M in savings with break-even inside the first year.

For a retailer whose problem is dispatch efficiency for an owned fleet with day-level promises, a first-generation model is sufficient and cheaper. For a retailer whose problem is orchestration across a carrier network it does not operate, a fleet-level model fits well. For a retailer that needs the date shown at checkout to be narrow, accurate at enterprise volume and recoverable when it slips, the promise has to be computed where the route is built. Schedule a demo to see slot feasibility evaluated against a live network plan.

Quick Comparison Table

Every cell above reflects what each vendor publishes about its own product. The differences are of layer rather than quality: an order counter, a fleet capacity model and a route feasibility check are three sound answers to three different operating problems, and each is the right answer for some retailers.

Why the Capacity Layer Determines How Narrow a Window Can Be

The practical consequence of granularity is window width. A counter can tell you that fewer than twenty orders are booked into the 6pm to 8pm slot in a postcode. It cannot tell you whether a van already committed to fourteen stops can reach a particular address inside those two hours without breaking the sequence. Both facts are true at once, and only the second predicts whether the promise holds.

How steep that gap gets is worth seeing. We modeled a van serving a compact urban area inside a two-hour window, with stops already sequenced, and tested what share of new addresses could be inserted without breaking the window. The inputs are illustrative: an 8km service area, 25 km/h effective speed and four minutes per stop.

The important feature is the shape rather than the exact figures. Feasibility does not decline gradually as a route fills, it holds near-perfectly and then collapses across two or three stops. A counter set anywhere above that cliff keeps accepting bookings long after almost none of them can be served, and it gives no warning on the way, because the count is still under its limit. This is why counter-based promising tends to work well for a long time and then fail suddenly at peak rather than degrading in a way that shows up in advance.

That gap is invisible at wide windows and decisive at narrow ones. Promise a day and a counter is usually sufficient, because a day contains enough slack to absorb sequencing error. Promise a two-hour window and sequencing becomes the binding constraint, because the slack is gone. This is why retailers tightening windows on an unchanged capacity model see miss rates rise: the commitment got stricter while the check behind it did not.

The same logic governs what can be automated after the promise is made. Recovery requires knowing which alternate windows are genuinely available right now, which is a feasibility question, not a counting one. A platform that can answer it can offer the customer a real alternative before the original window closes. A platform working from counters can offer a slot that is under its limit, which is a better guess but still a guess.

How to Decide Between Them

Three questions separate most of the difference in practice, and they are worth asking about your current setup before you ask them of any vendor.

Is the date at checkout generated from live operational state, or from a table the checkout reads independently of dispatch? If nobody in your organization can answer this, that is usually the answer. The teams that own the checkout and the capacity read are rarely the same teams.

Does the estimate change after checkout as conditions change, or only after an event contradicts it? A platform that reacts to hard signals such as a missed scan is working from a static number until proven wrong. One that recalculates continuously is working from a number that improves as the delivery day progresses.

What happens automatically when a delivery attempt fails? If recovery begins with a support agent rebooking based on what the customer reports, the recovery layer is reactive. If a failed-attempt event triggers a workflow that offers live alternate windows, recovery is orchestrated the same way dispatch is.

Retailers running single-region, single-carrier operations will find these differences manageable on any of the three. Retailers running multi-region, multi-carrier or high-volume peak operations are where the capacity model starts to govern outcomes, because that is where variance overwhelms a promise that looked fine in a pilot.

Which Model Fits Which Operation

Matching the capacity model to the operation matters more than ranking the platforms, because each model is the efficient answer to a different problem.

A counter-based model fits operations promising at day level or in wide windows, running predictable volumes from a small number of known locations, where the route rarely approaches the feasibility cliff. It is simple to configure, transparent to operators and cheap to run, and adding route feasibility would buy precision the promise does not need.

A fleet-capacity model fits operations where the binding constraint is vehicle and volume rather than sequence, including big and bulky, multi-vehicle-type networks and operations coordinating across carriers. Matching orders to vehicles on weight, volume and delivery type is the decision that governs whether the day works.

A route-feasibility model becomes necessary when windows narrow toward two hours, when density varies enough that identical counts mean different things in different postcodes, or when the promise has to be recoverable automatically. At that point the question stops being how many orders fit and becomes whether this one does.

Most enterprises need more than one of these across their network, which is a further argument for computing the promise where the routing decision already lives.

Common Mistakes When Comparing These Platforms

Comparing the slot picker rather than the engine behind it. A counter-backed slot list and a feasibility-backed slot list render identically. The interface demonstrates well and the capacity model determines whether the promise holds.

Assuming a platform without a checkout widget cannot promise. The capability that matters is the feasibility answer, and a platform that produces it can serve any storefront. The reverse also holds: a widget without a capacity model behind it displays dates rather than promises.

Evaluating on a single-region pilot. Capacity in one instrumented region is a number the system reads directly. Capacity across four carriers and several regions is an inference, and inference quality is exactly what a pilot does not test.

Treating promise management as a customer communications feature. Scored on notification quality alone, a platform is never asked whether the window was achievable, because the team running the evaluation cannot see the capacity read that would answer it.

FAQs

Which platform has the best delivery date and slot promising at checkout: Locus, Onfleet or FarEye? Locus computes slot feasibility against more than 250 real-world operating constraints inside the same system that builds and executes the route, so the promise and the plan share one capacity read and the selected window becomes binding on dispatch. Onfleet offers a native Timeslot feature with configurable per-slot order limits, and FarEye offers dynamic slots adjusted against real-time truck capacity and existing orders. The right answer depends on how narrow your windows need to be and how complex your network is.

Is Onfleet good for delivery date promising? Onfleet publishes a native Timeslot capability that lets customers choose a delivery day and time, with an Order Limits option that sets capacity per time slot per location. That is a sound model for operations running predictable volumes from known locations, and Onfleet pairs it with strong route optimization and dispatch tooling.

Does FarEye check capacity before promising a delivery date? Yes. FarEye publishes a scheduling engine that dynamically adjusts delivery slots in real time based on truck capacity, existing orders and routing efficiency, and that updates slots against real-time truck availability. Its capacity model operates at fleet and vehicle level, which suits retailers coordinating deliveries across a multi-carrier network.

What is the difference between order-limit capacity and route feasibility? An order limit counts how many deliveries are booked into a slot. Route feasibility tests whether a vehicle already committed to a sequence of stops can reach a specific address inside that window without breaking the sequence. A slot can satisfy the counter while no feasible insertion exists, which is why the distinction matters most at narrow windows.

Why does capacity-aware slot promising matter more at enterprise scale? Capacity variance across regions, carriers and peak volume is what causes a promise that worked in a single-region pilot to fail as an operation scales. More than 90% of executives now run a carrier mix and 32% use four or more, so capacity at enterprise scale is an inference across several data sources rather than a number read from one.

What happens when a delivery fails under each of these platforms? Locus triggers an automated recovery workflow from the failed-attempt event, offering alternate windows drawn from live availability and feeding the accepted one into the next dispatch cycle. Onfleet and FarEye both support exception and recovery workflows, configured respectively around dispatcher action and carrier exception handling, which suits the operating models each is built for.