Ask how a field team's day gets planned and the answer is usually a person: a supervisor exports a list, or the rep decides in the morning. Both work, and both drift — because a plan assembled by hand is assembled with the effort available on the day, and the effort available on the day is variable.
The alternative is to treat the day's list as something the system produces from a schedule that was agreed once. It is not a sophisticated feature. It is one of the highest-leverage ones we have shipped.
The schedule lives on the route
In xMatix, a visit route — the beat — carries its own schedule rather than being fed by an external planner. A route can repeat on given days of the week, on a week-of-month pattern (weeks one and three, for fortnightly coverage), or on a cron expression for cases the first two do not express.
From that, visit plans are materialised over a rolling lead-days window, so the coming days' lists exist before the days do. Nobody generates tomorrow; tomorrow is already there.
Putting the schedule on the route rather than in a separate planning tool has one consequence worth naming: there is no import step, so there is no drift between the plan someone maintains and the plan the field executes. They are the same object.
Why generation must be continuous, not a one-off import
The common implementation is a bulk import: build the journey plan in a spreadsheet, load it, and load it again when it changes. That fails in a specific way — the loaded plan is a snapshot, so every change means a rebuild, and rebuilds are avoided, so the plan ages.
Continuous generation inverts the failure mode. Because plans are produced from the route on a rolling window, a change to the route takes effect on the next generation rather than requiring anyone to regenerate anything. Adding a stop, changing a frequency or transferring outlets between beats propagates by itself.
Three details that make it work
Serialisation. Generation runs against shared state, and the failure mode of running it twice concurrently is duplicate visit plans — which is worse than not generating at all, because reps then face two lists and trust neither. Generation is serialised so that cannot happen.
Assignment and acceptance. A generated plan is assigned to the person who will execute it, and carries an acceptance state. That closes the gap between "the system made a plan" and "someone knows it is theirs".
Cleaning up what was never executed. Plans that came and went unexecuted are cancelled rather than accumulating. This one is easy to skip and expensive to skip: a system that keeps stale plans forever grows a backlog nobody will ever clear, and once the backlog is large enough to be hopeless, people stop reading the list at all — which removes the entire benefit.
What generation does not decide
The journey plan answers which outlets and when. It deliberately does not answer in what order — that is sequencing, which is a separate, versioned property of the route with its own planned, optimized and learned variants.
Keeping them separate matters because they change on different cadences. Frequency is a commercial decision revisited a few times a year. Sequence is an operational one that can be revisited whenever the evidence suggests it. Coupling them would mean re-planning coverage every time you wanted to re-order the stops.
The measurable effect
The gain is not that planning takes less time, though it does. It is that coverage becomes measurable.
When the day's list is generated from an agreed frequency, "which outlets did we promise to visit this week?" has a denominator — and coverage becomes a fraction rather than an assertion. Missed visits cluster in visible patterns: the same forty outlets at the end of two overloaded beats, every cycle. That is a beat-planning fix, and it is invisible without a generated plan to compare against.
What we would tell another team
If your users are assembling a recurring work list by hand, generating it is likely worth more than anything clever you could do with it afterwards. Optimising a list somebody had to build is optimising the wrong step.
And when you build it: serialise generation, expire what was never executed, and keep the "when" separate from the "in what order". Those three details are the difference between a feature people rely on and one they route around.
Related: What is a permanent journey plan? · Beat planning · xMatix Field Sales