Scheduling plans: how the automatic cycle works
The dispatcher runs on a schedule you define per store, or per group of stores. Scheduling and assignment behaviour are configured together, in the same plan.
How the automatic cycle works
- Each plan defines how often the dispatcher should run for a group of stores.
- You can optionally restrict execution to a daily time window — for example, only between 08:00 and 23:00.
- If a run fails, the cycle is not broken. The next run is still scheduled automatically, as long as the plan is active.
- If a run falls outside the configured time window it is skipped for that cycle, but the schedule keeps going and resumes normally once back inside the window.
Scheduling settings
| Setting | Default | What it does |
|---|---|---|
| Plan name | — | A label to help you identify this plan. Optional, free text |
| Stores | — | The stores this plan applies to. One plan can cover several |
| Active | Off | Whether the automatic cycle is currently running for this plan |
| Run interval | 60 seconds | How often the dispatcher re-runs. Allowed range: 60–300 seconds |
| Daily time window | None | Optional start and end time. If not set, the plan runs 24/7 |
| Last run | — | Read-only. When this plan last actually ran |
Assignment behaviour settings
| Setting | Default | What it does |
|---|---|---|
| Assignment mode | Automatic | Forces PG Mode or Google OR-Tools, or leaves the choice automatic (recommended) |
| Routing strategy | Automatic | Only relevant when Google OR-Tools is used |
| Stop time at customer | 5 min | Extra time accounted for at each customer stop |
| Stop time at store | 3 min | Extra time accounted for at each store stop |
| Maximum orders per driver | 3 | Most orders bundled onto a single own driver. Allowed range: 1–5 |
| Offline driver grace period | 5 min | How long a briefly-offline driver is tolerated before being treated as unavailable |
| Apply results | On | When off, the run is a simulation only and nothing is changed |
| Extra time margin | 10 min | Additional slack allowed. Only relevant to Google OR-Tools |
| Minimum orders to accept a plan | 0 | How many orders Google OR-Tools must successfully assign for its plan to be accepted |
| Priority Customers (Platinum) | Disabled | Enables and configures the Platinum layer — see Priority Customers (Platinum) |
| Traffic-aware estimates | Off | More accurate time estimates, at a higher cost |
| Traffic estimate type | — | Optimistic, pessimistic or best guess. Only used when traffic-aware estimates are on |
| Return-time reuse | — | Advanced. Controls how aggressively previously calculated driver-to-store times are reused instead of recalculated |
Store-level delivery settings
Two further settings live at the store level, not inside the scheduling plan. They are configured from the store's dispatcher settings and control how much delay is tolerated before an order is treated as at risk.
| Setting | Applies to | What it does |
|---|---|---|
| Own-fleet delay tolerance | Your own fleet — in-house and own-fleet contractors, treated equally | The delay tolerance used when checking whether your own fleet can deliver on time. If a store has no in-house drivers at all, this value is automatically replaced by the Third-Party tolerance below, so an all-contractor store isn't held to a stricter standard than it can meet |
| Third-Party delay tolerance | Third-Party carriers | The delay tolerance used to decide whether a carrier can be trusted to deliver on time. It always applies to carriers, whether or not the store also has in-house drivers |
Capacity works differently from delay tolerance. Your own fleet has a per-driver limit — each vehicle carries up to the configured maximum at once. Third-Party carriers have a single shared pool per store, per carrier company — for example "this carrier can handle 10 concurrent orders at this store", however many individual couriers they have on the road. This is why a carrier can appear full for a store even when it looks like it has plenty of drivers: the limit is set at company level, not per courier.
Activating and pausing a plan
This is the part most likely to cause confusion.
| Action | Starts the cycle? | Stops the cycle? |
|---|---|---|
| Create a plan with Active switched on | Yes | — |
| Create a plan with Active switched off | No — it stays dormant | — |
| Edit an existing plan and switch Active on | No effect — it only updates the stored value | — |
| Edit an existing plan and switch Active off | — | Yes, from the next run onwards |
| Use the dedicated Activate action | Yes | — |
| Use the dedicated Pause action | — | Yes |
| Delete a plan | — | Yes |
Recommendation: don't rely on editing the Active field through a general edit form. Always use the dedicated Activate and Pause actions — editing the field directly can leave a plan marked active but not actually running.