Routes & Optimization
A route is the set of delivery stops a single driver is working through right now. In the cloud-native delivery system, routes are built automatically as deliveries are assigned or claimed -- you no longer hand-build a route in the admin panel and push it to a device. Each stop carries a live status, an ETA, and an on-time flag against the customer's delivery window.
Routes require Enable Local Delivery (enable_local_delivery) to be enabled in your store settings.
Route ordering and ETAs come from Google Maps. They require a Google Maps API key -- see Delivery Setup. Without a key, stops still work and can be delivered; they just keep their original order and show no ETA.
How a Route Comes Together
- A delivery order is created (POS register, storefront, or WooCommerce) with a delivery address.
- The address is geocoded to a map pin in the background.
- The order joins the available pool of unassigned deliveries.
- The delivery gets a driver, one of two ways:
- A dispatcher assigns it to a driver from the Dispatcher Console, or
- A driver claims it themselves from the Available tab in the app.
- Either way, a stop is added to that driver's route for the day (the route is created the first time a driver gets a delivery).
- The driver taps Optimize to order the stops for the fastest trip and get ETAs.
- The driver works the stops -- notify, arrive, deliver -- and finishes the route.
There is one active route per driver per day. New deliveries assigned to that driver are appended to the same route.
Stop Statuses
Each stop moves through these states as the driver works it:
| Status | Meaning |
|---|---|
| Pending | On the route, not yet started. |
| En route | Driver is heading to the stop. |
| Notified | The customer has been sent (or queued) the "almost there" text. |
| Arrived | Driver has reached the address. |
| Delivered | Order handed off; cash collected recorded for COD orders. |
| Failed | Delivery could not be completed. |
The Available Pool
The "available" deliveries a driver can claim (and that a dispatcher can assign) are local-delivery orders that:
- have no driver and no route yet, and
- are due today or earlier -- unscheduled "ASAP" orders and any overdue orders show immediately, while orders scheduled for a future day stay hidden until that day.
This keeps next-day orders out of today's queue automatically. Available deliveries are sorted by their delivery-window end time, so the most time-sensitive orders surface first.
Delivery Windows
A delivery can carry a time window (the earliest and latest the customer should expect their order). Windows come from:
- A scheduled time slot chosen at order time. Slots map to fixed hours: Morning 9 AM-12 PM, Afternoon 12-5 PM, Evening 5-9 PM.
- WooCommerce online orders with a chosen delivery time become a next-day 1-hour window automatically (see WooCommerce Orders).
Each stop is flagged on time or late by comparing its predicted ETA against the window's end. A stop with no window simply has no on-time flag.
Route Optimization
When a driver taps Optimize in the app, Brother POS reorders their remaining stops and computes an ETA for each one. The optimizer is traffic-aware and window-aware:
| Situation | How stops are ordered |
|---|---|
| No delivery windows | Google Maps picks the fastest overall route (shortest total drive time) from the driver's current location. |
| Some stops have windows | Stops are ordered deadline-first -- earliest window-end first, nearest stop breaking ties -- so time-sensitive deliveries come first. Google then supplies accurate drive times in that order. |
Each ETA accounts for:
- Live traffic drive time between stops (not just distance).
- A fixed service time spent at every prior stop (parking, walking to the door, handing off). This is configurable; the default is 5 minutes per stop.
The dwell time added per stop is controlled by the delivery_service_minutes store setting (default 5 minutes). Raise it if your drivers typically spend longer at each door; this makes downstream ETAs more realistic.
A single optimization request handles up to 25 stops. For navigation, Google Maps fits about 10 stops per trip -- the app opens the first 10 as one trip and tells the driver how many remain for a second trip.
Stops that never geocoded (no map pin) are left in place during optimization rather than dropped -- fix their pins with the geocode tool below so they can be routed.
Live Location
While a driver is on a route, the app can report the driver's position so dispatch sees their latest location on the live map. Driver location is the most recent fix sent from the app, shown to dispatchers in the Dispatcher Console.
Fixing Delivery Pins (Geocoding)
When a delivery address can't be matched to a precise map location, it's flagged so you can fix it before the driver heads out. From the Deliveries page, open Fix delivery pins (a count badge shows how many need attention).
The page lists local-delivery orders whose address came back fuzzy (matched only approximately) or failed (no match). For each one you can:
| Action | What it does |
|---|---|
| Re-geocode | Re-runs the address through Google Maps -- use this after correcting a typo in the address. |
| Save pin | Manually enter latitude/longitude to place the pin exactly, marking the address as manual. |
A stop with no pin can't be slotted into the optimized order or shown on the map. If a delivery looks out of sequence or missing from the map, check Fix delivery pins first.
Completing a Route
A driver finishes their route from the app once every stop is delivered (or failed). On completion the route records the total cash collected across its COD stops, which is the sum of cash recorded at each delivered stop.
Best Practices
- Set realistic time slots -- don't promise a morning window for an order placed mid-afternoon.
- Keep service time honest -- if drivers regularly take longer than 5 minutes per door, raise
delivery_service_minutesso ETAs stay believable. - Clear the pin queue daily -- check Fix delivery pins each morning so every stop can be routed and mapped.
- Re-optimize after new claims -- when a driver picks up extra stops mid-run, have them tap Optimize again to re-sequence.
- Watch the live map at peak -- the Dispatcher Console shows every driver's stops and last position so you can spot a driver falling behind.
Troubleshooting
| Problem | Solution |
|---|---|
| Stops won't reorder / no ETAs | The Google Maps API key isn't configured, or stops have no pins. See Delivery Setup and Fix delivery pins. |
| A delivery is missing from a driver's route | Confirm it was assigned or claimed, and that it isn't scheduled for a future day (those stay hidden until their day). |
| ETAs look wildly off | Service time may be set too low/high, or traffic conditions changed since the last optimize. Have the driver re-optimize. |
| Stop shows "late" repeatedly | The customer's window is tighter than the route can meet; consider splitting the route or adjusting promised windows. |
What's Next?
- Dispatcher Console -- Assign drivers and watch deliveries live.
- The Driver App -- The driver's side of a route.
- Delivery Zones -- Define where you deliver and what you charge.
- Delivery Setup -- Google Maps and push notification setup.