How delivery windows work

A delivery window is a bookable time slot a shopper picks at checkout — a Saturday 9:00–11:00 morning slot, a weekday evening slot — that commits your organization to getting that order delivered in that window. This article is about what a window actually is underneath that checkout choice: the five things every window carries, how many orders one can hold, how Nash decides which windows an order is even offered, and what happens to that promise once a shopper books it. For where you find and build windows in the portal, start with delivery windows overview; this page is the model behind those screens.

Note

This is a beta feature. Reach out to Nash if you'd like early access.

What a delivery window is

Every delivery window is a recurring slot anchored to a zone. Most organizations run windows per zone — the geographic area a store delivers to — so a single window like "Tuesday 2:00–4:00pm" isn't one slot floating on its own; it's a slot that belongs to a specific zone's weekly calendar and repeats forward from there. (A handful of setups anchor windows to a store location directly, but the shape is the same: a window belongs to somewhere, and it recurs.)

What makes a window more than a time range is the five levers it carries. Each one is something you set, and each one shapes whether — and to whom — the window is offered:

• Price — what the window costs the shopper, in your organization's currency. A window can be free or carry a premium; an express evening slot might cost more than a mid-week afternoon one.
• Cutoff — the book-by time. After a window's cutoff passes, it can no longer be booked, even if it otherwise has room. This is how you stop same-slot bookings arriving with no time to fulfil them.
• Minimum order value — the smallest order that qualifies for the window. An order under that floor isn't offered the window at all.
• Allow-tags — required tags an order must carry to be eligible. If a window carries allow-tags, an order has to bring all of them to qualify; it's an allow-list, not a preference.
• Capacity — the quota. A window can hold only so many orders, and this is the backbone of the whole object: it's the "how much you can take on" number. You set a window's maximum capacity, and once that many orders have booked it, the window is full and stops being offered — no matter how well an order meets every other condition.

Capacity is worth pausing on, because it's the lever that makes a window a real commitment rather than an open-ended offer. Price, cutoff, minimum, and tags all decide whether a given order qualifies. Capacity decides how many qualifying orders you'll actually accept into that slot. Set it to match what your fleet and your providers can genuinely deliver in that window, and the slot protects itself: it fills up to the number you can handle and then closes, so you're never promising more deliveries in a window than you can move.

Building windows

There are two ways windows get onto a zone's calendar, and they suit different jobs.

The first is by hand: you open a zone's weekly calendar and place a single window on it, filling in its time range and its five levers. This is the right tool for a one-off — a special slot for a holiday, an extra window to cover a busy Saturday.

The second is a template, and it's how most of a schedule actually gets built. A template describes a repeating slot — which days of the week it runs, what local time, its price, capacity, and minimum — and then generates the individual windows for the zones you attach it to. Two settings control how far that generation reaches: a cadence (how often it creates windows, for example every week) and a rolling horizon (how far ahead to keep the calendar filled, for example up to twelve weeks out). As time moves forward, the horizon rolls with it — Nash keeps generating new windows ahead of today so the calendar never runs dry.

That generation happens on Nash's side, on the schedule your template sets. There's no operator "recompute" or "regenerate" button to press — you define the template once, and the windows keep appearing on the rolling horizon without you doing anything further. For the field-by-field how-to on both paths, see schedule delivery windows with templates.

How a window gets offered

When an order needs a delivery window, Nash doesn't hand it the whole calendar — it works out which windows that specific order is actually eligible for, and offers only those. Every window has to clear the same set of checks:

• The order's dropoff falls in the zone's coverage. A window belongs to a zone; if the order is being delivered outside that zone's area, none of the zone's windows are in the running.
• The store-to-zone link is active for that date. The connection between a pickup store and a zone can itself be scheduled to be live only over certain dates. A window on a zone whose link to the store isn't active for the requested date won't be offered.
• The window has capacity left. If the slot has already filled to its maximum, it's full — it drops out of the offer.
• The order meets the minimum order value. An order below the window's floor doesn't qualify.
• The order carries the required allow-tags. If the window has allow-tags, the order has to bring all of them.
• The cutoff hasn't passed. A window whose book-by time is already behind us is closed to new bookings.

A window that clears every one of these is eligible and gets offered to the order. A window that misses even one sits out — and Nash can say why it sat out, in plain terms: not enough capacity remaining, minimum order value not met, the required tags weren't all present, or the cutoff time has passed. That last part matters when a window you expected to see isn't offered: the reason is almost always one of these checks, and each one names itself.

It's worth being precise about what this matching is and isn't. It decides which sellable slots an order can be promised into. It is not the same thing as your organization's operating hours — the store-hours and outside-hours dispatch behavior set under Settings ▸ Organization (set operating hours and dispatch behavior). Operating hours govern when dispatch runs relative to when your store is open; delivery windows govern which time slots a shopper can book. They're two separate controls, and it's easy to conflate them because both are about time — keep them distinct.

Booking consumes capacity

Eligibility is only the offer. The moment that turns a window from an option into a commitment is the booking: when a window is booked and confirmed for an order, it uses up one of that window's slots. Capacity is counted per date — per occurrence of the recurring window — so booking the Tuesday slot this week draws down this Tuesday's count, not next Tuesday's. Each recurrence of a repeating window carries its own capacity.

This is the loop that makes capacity self-enforcing. Windows are offered while they have room; each booking consumes a unit of that room; and when the bookings reach the maximum you set, the window stops being offered to further orders and the slot is full for that date. You never have to close a window by hand once it's full — the counting does it. Set a window's capacity to what you can truly deliver on, and it becomes a cap you can trust: the slot accepts exactly that many orders and no more.

Pricing and tag rules, at a glance

Beyond the fixed price you set on a window, Nash offers a separate engine that can raise or lower a window's price, or attach a tag to it, automatically as a calculated metric you're tracking crosses tiers you define — so a window can price up as it fills, for instance. This is a further capability layered on top of the model above, not part of the base window. It's covered on its own in delivery window pricing and tag rules, with every field defined in the delivery window rules reference — this page won't re-document it.

Note

Pricing and tag rules are a separate beta capability that appears for some organizations. Reach out to Nash if you'd like early access.

What affects this

A window doesn't decide anything on its own — what it's offered for, and what happens after it's booked, is shaped by objects set elsewhere. None of these live on the window itself.

Input	Where it's set	Effect on a delivery window
The window's five levers	The window itself (or the template that generated it)	Price, cutoff, minimum order value, allow-tags, and capacity — the conditions every order is checked against
Zone coverage	Configure ▸ Network ▸ Zones — see manage zones and define zone coverage	Whether an order's dropoff falls in the zone a window belongs to, deciding if the zone's windows are in the running at all
Templates	The Templates tab — see schedule delivery windows with templates	Generate the recurring windows across zones on a rolling horizon, stamping each one's levers
Pricing and tag rules	The Pricing Rules / Tag Rules tabs — see delivery window pricing and tag rules	Adjust a window's price or attach a tag dynamically as a metric crosses tiers you set — a separate, further-gated capability
A window's Requirements	The window dialog (a gated field)	Restricts a window to deliveries that meet requirements you've configured — a beta field that appears for some organizations
Order attributes	The order itself	Its dropoff, value, and tags feed directly into which windows it's eligible for

Two windows that look identically configured can still be offered differently if the zones, store links, or bookings behind them differ — a window that's full for one date is wide open for the next.

The last thing to carry out of all this is what a booked window actually is. It's a promise to the customer — a commitment that their order will be delivered in the slot they chose, at the price they saw. It is not Nash performing that delivery. Once a window is booked, the order flows into dispatch like any other: Nash gathers quotes and hands the job to a provider or to your own fleet, and they carry it out within the window you promised. The window is the commitment and the quote surface; see how dispatch works for how the order then gets assigned, and deliveries overview for the delivery it becomes. Nash dispatches into the window it promised; the provider or your own fleet performs the delivery.