Planned, optimized, actually followed

Most route optimization works like this: take the stops, compute the best order, write it back, done. The plan is now optimal, and any deviation from it is a compliance problem.

That model breaks on contact with a real territory, and it breaks in a specific way: the rep keeps driving a different order, the plan keeps being marked as not followed, and after a few cycles everyone stops looking. The information in that deviation — which is often the most accurate knowledge anyone has about the territory — is discarded as noise.

So we store three sequences per route instead of one.

The three sequences

A visit route in xMatix can hold, simultaneously:

Planned — the order a human set. Usually reflects real constraints nobody wrote down: the wholesaler who only takes orders before 10am, the shop that shuts for lunch.
Optimized — computed over road-network distances through the configured routing provider. Minimises travel, and knows nothing about the lunch break.
Most followed — derived from what reps actually drove on previous visits to this route, generated either route-wide or per salesperson.

Each is stored with its total distance, estimated duration and how many stops it resequences, so they can be compared before one is made current. Making a sequence current is an explicit act, and it applies to subsequent visit plans — the route does not silently change under the person driving it.

Why the third one earns its place

The first two are what you would expect. The third is the one that changed how we think about the feature.

When a rep consistently drives a different order from the plan, there are three possible explanations. They are wrong, and the plan should be enforced. The plan is wrong, and it should be corrected. Or — most often — the plan is right about distance and wrong about everything else it was never told.

The learned sequence does not adjudicate between those. It states the pattern as a fact: this is the order this route is actually driven. That reframes the conversation from "why aren't you following the plan?" to "your order is 4km longer but it exists for a reason — what is it?" One of those questions produces information.

Frequently the answer is mundane and valuable: two of the stops are in a market that is closed until 11am, so the rep does the far cluster first and comes back. No optimizer will ever infer that from a road graph. Once known, it can go into the planned sequence and stop being rediscovered every quarter.

What optimizing distance alone gets wrong

An optimizer values only what it is told to value. Give it distance and it will produce the shortest route, which routinely means arriving at the difficult account at 5pm on Friday, visiting a shop at a different time each week, or breaking the arrival time a shopkeeper has organised their week around.

Predictability is worth real money in a relationship business. It is also invisible in a distance objective. This is why we treat the optimizer's answer as a proposal to compare rather than an instruction to apply — and why the comparison shows distance and duration for all three, rather than declaring a winner.

The cost model shapes the design

One implementation detail with more consequence than it looks. Road-network optimization means calling a routing service, and each call costs money. That single fact rules out the obvious architecture — quietly re-optimizing everything on a schedule — because the bill scales with routes multiplied by frequency for benefit that is often zero on a stable retail territory.

So optimization runs are user-triggered. Someone decides this route is worth optimizing, and the run happens. For cases where a paid call is not warranted, a free nearest-neighbour sequencing option works from the route's coverage midpoint, and the learned sequence costs nothing at all — it is derived from visit history already captured.

That constraint produced a better design than an unlimited budget would have. It forced the question "which routes actually benefit?" to be answered by a person who knows, rather than assumed away.

Where this sits in the bigger problem

Sequencing one route is the easy half. The harder half is deciding who covers which outlets — the assignment problem — which we handle separately through territory planning with a capacitated solver, with service minutes, shift windows, balance tolerance and capacity as tenant settings rather than hard-coded assumptions.

The two interact: the cost of adding an outlet to a territory depends on the route it joins. But they are separate decisions on separate cadences. Territories change a few times a year. Sequence is a property of a route that can be revisited whenever the evidence says it should be.

What we would tell another team building this

Do not model the plan as a single correct answer that execution either matches or violates. Store what was intended, what was computed, and what happened, and let the difference between them be visible.

The deviation is not noise. In a field business it is usually the only channel through which local knowledge reaches the system at all — and a design that overwrites it with an optimal answer is throwing away the most territory-specific data you have.