Keep work in the right territory
Decide where you will accept work and which team should receive it, without confusing those two policies.
Choose the boundary you need
| Decision | Setting | Example |
|---|---|---|
| May we accept work here? | Zone Service Restriction | Warn staff that a remote address needs an access check. |
| Which team covers it? | Team Zones | Assign the North team to the North delivery area. |
| May another team help? | Site Zone enforcement | Permit wider coverage when the local team has no available driver pool. |
| Does the area change the price? | Pricing Rules using zones | Apply a reviewed regional surcharge. |
| Do we need a boundary alert? | Geofence Notifications | Tell staff when a driver enters a depot. |
Use Create and import zones for the drawing and file-import steps. This guide helps you choose how those boundaries should affect daily work.
Decide where work is accepted
Open Settings → Zones, then add or edit a zone. Give it a recognizable name and select its Service Restriction:
- None: classify the area without adding a service warning or ban.
- Caution: allow work with a warning, useful for addresses that need an access or surcharge check.
- Banned: block new work in that area unless an authorized operator overrides the restriction.
Leave the zone Active when it should participate. Use Priority to resolve overlapping active zones: the highest-priority containing zone determines serviceability. Give a deliberate higher priority to a smaller exception area, then test it.
Addresses outside every zone are allowed by default. Review the boundary cases before treating a zone map as a complete booking restriction.
Connect the territory to a team
- Open Teams and add or edit the team responsible for the area.
- Choose its coverage in Zones, then save the team.
- Confirm the intended drivers belong to the team and have suitable vehicles and capabilities.
- As a site administrator, open Settings → Site Settings → Auto Dispatcher and review Zone enforcement.
- If automatic assignment should use territories, set Scope to Zone. Select Save settings.
The job's dispatch zone comes from its first stop. A dropoff in another territory does not switch the job to that territory's team. Service restrictions are checked separately at every stop address, so an acceptable pickup does not make a banned destination acceptable.
A driver's current GPS position alone does not make them part of a territory's team. Team coverage expresses responsibility; location and ETA help choose among eligible drivers.
Choose strict or preferred coverage
| Policy | Operational effect | Useful when |
|---|---|---|
| Strict | The driver picker restricts zoned work to covering teams. Zone-scoped automatic dispatch cannot proceed if the job has no zone, no team covers it, or no eligible local driver is available. | Territories are firm responsibilities and exceptions should go through a dispatcher. |
| Preferred | Zone-scoped dispatch uses covering teams first. It can consider the wider site when the job has no zone, no team covers it, or the covering teams have no drivers available after schedule, conflict, and vehicle checks. | Neighboring teams may help during peaks or absences. |
Preferred is not a guarantee of automatic assignment. If local drivers are available but later fail capability requirements, a decline cooldown, expired-offer limits, or the distance limit, automatic dispatch can still leave the job unassigned instead of trying another territory. Keep those exceptions on the dispatcher's work list.
This setting is shared by the driver picker and zone-scoped automatic dispatch. Choosing Site-wide or Team automatic scope is a different driver-pool decision; it does not turn that scope into Zone scope.
Example: the North team normally handles North pickups. Choose Preferred if a South driver may help when the North team has no available driver pool. Choose Strict if that delivery should wait for a North driver or an explicit dispatch decision.
Check the edges and the overlap
- In a test site, create jobs just inside and just outside the boundary. Inspect the zone and any serviceability warning.
- Test an address inside two zones and confirm the intended priority wins.
- Check the driver picker with an available local driver, then with local coverage unavailable.
- If using Zone-scoped automatic dispatch, repeat the unavailable-driver case and a job outside all zones. Also test a local driver who is available but lacks a required capability; confirm how your team will handle the still-unassigned job.
- Separately verify any pricing rule or geofence notification using the same zone. A correct team assignment does not verify those other rules.
Use a new test job after changing coverage so you can inspect its classification and assignment without disturbing an active run.
Troubleshooting
An outside address is still accepted
That is the default behavior outside all zones. Review the actual service-restriction policy; a normal territory polygon is not a blanket outside-area ban.
The wrong overlapping zone applies
Check which zones are active, whether the point is inside their boundaries, and their priorities. Avoid equal priorities for overlapping zones that need different outcomes.
Preferred leaves a job unassigned even though another territory has drivers
Check whether local drivers passed the initial availability checks but were then ruled out by requirements, prior declines, expired offers, or distance. Those later exclusions do not trigger another territory search. A dispatcher should review the job and choose an eligible assignment.
No local driver appears
Check the job's recorded zone, team coverage, membership, duty status, schedule, vehicle, and capabilities. Strict coverage does not create availability.
Next, choose when to dispatch automatically or choose the right notification.