01 · Orientation

Route optimisation, without the bullshit

A visual coaching guide for thinking clearly about planning, constraints, solvers and real-world execution.

FleetRobo learning lab
The map is the easy part.

The hard part is deciding who should visit which stops, in what order, at what time, with which vehicle—while reality keeps changing.

Milk collection exampleVRP made intuitiveIndustry patternsFleetRobo lens
Use this guide to: ask better customer questions, challenge vague “AI” claims, reason with engineering, and recognise where product differentiation actually lives.
Chilling centre start + return A B NEW C 2,500 L Can NEW fit?
Route optimisation mental modelAJ coaching pack · 10 Aug 2026
02 · Mental Model

Five problems people lazily call “routing”

Separate them first. Otherwise product conversations become a soup of maps, GPS and algorithms.

FleetRobo learning lab
1

Routing

Which road path connects known points?

A → B using truck-safe roads
2

Sequencing

In what order should stops be visited?

Depot → C → A → B
3

Allocation

Which vehicle or driver owns each stop?

Truck 7 serves A, C, F
4

Scheduling

When should each visit and shift occur?

Reach A between 06:00–06:30
5

Optimisation

Search across all four decisions for the best feasible plan.

Minimise cost without breaking reality
Tracking is different again: it observes what actually happened after the plan was committed. Planning produces intent; GPS produces evidence.
Route optimisation mental modelFleetRobo Order → Plan → Execute abstraction
03 · Problem Anatomy

A milk run is a Vehicle Routing Problem with personality

The generic skeleton is familiar. Dairy adds freshness, variable collection quantities and sometimes product-separation rules.

FleetRobo learning lab
Chilling centre 2 vehicles · 05:30 start P1600 L05:40–06:10P2450 L05:55–06:35P3700 L06:20–07:00P4300 L06:30–07:20P5450 L06:05–06:35

What the planner is really deciding

  • Assignment: which truck collects each point?
  • Sequence: in what order?
  • Timing: can every collection window be met?
  • Load: does cumulative milk stay within capacity?
  • Return: can the truck reach the chilling centre before quality or shift limits?
  • Stability: should today’s familiar route be preserved even if another plan is 2 km shorter?
Important: “Shortest route” is usually the wrong problem statement.
Route optimisation mental modelDairy lens informed by milk-collection VRP research
04 · Inputs

Optimisers do not consume “business requirements”

They consume structured entities, constraints, costs and an objective. Bad modelling in means confidently wrong plans out.

FleetRobo learning lab
Visits / orders location · quantity · window Vehicles / shifts capacity · start · availability Network facts time matrix · roads · traffic Optimisation model decision variables + constraints + objective What is allowed? What is preferred? Assignments stop → vehicle Sequences ordered stops Schedule arrival + departure
Coordinates are not addresses.Capacity may be weight, volume, compartments or product compatibility.Travel time is not straight-line distance.
Route optimisation mental modelGoogle Route Optimization shipment/vehicle model; OR-Tools dimensions
05 · Core Logic

Hard constraints gate. Soft objectives rank.

This distinction is the single most useful concept for product conversations.

FleetRobo learning lab
HARD CONSTRAINTS capacity · time window · vehicle compatibility · max shift · required visit Fail one → solution is infeasible SOFT OBJECTIVES distance · overtime · balance · overlap · route stability · preference Trade-offs produce a score
Candidate routes
Option B92feasible · stable · +4 km
Option A74feasible · +8 km · more delay
Option C—infeasible · misses window

Never hide infeasibility behind a mysterious low score. Explain the broken rule.

Route optimisation mental modelTimefold hard/medium/soft scoring; Google skipped shipments and validation errors
06 · Worked Example

Can a new pickup fit an existing route?

Test every sensible insertion position, reject broken constraints, then compare the survivors.

FleetRobo learning lab
Existing Route R1
D12mA14mB18mC22mD
Load 1,900 / 2,500 L · all windows currently pass
NEW P5450 Lwindow 06:05–06:35service 8 min
AD → A → P5 → B → C → D
+8 km
❌ C becomes 18 min late
BD → A → B → P5 → C → D
+4 km
✓ capacity, windows and shift pass
CD → A → B → C → P5 → D
+11 km
❌ P5 reached after 06:35
RecommendationInsert P5 after Bbecause it is the lowest-cost feasible change—not merely the geometrically nearest point.
Route optimisation mental modelDynamic VRP insertion-heuristic pattern
07 · Dynamic Planning

Insertion, local repair or full re-optimisation?

The smartest planner is not the one that constantly redraws everything. Operational stability has value.

FleetRobo learning lab
New request point · load · window Test cheap insertions existing routes + positions Good feasibleinsertion? Insert locally preserve committed routes Re-optimise a zone move a bounded set of stops Acceptabledisruption? YESNO If still infeasible: new route, defer, outsource or reject—with a reason
Route optimisation mental modelDynamic routing and real-time replanning patterns
08 · How Solvers Think

The solver searches. It does not “understand logistics”.

Your team supplies the model and trade-offs; the engine explores combinations faster than humans can.

FleetRobo learning lab
BEST KNOWNPLAN Create candidate assign + sequence Check feasibility reject broken rules Score candidate cost + preferences Keep or perturb search nearby alternatives
Exact methods

Can prove optimality, but often become slow as problem size and constraints grow.

Heuristics / metaheuristics

Find good solutions quickly; may not prove they are globally best.

Time limit

Real products frequently ask for “best answer in 2–30 seconds,” not theoretical perfection.

Product implication

Show solution quality, unresolved visits and trade-offs—not a magical “Optimised” badge.

Route optimisation mental modelOR-Tools: VRPs are computationally hard and may return good, non-optimal solutions
09 · AI Reality Check

Optimisation chooses. Machine learning predicts.

They can work together, but calling the whole thing “AI” hides important engineering and product decisions.

FleetRobo learning lab
Prediction layer ETA · demand · service time · risk Optimisation layer constraints + objective → plan Execution layer dispatch · GPS · stop events · overrides Outcome actuals Actual travel, wait and load data improve future predictions and rules
Rule of thumb: If the task is “choose the best feasible combination,” think operations research. If it is “estimate an unknown future value,” think machine learning.
Route optimisation mental modelPrescriptive optimisation + predictive models
10 · Industry Patterns

How others package the same underlying problem

The market differs less in the mathematics than in control, integration, explainability and operational workflow.

FleetRobo learning lab
BUILD

Solver toolkit

Google OR-Tools

You own the data model, distance matrix, constraints, search configuration, scaling and UX.

Best when optimisation logic is strategic IP and you have OR engineering depth.
API

Managed optimiser

Google / HERE

Send vehicles, visits, windows and costs; receive assigned routes, metrics and unresolved work.

Fastest path when roads, traffic and industrial solving are infrastructure—not differentiation.
PLATFORM

Constraint platform

Timefold

Model hard and soft constraints, score solutions, support real-time planning and expose useful visualisations.

Useful when constraint flexibility and explainability matter more than owning the solver.
BUY

Operations SaaS

OptimoRoute

Import orders, plan, manually adjust, dispatch to drivers, track progress and analyse actual performance.

Shows the complete user workflow—but offers less control over your TMS product experience.
GraphHopper illustrates another modular pattern: separate geocoding, routing, matrix and optimisation APIs so each layer can be swapped or owned independently.
Route optimisation mental modelOfficial Google, HERE, GraphHopper, Timefold and OptimoRoute documentation
11 · Architecture

What FleetRobo should own—and what it can rent

Own the operational truth and decision experience. Treat road intelligence and solver machinery as replaceable capabilities until proven otherwise.

FleetRobo learning lab
FLEETROBO-OWNED PRODUCT + DOMAIN PROVIDER CAPABILITIES Orders + resources visits · vehicles · shifts Policy + validation hard rules · preferences · data quality Problem canonical model Road intelligence geocode · route · matrix · traffic Solver capability search · score · return candidates Candidate plans + reasons Planner experience compare · explain · edit · approve Committed TMS Plan Also own: versioning, approvals, audit, override reasons, Plan → Trip binding and planned-vs-actual learning.
Route optimisation mental modelRecommended composable boundary; provider-independent orchestration
12 · Product Experience

A trustworthy planner is a decision cockpit, not a “Generate Route” button

Humans need to see the plan, understand compromises and stay in control when the model meets messy operations.

FleetRobo learning lab
1

Prepare

Validate visits, fleet, windows and missing data

2

Configure

Choose objective, frozen routes and allowed disruption

3

Generate

Produce candidates plus infeasible/unassigned work

4

Compare

Map + vehicle timeline + visit view + metrics

5

Explain

Why assigned, why skipped, which constraint binds

6

Adjust

Drag, lock, override and re-run locally

7

Commit

Approve versioned Plan and dispatch

8

Observe

Track actuals, exceptions and route adherence

9

Learn

Calibrate ETAs, service times and business rules

Mapspatial shape + overlaps
Vehicle timelineshift, wait, breaks, lateness
Visit tableassignment, window, reason, status
Route optimisation mental modelTimefold visualisation workflow; OptimoRoute planner workflow
13 · Failure Modes

Most route-optimisation failures are product failures before they are algorithm failures

The solver is an excellent scapegoat for missing data, contradictory rules and ignored operational behaviour.

FleetRobo learning lab

Garbage coordinates

Pins fall on the wrong road, village or entrance.

Validate and let users correct map points.

Fantasy travel times

Rural roads, loading queues and seasonal conditions are absent.

Calibrate matrix estimates with actual trip data.

Constraint explosion

Every stakeholder marks preferences as mandatory.

Force hard-versus-soft classification and ownership.

Plan instability

Minor changes reshuffle every driver and stop.

Freeze committed work and penalise disruption.

Silent infeasibility

Visits vanish because no route can legally serve them.

Show unassigned work and exact reason codes.

Manual override blindness

Drivers know local reality but overrides disappear.

Capture reason, outcome and repeat patterns.

Optimise the wrong KPI

Distance falls while overtime, spoilage or service failure rises.

Use a balanced scorecard tied to business outcome.

Tracking ≠ planning

GPS dots are mistaken for route intelligence.

Keep Plan intent and Trip evidence as separate layers.
Route optimisation mental modelOperational synthesis across solver docs and FleetRobo Plan/Execute model
14 · Coaching Questions

Questions that reveal the real problem

Ask these before discussing vendors, algorithms, screens or “AI”.

FleetRobo learning lab

Business

  1. What does “better” mean: distance, vehicles, freshness, on-time rate, stability or cost?
  2. What is the cost of leaving one pickup unserved?
  3. Which decisions are strategic, daily and real-time?
  4. What can a planner override, and who approves it?

Constraints

  1. Which rules are truly impossible to break?
  2. Which rules are preferences with penalties?
  3. Are quantities known, forecast or confirmed only at pickup?
  4. Do milk grades, compartments or cleaning rules restrict mixing?

Operations

  1. When are routes frozen?
  2. How frequently do new points or quantity changes arrive?
  3. What causes planners and drivers to ignore generated routes?
  4. How are waiting, failed visits and road exceptions recorded?

Technology

  1. Where do geocodes, traffic and GPS come from?
  2. What response time is acceptable for planning and replanning?
  3. Must the result be reproducible and auditable?
  4. What happens when provider APIs or GPS are degraded?
Route optimisation mental modelDiscovery checklist for modelling before solution selection
15 · Learning Path

What you should learn—in the right order

You do not need to become an operations-research scientist. You need enough depth to frame the problem, challenge assumptions and lead product decisions.

FleetRobo learning lab
01

Vocabulary

TSP, VRP, CVRP, VRPTW, pickup-delivery, depot, matrix, hard/soft constraints.

Outcome: translate customer language into a known problem family.
02

Model a tiny case

Use 1 depot, 2 vehicles and 8 visits on paper. Mark capacity and windows.

Outcome: feel why nearest-neighbour logic fails.
03

Run a solver

Complete the OR-Tools VRP and time-window tutorials; alter one constraint at a time.

Outcome: understand inputs, search limits and infeasibility.
04

Compare providers

Send the same small dataset to one managed optimiser and compare its model/output.

Outcome: separate provider capability from FleetRobo product value.
05

Shadow reality

Observe planners for two route-planning cycles and capture every manual exception.

Outcome: discover hidden constraints no workshop will surface.
06

Design the cockpit

Prototype map + timeline + visit table + reason explanations, not just route lines.

Outcome: test whether humans trust and can repair the plan.
07

Measure the loop

Compare planned vs actual distance, time, stops, load and overrides.

Outcome: improve estimates, rules and adoption continuously.
Route optimisation mental modelPractical PM learning sequence
16 · FleetRobo Bridge

The mental model to carry into Universal TMS

Do not jump to features yet. Preserve these product truths when we eventually design the planning capability.

FleetRobo learning lab
1

Plan is a commitment

Optimisation proposes a versioned Plan. GPS and Trip events later prove what happened.

2

Patterns stay generic

Milk collection maps to Multi-Stop or Consolidated Plans; dairy rules belong in configuration.

3

Explainability is product

Why this vehicle, why this sequence, why this stop is unassigned and what changed must be visible.

4

Human control is not failure

Locks, edits and overrides are first-class operational inputs—not embarrassing exceptions.

5

Providers remain replaceable

FleetRobo owns the canonical model, policy, workflow, audit and execution feedback loop.

6

Optimise outcomes

Distance is one metric. Reliability, capacity, freshness, workload, stability and service matter too.

Your next useful question is no longer “Can we build route optimisation?” It is: “What decisions, constraints and outcomes must our planning product own?”
Route optimisation mental modelFleetRobo Universal TMS product principles
17 · Reference

A compact glossary and source map

Keep this page nearby when the acronyms start breeding.

FleetRobo learning lab
TSPOne vehicle, visit all locations, choose sequence.
VRPMultiple vehicles, assignments and routes.
CVRPVRP with vehicle capacity.
VRPTWVRP with visit or shift time windows.
PDPPickup and delivery pairs with precedence.
MatrixTravel time/distance between every relevant pair.
ObjectiveWhat the solver tries to minimise or maximise.
PenaltyCost of a soft-rule violation or dropped visit.
HeuristicA method that finds good solutions quickly.
Re-optimisationSolve again after data or operations change.

Study next

Foundations: Google OR-Tools Vehicle Routing, VRP and VRPTW guides.

Managed API model: Google Maps Route Optimization request/response and time-window concepts.

Constraint product: Timefold introduction, visualisations and metrics.

Operations workflow: OptimoRoute planning and planning-settings guides.

Dairy depth: milk collection centre VRP, raw-milk routing and blending research.

Full URLs: included in the companion SOURCES.md.

Coaching rule: learn through one evolving dataset. Changing the example every time hides the effect of each constraint.