How optimization strategies work

An optimization strategy is a saved ruleset, not a one-time run. This article is about what's actually inside that ruleset — the pieces you configure once, and how they come together every time the strategy fires — and about the timing model that decides when it fires. For what an optimization strategy is and where you find it, start with optimization strategies. For how Nash actually turns a set of orders into sequenced routes — the solve itself, and the fleet and network settings that shape it — see how optimization works. This article stops short of the solve; it's about the object that kicks the solve off and tells it what to work with.

Note

Optimization strategies are available depending on your organization's setup. If you don't see them, reach out to Nash.

The model: a config bundle, and a run

Everything you set on a strategy falls into one of two buckets: things that scope and shape a run, and the timing that decides when a run happens. Scope and shape includes the contracts the run may use, any store locations it's restricted to, the pickup-time window of orders it pulls in, route restrictions it must avoid, and a set of service and route settings — service times, how routes balance across providers, and similar tuning covered field-by-field in the optimization parameters reference. None of that is the solve itself — it's the bundle of constraints and inputs the strategy hands off when it runs.

What comes back is sequenced draft routes: which orders ride together, in what order, ready for you to review on the Routes tab. The strategy doesn't dispatch by default and it doesn't decide how the solver arrives at that sequencing — that logic, and everything else that shapes an optimization's outcome (fleet capacity, zones, contracts), belongs to how optimization works. What the strategy controls is the bundle going in and a couple of options for what happens to the routes coming out.

Timing and cadence

The timing model is the part of a strategy that's genuinely its own — it doesn't exist anywhere else in Nash, because nothing else decides when optimization should happen on its own.

A strategy's schedule starts with a simple pattern: which days it runs (Everyday, Weekdays, Weekends, or a Custom set of days) and how often within those days — either a fixed cadence, like every 30 minutes, or a set clock time. You can also give a schedule an active date range, so it only applies starting on, or stopping on, a specific date rather than running indefinitely. A strategy can carry more than one schedule if different cadences make sense at different times.

On top of that base pattern sits Smart Frequency, a standard part of every strategy — there's nothing extra to turn on for it to be available. Smart Frequency layers a set of tiers on top of the base schedule, and each tier tightens how often the strategy runs as a delivery's cutoff gets closer. A tier says, in effect, "once we're within this many hours of the cutoff, run every this many minutes" — and as orders approach their cutoff, a tighter, more frequent tier takes over from the looser one that applied further out. Tiers are evaluated in order and the first one that matches wins; the last tier is an unbounded catch-all, so there's always a tier in effect once you've crossed into Smart Frequency territory, even if nothing more specific applies yet. You can also tell Smart Frequency not to start optimizing until a set number of minutes before the window even opens, so a strategy with a tight final tier doesn't also fire needlessly far in advance.

Put together, the base schedule sets the outer rhythm and Smart Frequency squeezes that rhythm tighter as urgency rises — a strategy might check in every hour through most of the day and then, as cutoffs start landing, switch to running every few minutes without you touching a setting.

A strategy only fires on this schedule while it's active; deactivating a strategy pauses its timing without discarding the configuration underneath it, exactly as covered in optimization strategies. A shift change on your own fleet can also trigger a reactive optimization outside this schedule — but the schedule and Smart Frequency are the timing you actually configure.

What scopes a run

When a strategy's schedule fires — or when you pick it as a starting point for a manual run — three things decide what that run actually looks at.

Contracts decide which fleets the solver is allowed to draw from: a run only ever considers vehicles reachable through a contract the strategy allows. Store locations, if the strategy has any attached, narrow the run further and change how it's carried out: a strategy scoped to one or more store locations runs its schedule separately per store location — and per shift, where relevant — rather than as one sweep across the whole organization. A strategy with no store locations attached runs organization-wide instead. The pickup-time window — a from/to range measured from each order's pickup time — is the last filter: only orders whose pickup time falls inside that window are pulled into the run at all. Narrow the window and a run considers fewer, more time-relevant orders; widen it and more of the order pool becomes eligible for this run to batch and sequence.

These three settings don't touch the solve's logic — they decide the input, not the reasoning. Which vehicle pools and drivers actually exist to be routed, and how the solver clusters and sequences what it's handed, is covered in how optimization works.

The two ways a strategy runs

A strategy runs one of two ways, and it's worth being precise about the contrast with dispatch strategies here: no workflow applies an optimization strategy. A dispatch strategy can be assigned to matching orders by a workflow action; an optimization strategy never is. It only ever runs itself.

• On its own schedule. Once a strategy is active, the timing model above runs it without anyone triggering it — the schedule and Smart Frequency are the whole mechanism.
• As a preset in a manual optimization. When you optimize a set of orders by hand, you can pick a saved strategy as your starting point instead of configuring a run from scratch. See optimize orders into routes for that workflow. Picking a strategy this way borrows its config bundle for this one run — it doesn't change the strategy's own schedule.

Either path produces the same shape of result: sequenced draft routes on the Routes tab, ready for you to review before anything ships.

Dispatch options

A strategy doesn't have to stop at producing draft routes — two settings decide what, if anything, happens next.

Auto-Dispatch after Optimization sends the routes a run produces straight to dispatch instead of leaving them for you to review first. Leave it off and every run's output waits on the Routes tab until you dispatch it yourself.

The Unassigned Orders Fallback Strategy covers the opposite case: orders a run couldn't fit onto any route at all. Rather than dropping those orders, the strategy hands them to a dispatch strategy you name — letting that fallback strategy dispatch them individually the normal way, outside of any route. This is the seam between the two objects: optimization decides how orders group into routes; when it can't group an order at all, dispatch takes over for that one order on its own.

What affects this

None of the following live on the strategy's timing settings, but each one changes what a run actually has to work with, or what happens after it finishes.

Input	Where it's set	Effect on a run
Contracts	The strategy	Which fleets and vehicle pools a run may draw from
Store locations and pickup-time window	The strategy	Which orders a run pulls in, and whether the schedule fans out per store location or runs organization-wide
Schedule and Smart Frequency	The strategy	When the strategy runs, and how tightly it tightens as cutoffs approach
Route restrictions	Their own surface, attached to the strategy — see route restrictions	Areas the run must avoid when building routes
Fleet and network configuration	Configure ▸ Fleet / Network — owned by how optimization works	Which drivers, vehicles, shifts, zones, and contracts actually exist for the solver to route work onto
Unassigned Orders Fallback Strategy	The strategy — see dispatch strategies	What happens to an order a run couldn't fit onto any route

Two strategies that look identically configured can still produce different routes if the contracts, fleet capacity, or zone coverage behind them have shifted — the strategy only controls what it gathers and when it runs; the solve itself is shaped by everything in that last row. Nash optimizes and dispatches; the provider or your own fleet performs the delivery.