How optimization works

Last updated: August 25, 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 and the contracts and fleets available to carry them; it searches for low-cost routes that still satisfy every constraint, 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. Nash offloads the actual solve to a dedicated optimization engine; what you get back is a set of draft routes on the Routes tab, exactly like the ones you'd build yourself.

This article is about the part that isn't visible on the Routes tab: why an optimization comes out the way it does. How routes work covers the route object itself — stops, the editable-then-locked lifecycle, and optimize-versus-group-by-hand. This is its richer sibling, focused on one question: which settings, spread across several corners of Nash, actually shape the routes an optimization produces. Almost none of them live on the Routes tab, which is exactly why two optimizations over similar orders can come out grouped, sequenced, or costed differently.

How it works

At a high level, an optimization has three moving parts: the orders you feed in, the strategy that tells the engine how to solve, and the fleet and network configuration that says what's actually available to carry the work. The engine takes all three, searches for the cheapest set of routes that breaks no hard rule, and returns them sequenced.

You start an optimization one of two ways. You can run it manually with the Optimize action on your Ready-to-Dispatch orders — you pick the scope, the engine runs, and you save the result as routes. Or an optimization scheduler can run a strategy for you on a schedule, so the gather-orders-then-optimize step happens on its own rather than by hand. Scheduled optimization is an org-dependent capability — availability varies, so if you want it, reach out to Nash about access. Either way the result is the same shape: draft routes on the Routes tab that you review, edit, and dispatch. Optimization never dispatches anything on its own by virtue of being optimization; it produces reviewable drafts and leaves the send decision to you.

What "cheapest route that breaks no rule" means isn't fixed — it's assembled from settings that live in several places. The strategy carries the engine's rules and cost model. Your fleet configuration says which drivers, vehicles, and shifts exist to be routed. Your network configuration says where orders may group and which contracts are in play. The optimizer reads all of it at once. So when an optimized result surprises you, the explanation almost always lives one layer out — in one of those settings — not on the route the optimizer handed back.

What shapes an optimization

Every input below changes what the optimizer can build or how it scores the options. Each is set somewhere other than the route itself, and each links out to its own home. The existence and location of each input is solid; the exact effect — how strongly it drives a given result — is operational and best confirmed against your own strategy, so read the effect column as "what this input generally contributes," not a hard rule.

Input Where it's set What it does here
Optimization strategy Automate ▸ Strategies — optimization strategies Selects the engine and the rules it solves against — which contracts and fleets it may use, the constraints a route must respect, the cost model that defines "cheapest," and the batching and sequencing rules. This is the primary shaper of a result. For the complete field-level list of everything a strategy can set, see the optimization parameters reference.
Manual run options Operate ▸ Orders ▸ Routes — optimize orders into routes The choices you make when you run Optimize by hand — which orders are in scope and how this particular run is constrained. Scopes and constrains this one run without changing the underlying strategy.
Driver groups Configure ▸ Fleet — manage driver groups Determine which drivers, and therefore how much capacity, a route can draw from when the work runs on your own fleet. Generally bounds who an optimized route can be built for.
Vehicles & capacity Configure ▸ Fleet — manage vehicles Bound the vehicles available to your own fleet and their capacity and type. These generally feed the capacity and capability constraints the optimizer has to respect — how many orders fit, and whether a route needs a particular kind of vehicle.
Shifts Configure ▸ Fleet — manage shifts Define when your own fleet is available to be routed. Generally bound an optimized route to the window a driver is actually working.
Zones & contracts Configure ▸ Network — manage zones, manage providers Zones generally constrain where and how orders group geographically; contracts (providers) are the carriers optimization weighs and picks among, choosing the most cost-effective way to run each route — with lowest cost as the tie-breaker. Together they help determine which fleets are in play and how the work clusters.

These inputs combine to determine which routes the optimizer builds: the strategy sets the rules and the cost yardstick, fleet configuration says what own-fleet capacity exists, and network configuration says where work may group and which contracts compete to carry it. Change any one of them and the same pile of orders can come back as a different set of routes.

Next steps

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