Read the route-group context
- 1
Name identifies the territory-planning group and the family of routes it produces.
- 2
Visit Task Template supplies the expected work duration used by planning.
- 3
Visit Purpose distinguishes the commercial reason for the generated beats.
- 4
Partner Account and Branch scope the organizational and geographic population.
- 5
Resource context establishes the field capacity against which outlets are distributed.
Territory planning runs from a Visit Route Group rather than an isolated beat. Name identifies the planning population; Visit Purpose and Visit Task Template provide the service intent and expected stop duration; Partner Account and Branch scope the operating context; and Resource information connects the group to available field capacity. These header choices become the common assumptions under every route the planning run produces.
Before running Plan Territory, validate outlet coordinates, executive shift windows, template duration, candidate resources and—when enabled—vehicle weight or volume capacities. Review the result summary instead of treating route creation as proof of feasibility: dropped outlets, missing coordinates, capacity-data gaps, total road time and balance tolerance are explicit exceptions that require a decision. Preserve the run output and reason for manual changes so later comparisons distinguish optimizer behavior from planner intervention.
Territory planning answers the question a single-route optimizer cannot: "I have a hundred outlets and five executives in one city — who visits what, and in what order?" The Plan Territory action on a route group takes a set of outlets and a set of executives and produces one road-ordered beat per executive, balanced so no one's day is systematically longer than anyone else's. The split itself is the optimization: assignment and stop ordering are solved together over real road travel times.
Inputs and constraints
| Input | How it is used |
|---|---|
| Outlets | Chosen by explicit list, by account group, or as all outlets of a distribution partner; each needs coordinates |
| Executives | One route is created per executive |
| Shift windows | Each executive's working hours from their business-hours record (a tenant default applies otherwise); a route must fit inside the shift |
| Service time per stop | Learned from history — the mean duration of past visits at that outlet — with a configurable default for outlets never visited |
| Balance tolerance | Routes are balanced on total time (travel + in-store service), within a configurable tolerance over the perfect split |
| Van capacity (optional) | Off by default; when enabled, each executive's van caps their route's load by weight and volume, with per-outlet demand estimated from recent order history |
| Max stops per route | Optional hard cap; overflow becomes explicit drops |
The travel times between every pair of points come from road-network data, so the split reflects actual driving, not straight-line distance. Because the computation can take a while, the action runs on a background worker and reports back when done.
What a run produces
One visit route per executive, named for the group and the executive, its stops in solver order and pre-approved — plus an audit run per route recording the real road distance and duration. The run summary is deliberately explicit about its own limits:
- Dropped outlets — when a feasible day cannot include every outlet, the leftovers are reported as dropped rather than silently squeezed in.
- Outlets without coordinates — excluded up front and listed, never silently skipped.
- Capacity data gaps — items that lack weight or volume on the item master count as zero load, so the summary flags them: reported loads are optimistic until the item data is filled in.
- Load vs capacity per route — on capacity-constrained runs, each route reports its estimated load against the van's declared limits.
Rerun semantics
Territory planning is safe to run again. By default a rerun deactivates the group's previous routes — history is preserved, and plans already generated from the old routes are untouched — and creates the new set. Scheduling stays human: the run does not set day-of-week rhythms, so the planner assigns each new beat its weekly schedule before visit plans start generating.
Common questions
How is "balanced" measured?
By total time — travel plus expected in-store service — not by stop count. Ten quick kiosks near each other can be a lighter day than four supermarkets across town, and the solver knows it, because service time per outlet is learned from actual visit history.
What happens to outlets that don't fit anyone's day?
They are dropped and reported by name. The solver prefers an honest partial answer over an infeasible one; the planner can rerun with more executives, longer shifts, or a smaller selection.
Do I have to use van capacity?
No — it is off by default. Enable it when executives sell from stock (van sales) and the van genuinely limits the day; it needs weight/volume on the item master and a declared capacity on each van to bind.