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 · Real Operations

Route planning happens at three different horizons

The users, decisions, data freshness and tolerance for change are different at each horizon. Treating them as one screen creates chaos.

FleetRobo learning lab
MONTHLY / WEEKLY1

Network and route design

Define the stable operating shape before daily demand arrives.

  • Depots, collection zones and route templates
  • Service days and standard collection windows
  • Vehicle types, capacities and transporter pools
  • Policies: maximum distance, duration and mixing rules
Owner: Operations manager + route designer
DAY-BEFORE / SHIFT START2

Daily planning

Turn today’s work and available fleet into committed Plans.

  • Import today’s quantities, additions and cancellations
  • Confirm vehicles, drivers, shifts and unavailable assets
  • Insert visits, create routes and compare alternatives
  • Review, adjust, approve and dispatch
Owner: Route planner / dispatcher
SAME DAY / LIVE3

Exception and replanning

Repair only what must change after commitment or movement.

  • New pickup, quantity spike, delay or breakdown
  • Protect completed and frozen work
  • Repair locally before re-optimising a wider zone
  • Approve, notify and preserve a new Plan version
Owner: Dispatcher + supervisor + live ops
Reality: planners rarely start from a blank map. They begin with yesterday’s routes, today’s changes and a limited permission to disturb what drivers already know.
Route optimisation mental modelReal operations model: design → daily commit → bounded live repair
14 · Daily User Flow

How a route planner builds and commits the day

A practical swimlane: what the system prepares, what the planner decides, what the supervisor governs and what the transporter receives.

FleetRobo learning lab
SYSTEMPLANNERSUPERVISORTRANSPORTER / DRIVER Load today visits · quantity · windows Share availability vehicle + driver truth Resolve inputs points · fleet · exceptions Set boundaries locks · objective · cut-off Validate + generate candidates · unassigned Review + adjust map · timeline · visits Approve or return Receive routes acknowledge version Output: a versioned, auditable Plan—not merely a polyline. Unassigned visits remain visible with reasons.
Route optimisation mental modelDay-before / shift-start planner operating flow
15 · Live User Flow

When reality changes, repair the smallest safe part of the plan

Same-day replanning is governed change management. The goal is not to continuously redraw every route.

FleetRobo learning lab
New pickupQuantity spikeVehicle unavailableRoad delayMissed collection
Capture change time · location · impact Protect reality completed · started · frozen work Can one routeabsorb it safely? Local repair insert · swap · delay one route Re-optimise a zone only unlocked routes + visits Approve + notify new Plan version YESNO STILL FAILS If still infeasibledefer · outsource · add vehicle · reject with reason
Driver communication: never silently alter a dispatched route.Versioning: keep original, changed and actual sequence.Success metric: service recovered with minimum disruption.
Route optimisation mental modelBounded dynamic replanning with frozen-horizon control
16 · Screen Journey

The planner moves through eight decision screens—not one giant map

Each screen should answer one operational question and make the next commitment explicit.

FleetRobo learning lab
1

Planning work queue

What needs a plan today?

Dates · zones · cut-offs · readiness

2

Input readiness

Is the demand and fleet truth usable?

Missing pins · quantities · vehicles · drivers

3

Plan setup

What can the system change?

Template · objective · locks · disruption budget

4

Generate options

What feasible choices exist?

Candidates · score · unassigned work

5

Planning cockpit

Does this option work operationally?

Map · timeline · visit table · warnings

6

Compare + repair

Which compromise should we accept?

Diff · drag · swap · lock · re-run

7

Approve + dispatch

Who commits this version?

Approval · acknowledgement · notifications

8

Live control

What changed after commitment?

Exception · impact · bounded repair · new version

Design rule: do not ask a planner to configure policies, clean data, compare routes and monitor execution in the same visual state. The map persists, but the decision context changes.
Route optimisation mental modelRecommended planner information architecture
17 · Screen 1–2

Start with a planning work queue, then force input readiness

The first job is not optimisation. It is making today’s planning problem visible, owned and solvable.

FleetRobo learning lab
Daily PlanningMon, 10 Aug · Morning collection
1,840 Lexpected demand
12 / 14pickup points ready
2blocking issues
3 / 4vehicles confirmed
Planning setDemandFleetCut-offStatus
North clusterTemplate: NC-AM-v128 points · 1,150 L2 vehicles04:45Ready
East cluster2 new pickup requests6 points · 690 L1 of 2 confirmed05:00Blocked
Resolve before planningPickup P14 has no verified road entranceVehicle MH04 is unavailable; replacement not assigned
Planner sees: workload and blockers, not a blank map.System does: validation and issue ownership.Gate: generate stays disabled until hard blockers are resolved or explicitly waived.
Route optimisation mental modelRecommended work-queue and input-readiness experience
18 · Screen 3–5

The planning cockpit combines spatial, temporal and tabular truth

A route can look clean on a map and still fail capacity, time windows, shift limits or operational familiarity.

FleetRobo learning lab
North cluster · Draft v3Baseline: yesterday’s approved plan
Objective Service firstLocked 2 familiar assignmentsMax disruption 20%Candidate B · balanced
D
12345
Truck 1Truck 2Risk
Vehicle timeline
MH0105:30 → 08:05
MH0705:30 → 08:35
05:3007:0008:30
P3 arrival has only 6 min buffer
VisitTruckETALoadReason
P1MH0105:48600 Lclosest feasible
P3MH0106:541,300 Lwindow risk
P5MH0706:18450 Lcapacity fit
Why candidate B?

All visits served, no overtime, 18% change from baseline. Candidate A is 7 km shorter but breaks P3’s window.

Route optimisation mental modelRecommended map + timeline + visit + explanation cockpit
19 · Screen 6–7

Comparison, approval and dispatch are separate commitments

The best-scoring candidate is not automatically the approved operating plan. Humans choose the compromise and own the release.

FleetRobo learning lab
MetricA · CheapestB · BalancedC · Stable
Distance126 km133 km141 km
Vehicles222
Late visits100
Change vs baseline42%18%6%
Overtime0022 min
Unassigned000
Planner chooses B: +7 km buys full service compliance without destabilising familiar routes.
1
Planner review3 manual edits · reasons captured
2
Supervisor approvalService-first trade-off accepted
3
Transporter acknowledgement2 vehicles · 2 drivers
4
DispatchPlan v4 becomes committed
What gets sent

Vehicle assignment, ordered stops, planned ETAs, quantities, instructions and Plan version.

Audit trail: candidate scores → planner edits → override reasons → approval → acknowledgements → committed Plan version.
Route optimisation mental modelHuman-governed candidate selection and release flow
20 · Scenario 1 · Normal Day

A normal planning day still contains six user decisions

The system automates preparation and calculation. The planner remains responsible for interpreting operational risk.

FleetRobo learning lab
System

Creates today’s planning set from the Monday template and imports 12 pickup quantities.

Draft v1
Planner

Resolves one changed quantity and confirms three available vehicles.

Inputs ready
Planner

Protects four familiar assignments and selects “service first”.

Run configured
System

Returns three feasible candidates and explains the score differences.

Options A/B/C
Planner

Chooses B, swaps P6 after local-road knowledge and records the reason.

Draft v2
Supervisor

Approves the trade-off; transporter acknowledges vehicles and drivers.

Committed v3
System

Dispatches ordered routes and starts monitoring against Plan v3.

Live
System saved: calculation time and validation effort.Planner added: local knowledge and acceptable disruption.Organisation gained: a traceable commitment, not an unexplained route.
Route optimisation mental modelIllustrative day-before / shift-start scenario
21 · Scenario 2 · Before Dispatch

A new pickup and unavailable vehicle should trigger guided repair—not restart everything

This scenario happens after a candidate exists but before the Plan is committed.

FleetRobo learning lab
04:38 · Change arrivesNew pickup P13 · 350 L · window 06:10–06:35Vehicle MH04 marked unavailableCurrent candidate: 2 routes · all capacity nearly used
1

Impact preview

System highlights affected visits, capacity gap and likely late window.

2

Offer repair choices

A: add replacement vehicle · B: move P7/P8 · C: outsource P13 · D: defer with reason.

3

Planner selects scope

Unlock East cluster only. Preserve North cluster assignments and sequence.

4

Generate local candidates

Compare added cost, service risk, disruption and transporter availability.

5

Approve changed draft

Replacement MH09 accepted. Draft v3 records what changed from v2.

Before2 vehicles · 12 pickupsDraft v2
→
After2 vehicles · 13 pickupsDraft v3 · 1 replacement
Route optimisation mental modelIllustrative pre-dispatch demand and availability change
22 · Scenario 3 · Live Breakdown

After dispatch, the screen must protect physical reality

A vehicle breakdown is not another planning run. Completed work, current load, driver state and communication now constrain every option.

FleetRobo learning lab
06:32

MH01 breaks down

Current load: 1,050 L

Completed: P1, P2

Remaining: P3, P6

Driver confirms vehicle immobile

1
Confirm event

Breakdown, location, load safety and expected recovery time.

2
Freeze truth

Completed stops and current load cannot be reallocated as if untouched.

3
Find recovery options

Transfer load, send rescue vehicle, absorb stops, outsource or defer.

4
Compare operational impact

Service windows, cold-chain risk, driver hours, disruption and communication.

5
Approve repair

Supervisor selects rescue vehicle MH09 and transfers P3/P6.

6
Publish v4

Notify both drivers, transporter and customer-facing operations.

Plan v3Original committed route
EventBreakdown at 06:32
Plan v4Recovery assignment
ActualExecution evidence remains separate
Never: silently rewrite the old plan so history looks clean. Preserve what was committed, what changed, who approved it and what actually happened.
Route optimisation mental modelIllustrative post-dispatch recovery and versioning scenario
23 · Roles + State Model

Roles act on different decisions; Plan states prevent accidental commitment

The product needs permissions and state transitions because planning is a governed operational process, not collaborative drawing.

FleetRobo learning lab
DecisionPlannerSupervisorTransporterSystem
Resolve input issuesOwnsCan waiveSupplies truthValidates
Set objectives + locksOwnsGoverns—Suggests
Edit candidateOwnsReviews—Re-scores
Approve PlanProposesOwns—Blocks invalid
Acknowledge assignmentViewsEscalatesOwnsTracks
Live repairProposesApproves by policyConfirmsCalculates
1
Draft

Inputs and manual edits may change freely.

2
Validated

No blocking data or rule errors remain.

3
Candidate

Generated option; not an operational commitment.

4
Pending approval

Planner proposes a selected version.

5
Committed

Approved Plan; downstream dispatch may begin.

6
Dispatched

Assignments sent; acknowledgements tracked.

7
In execution

Started work creates a frozen physical horizon.

8
Revised

A newer approved version changes remaining work.

9
Completed / Cancelled

Closed with actual evidence and reason.

Key distinction: a solver candidate is not a Plan, an approved Plan is not a Trip, and a revised Plan must never erase the version that was originally dispatched.
Route optimisation mental modelRecommended roles, permissions and Plan lifecycle
24 · 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
25 · 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
26 · 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
27 · 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
28 · 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.