How optimization works

Last updated: September 4, 2026

Optimization is how Nash turns a pile of loose orders into sequenced, dispatchable routes without you grouping them by hand. You hand the optimizer a set of orders plus the fleets and contracts available to carry them; it searches for the lowest-cost way to run the work without breaking any hard rule, and it hands back sequenced routes — which orders ride together, in what order, on which contract, and at what cost — for you to review and dispatch.

How routes work covers the route object itself — its stops and its editable-then-locked lifecycle. This page is about the part that isn't visible on the Routes tab: why an optimization comes out the way it does, and why two optimizations over similar orders can come back grouped, sequenced, or costed differently — because almost none of the settings that decide it live on the route.

Nash dispatches the route and hands it to a provider or your own fleet — Nash itself doesn't carry the delivery. Optimization decides how work is grouped and sequenced and what it should cost; the drive belongs to whoever runs the route.

How it works

An optimization has three inputs, which Nash reads all at once:

  • The orders — the demand. Each order carries where it's picked up and dropped off, when it can happen (its time window), how much it is (weight, volume, count), and any special requirement.
  • The fleet and contracts — the supply. Your own drivers, vehicles, and shifts, plus the provider contracts the run may use — each with its own capacity, cost, availability, and capabilities.
  • The strategy — the rules. What the routes must respect, what counts as "cheapest," and how work may cluster and sequence.

The optimizer takes all three and searches for the set of routes with the lowest total cost that breaks no hard rule, then returns them sequenced. Nash offloads the actual solve to a dedicated optimization engine; what comes back is a set of draft routes on the Routes tab, exactly like the ones you'd build by hand — orders grouped into runs, each run's stops in order, each route costed and assigned to a contract.

Optimization never dispatches anything on its own by virtue of being optimization. It produces reviewable drafts and leaves the send decision to you — unless a strategy has auto-dispatch after optimization turned on, in which case the routes it builds go straight out.

What the optimizer is solving for

"Lowest total cost" isn't a single number you set — it's assembled from a cost model the strategy carries, and it's what makes the optimizer prefer one grouping over another. The pieces that add up to a route's cost:

  • A fixed cost per vehicle used. This is the lever that decides fleet size — how many routes you get. A high fixed cost pushes the optimizer to pack orders into fewer, fuller routes; a low one lets it spread work across more.
  • Cost per unit of time and distance. Longer, slower routes cost more, so the optimizer favors tight, efficient sequences.
  • Penalties for crossing a threshold. Going past a route's allowed time or distance is penalized rather than flatly forbidden, so the optimizer will stretch a route only when it's worth it.
  • A penalty for leaving an order unserved. Every order the optimizer can't place carries a cost too — which is what makes it try hard to fit every order, and what it weighs against the expense of adding another route.

Change the cost model and the same orders come back grouped differently. That's why fleet size, route length, and how aggressively work packs together are all downstream of numbers set on the strategy, not on any route.

The rules it can and can't break

Some inputs are hard constraints — a route that violates one is simply invalid, and the optimizer won't build it:

  • Capacity — a route can't hold more than its vehicle's weight, volume, or count limit.
  • Time windows — a stop has to be served inside the window the order allows.
  • Route limits — maximum stops, distance, and on-road time per route.
  • Driver hours and breaks — routes stay inside a shift and honor required rest.
  • Where work can go — zones and route restrictions keep routes inside serviceable areas and out of no-go ones.
  • Capabilities — an order that needs a specific vehicle type or skill only goes on a route that has it.

Others are soft — preferences the optimizer honors when it can and pays a cost to break when it must (for example, treating a cluster grouping as a suggestion rather than a hard partition). Soft rules let a strategy nudge the shape of a result without making it infeasible.

Note

Most of what surprises operators about an optimized result traces back to a hard constraint doing exactly its job — a tight time window that forced two nearby orders onto different routes, or a capacity limit that split a run. The route looks odd; the constraint behind it is working as intended.

How stops get sequenced

Grouping orders into a route is only half the job — the optimizer also decides the order the stops are visited in. It sequences each route to keep travel short while landing every stop inside its time window, and it budgets the on-site service time each stop takes — reaching the door, handing off, collecting a signature — into the schedule, so the plan reflects real arrival times, not just drive time. A pickup always comes before its own drop-off.

Because travel times depend on the road network and traffic, the same set of stops can sequence differently under different assumptions: the traffic data source a run plans against feeds the drive times the optimizer sequences on. So two runs over identical stops can hand back different orderings when the traffic picture behind them differs.

When an order can't be placed

If no feasible route can hold an order — nothing has the capacity, the capability, or the hours to serve it inside its window — the optimizer leaves it unassigned rather than force an invalid route. That's a feature: it would rather hand back a clean plan plus a short list of what didn't fit than quietly break a rule.

What happens to those unassigned orders is something the strategy decides. A strategy can name an unassigned-orders fallback — a dispatch strategy that takes the leftovers and sends them individually, so an order that couldn't be routed still gets dispatched. Without one, unassigned orders stay in your Ready-to-Dispatch pile for you to handle.

Tip

If an order keeps landing unassigned, the cause is almost always a hard constraint it can't satisfy — a window no shift covers, a requirement no vehicle has, or a location outside every zone. Check those before the strategy itself.

The two ways it runs

Both paths feed the same optimizer and produce the same kind of result — draft routes you review and dispatch. They differ in who starts the run.

By hand. Use the Optimize action on your Ready-to-Dispatch orders. You choose the scope, optionally pick a saved strategy as the template or set the run's options inline, and Nash builds the routes for you to save. This is the everyday path; the steps live in optimize orders into routes.

On a schedule. An optimization strategy can run itself on a schedule, so the gather-orders-then-optimize step happens without you. A schedule is a set of days and a cadence (a fixed clock time, or "every so often"). Layered on top, Smart Frequency tightens that cadence as a delivery cutoff approaches — optimizing less often when the cutoff is far out and more often as it nears, so early plans stay cheap to compute and late ones stay fresh. There's no "run now" button and no workflow that applies an optimization strategy — a scheduled strategy runs itself.

How a strategy is built and scheduled — schedules, Smart Frequency, the contracts and locations it draws from — is covered in how optimization strategies work; this page is about what the optimizer does with it.

Note

Scheduled optimization and some of the settings that feed it are available depending on your organization's setup. If you don't see them, they may not be turned on for your organization — reach out to Nash.

What you get back

The result is always the same shape: draft routes on the Routes tab. Each route names the orders that ride together, the order of their stops, the contract or fleet it's built for, and the cost the optimizer solved to — alongside any orders it left unassigned. From there you review, edit, and dispatch them like any route you'd build yourself; a routed order dispatches through its route, which is why it can appear both in Ready to Dispatch and on the Routes tab (see how routes work).

Two optimizations over the same orders can differ because the search itself has a quality-versus-speed dial: a lighter search returns fast but may miss a better plan; a harder search spends more time to find one. Combined with the cost model, the constraints, and the traffic data the run planned against, that's why a re-run can reshuffle routes even when the orders didn't change.

What affects this

Every input below changes what the optimizer can build or how it scores the options, and each is set somewhere other than the route itself. Their existence and location are firm; exactly how strongly each drives a given result is operational, so read the last column as "what this generally contributes."

Input Where it's set What it does here
Optimization strategy Orchestrate ▸ Optimization Strategies — optimization strategies The primary shaper. Sets the cost model that defines "cheapest," the constraints a route must respect, the batching and sequencing rules, and which contracts and fleets are in play. Every field it can set is listed in the optimization parameters reference.
Manual run options Orders ▸ Routes — optimize orders into routes The scope and settings you choose when you run Optimize by hand — constraining this one run without changing the strategy.
Driver groups Fleet ▸ Driver Groups — manage driver groups Bound which of your drivers, and how much capacity, a route can draw from when the work runs on your own fleet.
Vehicles & capacity Fleet ▸ Vehicles — manage vehicles Set the vehicles available and their capacity and type — the capacity and capability limits the optimizer must respect.
Shifts Fleet ▸ Shifts — manage shifts Define when your own fleet is available, bounding a route to the window a driver actually works.
Zones & contracts Control ▸ Zones and Control ▸ Providers — manage zones, manage providers Zones constrain where and how orders may group; contracts are the carriers the optimizer weighs and picks among, with lowest cost as the tie-breaker.

Change any one of these and the same pile of orders can come back as a different set of routes — which is exactly why, when an optimized result surprises you, the explanation almost always lives one layer out in the configuration behind it, not on the route the optimizer handed back.

Related