Delivery decisioning vs route optimization: what is the difference?

Route optimization sequences a vehicle’s stops. Delivery decisioning chooses which capacity carries each order at all, and keeps choosing as conditions change.

Delivery decisioning · the whole choice, order to doorstep

Who carries it

your van · contracted carrier · courier network · store associate · 3PL

How it moves

same day · scheduled · batched · parcel

When it leaves

this wave · a later wave · tomorrow

In what sequence

route optimization · the one step most operations have already bought

Read for every order · demand · network · reality · learning

The step that fit in a solver

Route optimization got automated first because its inputs fit. Addresses, time windows, vehicle capacity, a traffic estimate, a service time per stop. Give a solver those and it returns the best sequence for each vehicle, scored on distance and time. The math has been good for a decade (the solver is not the villain here), and the operator's complaint about it is rarely solver quality (the rules that break routes live in a planner's head, as a Nash engineer wrote about the gap between the plan and the road). The complaint is that the plan answered a narrower question than the one the operation has.

The optimizer assumes the set of orders it was handed is the right set. It cannot tell you that order 47 would have been cheaper and faster with a courier, because order 47 was never a candidate. It cannot tell you that the store meant to hand off order 112 is running forty minutes late, because the store's state was never an input. It sequences what it was given. Everything before that, which orders go to which capacity and whether that choice still holds as conditions change, stayed with a person.

The plan is perfect until it meets the road

Every order has a vehicle. Every vehicle has a sequence. The cost per stop is the lowest the solver could find. If the operation ran the way the plan assumed, this would be the end of the story.

The capacity the plan chooses from is wider than it was. In AlixPartners' 2026 Home Delivery Survey, more than 90% of logistics and supply chain executives at companies over $100 million in sales said they run a mix of last-mile carriers, and 32% use four or more. Every added option is another decision the plan froze.

Then the plan is wrong. A store opens late. A driver calls in. A customer moves their window. A courier network that was cheap when the plan was built is slammed now. None of this is a failure of the optimizer. The inputs changed, and the decision that chose the inputs was made once and frozen.

Most operations absorb this with people. A dispatcher watches the board, catches what they can, and the rest becomes a late delivery and a support ticket. The best dispatchers carry a second plan in their heads: which courier holds up under load, which carrier contract has slack, which store can be trusted to stage on time. Ask them how they decide and they say it depends. It does. The question is what it depends on, and whether any of that lives in software. Capturing that judgment as rules is the first job, and putting attention only where the plan broke is the second. Both depend on the decision being made somewhere other than a dispatcher's head.

What the full decision is made against

A decision is only as good as the context it is made against. The optimizer decides against a thin slice: what customers ordered and a guess at traffic. The full decision about an order needs four kinds of signal.

Lay the two side by side and the subset is plain. Route optimization reads Demand and a little Reality. Delivery decisioning reads all four, for every order, and reads them again when any of them move. The dispatcher's second plan is the Network and Learning signals that were never written down. Nash calls this shared picture the Context Fabric, and it is the reason the rest of the decision can live in software at all.

Why the order of operations matters

Decide capacity first, then sequence. An order that belongs with a courier should never reach the fleet's optimizer, and an order that belongs on a van should be sequenced with the day's other van orders rather than shipped at parcel rates because the fleet looked full when the plan was built. When the capacity decision is made once a day by rule (everything in zone A to our drivers, overflow to a courier), the optimizer spends its effort polishing a plan built on stale assignments.

Remake the decision continuously and the sequencing step gets better inputs. The courier that was cheap when the plan was built and is slammed now loses the next wave. The store running late loses its hand-offs to a nearby store or a later wave. The van that freed up when a customer cancelled picks up the order that was about to go out at a premium. Each of those is a decisioning change, and each one hands the optimizer a cleaner problem.

The cost shows up in the places the optimizer never measured: the premium courier fee on an order a van could have carried, the failed attempt because the window was never checked against the carrier's cutoff, the support call that followed. In the same AlixPartners survey, reliability edged past cost as the reason executives choose a primary carrier. Both show up as cost problems and are decisioning problems underneath, which is why cost to serve moves when the decision changes and cost per stop does not.

What it looks like on a dispatch floor

A regional grocer runs its own drivers from twelve stores, with two courier networks for overflow and a 3PL for the long tail. The plan is clean. Then one store reports its pick queue has backed up. Under a frozen decision, its forty orders go out late on the vans that were waiting for them, and a dispatcher starts phoning. Under a decision that is still being made, the orders that can be picked by a neighboring store move there, the ones with wide windows shift to a later wave, and the handful with tight promises go to a courier at a cost the system has already compared against the late-delivery credit. The vans are re-sequenced around what is left. The dispatcher sees the change proposed, with the reasoning, and approves it or doesn't. (The economics of that grocer keeping the order on its own storefront are on the grocery page.)

None of that is a better route. It is a better decision about which route each order belonged on, made against the state of the store, the carrier, the promise and the price, when the store fell behind rather than when the plan was built.

Keep the optimizer

The question that comes up most on calls is whether a decisioning layer replaces the routing tool or the TMS. Neither one goes anywhere: the optimizer keeps sequencing stops, the TMS keeps its records and becomes a source of Network signal, and the new layer sits above both, deciding which capacity each order reaches and revisiting that choice as conditions move. Orchestrate is that layer. It makes the decision per order across your own fleet, contracted carriers and a network of more than 250 delivery providers, then carries it through execution and proof of delivery, while Planning does the sequencing on cleaner inputs. One Platform shows how the Context Fabric sits under both, and the autonomic era is the longer argument for why the decision has to keep being made.

Route optimization decides the order of a vehicle’s stops. Delivery decisioning decides which capacity carries each order, and keeps deciding as the day changes.

Delivery decisioning: common questions