Time windows, service time, priority, and loadCopy link
A plain address gets an order onto a route. The fields below constrain when it can be served, how long it takes, and how much it loads the vehicle. All of them live in the order editor (open any order on the Orders page), and every one has a matching spreadsheet column, so whatever you can set by hand you can also import.
This example plan has morning and afternoon delivery windows:
Opening hours (time windows)Copy link
Opening hours is the window in which the job may start at the stop. Arriving early is allowed, the vehicle waits (the solution shows the wait); starting after the window closes is not.
- Both ends are optional. Only a start means "not before"; only an end means "not after".
- An order can have up to 4 alternative windows (press + to add one). The order is served within exactly one of them, whichever suits the route best. A shop closed for lunch: 08:00 to 12:00 or 14:00 to 18:00.
- Each window edge takes a day offset for multi-day planning: "+1 day" means the window is tomorrow.
Tight windows are costly to satisfy. Every one-hour window pins part of the day, so use wide windows and save the tight ones for the stops that need them.
Service durationCopy link
How long the driver spends at the stop, in minutes: parking, unloading, paperwork. Without it, the vehicle departs the moment it arrives, which makes every ETA after the first stop optimistic.
Set at least a rough default. Ten stops at 10 minutes each is over an hour and a half of the working day the optimizer would otherwise plan as driving time.
Release timeCopy link
Release time is when the goods become available at the depot. A vehicle cannot load this order before that time, so a route serving it cannot leave earlier. Use it when the morning bakery run cannot start until the bread is out of the oven, or when a supplier delivers to your depot mid-morning. It also accepts a day offset.
Max time in vehicle (shelf life)Copy link
Both fields in this section are Pro features. The free tier can use them within the free paid-feature optimizations.
Max time in vehicle caps how long the order may ride before it is delivered, in minutes. On a plain order the clock is pinned to the order's Release time: service must start no later than the release time plus this value. Chilled goods with a 90-minute cold-chain contract, out of the cold room at 06:00: set the release time to 06:00 and this field to 90, and the optimizer only builds routes that serve the order by 07:30. An order that cannot make it is left unassigned and reported with the reason. Empty means unlimited.
This tutorial plan uses both forms of the field, chilled depot orders and a bounded transfer:
On a plain order the bound covers the Delivery load, which is on board from the depot. A plain order that also carries a Pickup load is rejected: goods collected at the stop ride from there to the depot, a span this field does not bound. Split the collection into its own order, or model the movement as a transfer.
Set a release time whenever you use this field. Without one the clock starts at the beginning of the planning horizon, which is stricter than any real cold chain rather than looser. An opening-hours window that opens later than the release time plus this value can never be used, and an order whose windows all open later than that is impossible to serve: the optimizer stops with an error naming the order instead of producing a plan.
On a pickup & delivery transfer, the field instead bounds the ride time from the end of service at the pickup to the start of service at the delivery. The planner delays the pickup service where that shortens the ride, keeping the consignment at its origin instead of boarding it early, so only waiting that no feasible loading time can avoid counts toward the bound, and a reload does not reset the clock. In the tutorial plan above, the hotel accepts its delivery from 10:00. The van reaches the gelato lab well before that, waits there with the goods still at the counter, and loads late enough that the ride fits the 30-minute bound. Set the same value on every end of the transfer, alternative pickup and delivery locations included: ends that disagree are flagged on import, and the whole transfer is skipped at optimization. A transfer carrying this field combines with driver breaks: break placement avoids the span between pickup and delivery where it can, and a break placed inside it counts toward the ride like driving or waiting does. That break time is charged against Max ride overtime below, and a transfer that cannot meet its bound around the mandated breaks goes unassigned with the "Max time in vehicle" reason.
Max ride overtime, on a transfer end only, allows the ride to run past "Max time in vehicle" for a limited additional time, in minutes, priced per hour on the vehicle's cost fields. Beyond that allowance the bound is hard. It requires "Max time in vehicle" on the same transfer: set alone, it stops the optimizer with an error. Set the same value on every end; a mismatch skips the transfer, as above. Empty means no allowance, so the bound is hard with no priced overtime.
PriorityCopy link
Priority is a number from 1 to 1000 (default 1) that decides what gets dropped when not everything fits. Every order is optional to the solver: when the fleet cannot serve them all, higher-priority orders are kept and lower-priority ones go unassigned first.
It is a ranking, not a schedule: priority does not make an order come earlier in the route, it makes the order survive when capacity or time runs out. Use a large value like 1000 for "serve this unless physically impossible". See Why an order went unassigned for how dropped orders are reported.
Pickup and Delivery loadsCopy link
Delivery is the load brought from the depot to the stop; Pickup is the load collected at the stop and carried back to the depot (returns, empties). One order can have both. Loads are unitless: pick one unit (parcels, kilograms, crates) and use it consistently across orders and vehicle capacity. Two exceptions move goods between stops instead of via the depot: pickup & delivery transfers and order sequences, where a pickup at one stop feeds the drops after it.
The optimizer tracks the load on board stop by stop and keeps it within each vehicle's capacity. The full picture, including how reloads interact, is in Capacity, deliveries, and pickups.
The Pro fieldsCopy link
The remaining order-editor fields (marked with a PRO pill) cover specialized setups. Max time in vehicle and Max ride overtime are covered above; the rest:
- Required tags / Forbidden tags restrict which vehicles may serve the order, like "freezer van only". See Tags: vehicle-order compatibility.
- Transfer order (PUD) and Transfer id turn two orders into a pickup-delivery pair moved site to site on one route. See Pickup & delivery transfers.
- Custom sequence and Sequence put several orders on one route in a fixed order. See Order sequences.
- Alternative group marks orders as interchangeable: the solver serves at most one order per group (deliver to the door OR the pickup point), and reports the rest as "not chosen" rather than unassigned.
- Load class names the product class this order carries. Two classes listed in one of a vehicle's Do not mix load classes groups never ride together on that vehicle's route, reload trips included. See Product segregation.
Next stepCopy link
Per-order details cover one side of the model; vehicle limits cover the other. Continue with Shifts, working hours, and route limits.