What this guide covers
- What a route platform includes
- Constraint modelling
- Optimisation engine
- Live re-planning
- Driver execution
What is a route optimisation platform?
A route optimisation platform plans efficient multi-stop routes balancing distance, time, vehicle capacity, driver hours, and customer time windows.
Planners input stops, vehicles, and constraints, and the platform returns sequenced routes drivers can actually follow.
Feasibility is the test: routes ignoring road restrictions, service times, and driver breaks look efficient on screen and fail on the road.
Core features
Stop, vehicle, and constraint modelling
Stops carry location, time window, service duration, priority, and vehicle requirements, while vehicles carry capacity, equipment, shift times, and depot location. Constraints include driver hours, break rules, road restrictions, and zone assignments. Invalid data — ungeocodable addresses, impossible windows — is flagged before optimisation, not silently dropped.
Optimisation engine and scenario comparison
The engine sequences stops into routes minimising distance, time, or cost under the stated constraints, and planners compare scenarios — more vehicles versus longer routes, tighter windows versus looser ones — before committing. Optimisation settings expose the trade-offs: cost, service level, and workload balance are adjustable, not hidden defaults. Large plans run with progress feedback and partial results.
Territory and zone design
Recurring operations define territories and zones that balance workload and geography, reviewed as customer density changes. Zone boundaries respect natural barriers and road networks, and stops are assigned to zones before daily optimisation. Territory analytics show workload, distance, and service performance per zone over time.
Live re-planning and disruption handling
When traffic, cancellations, breakdowns, or urgent insertions occur, the platform re-plans affected routes without disturbing completed stops or violating remaining windows. Dispatchers preview re-plans before pushing them to drivers, and drivers receive updated sequences with change highlights. Re-plan history explains why a route changed.
Driver execution and mobile guidance
Drivers receive sequenced stops with navigation, customer notes, and proof-of-delivery capture, and their progress feeds back into ETAs for remaining stops. Actual arrival and service times are recorded per stop, building the data that improves future plans. Drivers report access problems and address corrections from the route.
Customer ETAs and notifications
Customers receive arrival windows derived from live route progress, updated as routes change, with notifications at dispatch and approaching-arrival stages. ETA accuracy is measured per stop, and systematic over- or under-estimation is corrected in the planning data. Customers can reschedule or add access notes within cut-offs that protect the route plan.
Analytics and continuous improvement
Reports compare planned versus actual distance, time, stops per route, and on-time performance, identifying zones, drivers, and stop types that deviate most. Service-time and travel-time assumptions are updated from actuals, so plans improve with use. Cost-per-stop trends by zone inform pricing and territory decisions.
How it is built
The build usually runs in phases, so each part can be tested before the next one starts.
- Operation and constraint definition. Define stop types, vehicle fleet, time windows, service durations, driver rules, and road constraints before building, since these are the optimisation inputs.
- Modelling, engine, and scenario build. Build stop and vehicle modelling with validation, the optimisation engine, and scenario comparison. Test with historical stops and compare plans against actual past routes.
- Execution, re-planning, and ETA build. Add driver execution apps, live re-planning, and customer ETAs, then pilot in one territory with real drivers and compare planned versus actual performance.
- Rollout and data refinement. Roll out territory by territory, refine service-time and travel-time assumptions from actuals, and review zone design quarterly as density changes.
Technology considerations
Optimisation quality depends on input data quality more than algorithm sophistication: geocoding accuracy, service-time realism, and travel-time data determine whether plans are usable. Invest in address validation and actuals-based calibration before tuning solver settings, and validate plans with experienced dispatchers who know the territory.
Travel-time modelling should use historical and live traffic data per road segment and time of day, not straight-line distances or fixed speeds. Plans built on average speeds fail at rush hour, so test optimisation outputs against peak and off-peak conditions separately.
Re-planning must be fast and stable: drivers cannot wait minutes for a new route, and constant small changes confuse execution. Design re-planning to run in seconds, to preserve completed stops, and to highlight only what changed for the driver.
Challenges to plan for
Plans drivers cannot follow
Ignoring service times, breaks, and road restrictions produces routes that look optimal and fail. Validate plans with dispatchers and drivers before rollout.
Bad address data
Wrong pins and ungeocodable addresses break optimisation. Validate at input, let drivers correct locations, and feed corrections back.
Re-planning chaos
Frequent, unexplained route changes confuse drivers. Preview re-plans, highlight changes, and preserve completed stops.
ETA promises the route cannot keep
Static ETAs go stale as routes change. Derive ETAs from live progress and measure accuracy per stop.
Cost and timeline
Costs vary widely with scope, integrations, and design quality, so treat any figure here as a typical range only: a basic version often lands in the low thousands of dollars, while a fully integrated build with custom workflows can run several times that. Timelines commonly run from a few weeks for a lean launch to a few months for a complete platform. Confirm both with a written quote scoped to your exact requirements before committing.
Frequently asked questions
What inputs does optimisation need?
Stops with locations, windows, and service times, vehicles with capacity and shifts, and constraints including driver hours and road restrictions.
How are scenarios compared?
Planners compare plans on distance, time, cost, vehicles used, and service level before committing, adjusting trade-offs such as workload balance.
What happens when a disruption occurs?
Affected routes re-plan without disturbing completed stops, dispatchers preview the change, and drivers receive updated sequences with highlights.
How accurate are customer ETAs?
ETAs derive from live route progress and update as routes change. Accuracy is measured per stop and used to correct planning assumptions.
Do plans improve over time?
Yes. Actual arrival and service times feed back into travel-time and service-time assumptions, and zone design is reviewed as density changes.