Route optimisation vs dispatch rules: what actually matters
What should you know about route optimisation logistics?
Dispatch rules and area batching deliver most of the gain; pure route optimisation matters only after the operation runs on data. Fix how work is grouped and assigned first, capture actual addresses, times and outcomes, and only then buy or build a routing algorithm, which is only as good as the data beneath it.
Route optimisation logistics vendors sell a solver: give it stops, vehicles and constraints and it returns the shortest set of routes. It is genuinely clever mathematics. It is also, for most operators in India and similar markets, the wrong first purchase. The gains that matter come from dispatch rules, area batching and clean data, and a solver applied to bad addresses and guessed service times will produce routes drivers ignore. This article explains the difference, what to fix first, and when the algorithm earns its place.
What dispatch rules are and why they come first
Dispatch rules are the plain logic that decides which orders go to which hub, which area, which vehicle type and which driver, and in what order. Examples: batch orders by pin code cluster; assign a driver to the area they know; keep a customer's regular delivery with the same person; put time-window orders first; cap a two-wheeler at a weight and a count. None of this needs an optimiser. All of it needs an operations manager who can write the rules down and a platform that applies them consistently.
Most operators run these rules in a dispatcher's head. The first improvement is to move them into software, apply them every day the same way, and measure the result. That alone removes a large share of the wasted kilometres, because the waste was never mainly in stop order; it was in the wrong driver going to the wrong area with the wrong mix of parcels. Our logistics industry page covers the platforms that make this possible.
Rules versus optimisation: a comparison
| Question | Dispatch rules and area batching | Route optimisation solver |
|---|---|---|
| What it decides | Which orders go to which area, vehicle and driver | The order of stops and the split across vehicles |
| Data it needs | Pin codes, vehicle capacity, driver areas, time windows | Geocoded addresses, travel-time matrix, service times, all constraints |
| Sensitivity to bad data | Low; a wrong pin code affects one order | High; wrong coordinates or service times distort every route |
| Driver acceptance | High when rules match how drivers already think | Low unless drivers trust the sequence; often re-ordered manually |
| Time to value | Weeks, once rules are written down | Months, after addresses and times are clean |
| Where it wins | Dense urban last mile, mixed fleets, recurring customers | Long multi-drop routes, tight time windows, high-value vehicles |
Why optimisation fails on an operation that does not run on data
Addresses
Delivery route planning depends on coordinates. In much of India an address is a landmark, a floor and a phone number, and the geocoded point can be hundreds of metres off. A solver treats that point as truth and builds a sequence around it. The driver, who knows the building is behind the temple and not on the main road, ignores the sequence. Operators that capture the actual delivery location from the driver app, and correct the geocode for the next visit, are the ones for whom optimisation eventually works.
Service times
How long a stop takes depends on the building, the customer and the parcel. Solvers assume a service time per stop, and if it is a guess, the whole plan is a guess. Capturing arrival and departure per stop from the driver app for a few months gives real distributions per area and customer type, which is the input a solver actually needs.
Constraints nobody wrote down
Vehicles that cannot enter certain roads, customers who refuse deliveries after a certain hour, drivers who finish early on Fridays, hubs that close for lunch: a solver that does not know about them produces routes that look efficient and are impossible. Rules-based dispatch surfaces these constraints because dispatchers add them one at a time as exceptions.
Dispatch optimisation that actually moves the numbers
In our experience the sequence that works is: rules in software, then area batching, then measurement, then targeted optimisation. Each step is worth doing on its own.
- Rules in software: encode the assignment logic and apply it automatically, with a dispatcher override that is logged so you learn where the rules are wrong
- Area batching: group orders into stable delivery areas, assign drivers to areas they know, and rebalance areas weekly from volume rather than daily from whim
- Measurement: capture arrival, departure, outcome and actual location per stop, and report kilometres, stops per hour and failed attempts per driver and area
- Targeted optimisation: apply a solver only where the data shows the problem is stop order, such as long routes with time windows or a mixed fleet with capacity limits
The dispatcher override is the most useful data you will collect. Every time a person changes an assignment, they are telling you something the rules do not know. Reviewing overrides weekly is how the rule set gets better; we described the engine side in dispatch and routing engines.
When a routing algorithm is worth it
A routing algorithm in India or anywhere else pays for itself when three things are true: addresses are geocoded from actual delivery locations, service times come from measured history, and the constraints have been captured as data rather than folklore. At that point the solver has something to work with, and the gain shows up as more stops per vehicle-hour on long routes and fewer time-window misses.
You do not need to build the solver. Open-source engines such as OR-Tools on GitHub handle vehicle routing with capacity and time-window constraints well, and commercial APIs exist for teams who prefer not to run one. The build work is in the integration: feeding the solver clean inputs, presenting its output in the driver app in a way drivers accept, and measuring whether they follow it. A solver whose routes are re-ordered by every driver is not optimising anything.
What to measure before and after
Route optimisation vendors quote savings on kilometres. Kilometres are one input, and a fleet that drives fewer of them while missing more time windows has not improved. The measures that reflect the operation are stops per vehicle-hour, first-attempt delivery rate, time-window compliance, and the share of dispatcher overrides. Baseline these for a month under rules-based dispatch before switching on any optimisation, so the improvement, if any, is attributable. Without a baseline every vendor's number is unfalsifiable.
A worked example
A last-mile operator came to us asking for route optimisation. Dispatch was done by hub supervisors from memory, addresses were free text, and drivers had no app, so there was no record of where deliveries actually happened or how long they took. We did not start with a solver. The dispatch platform and offline-first driver app encoded the supervisors' rules, batched orders by area, and captured arrival, departure and location at every stop.
Within the first months the operator had a measured baseline, corrected geocodes for a growing share of repeat addresses, and a weekly override review that kept tightening the rules. Optimisation was introduced later, on the longer routes only, where the data showed stop order was the constraint. The team's own summary was that the platform and the rules delivered the change they had expected from the algorithm.
Team and timeline
A rules-based dispatch platform with a driver app is a six-week build under the fixed-price Launch 6 programme at $26,500–45,500 or from ₹17,60,000. The team is a backend engineer for the dispatch engine and rules, a mobile engineer for the driver app, a designer, and a delivery lead who spends the first two weeks with hub supervisors writing rules down. Adding a solver later is a separate, smaller phase, scoped as AI and ML development from $17,500 or ₹11.2L, and only once the data is in place.
If the rules and constraints are unclear, a Sprint Zero at $3,250 or ₹2,00,000 produces the rule set, the data model and a priced plan, credited against the build. Full programme and service pricing is on the pricing page.
Before you start: a checklist
- Write down the assignment rules your best dispatcher uses today
- Define delivery areas and which drivers own them
- Confirm the driver app can capture arrival, departure, outcome and GPS location per stop
- Decide how dispatcher overrides are logged and reviewed
- Baseline stops per vehicle-hour, first-attempt rate and time-window compliance
- Identify which routes, if any, are long enough for stop-order optimisation to matter
- Agree who owns the weekly rule review
Glossary
- Dispatch rules: explicit logic deciding which orders go to which hub, area, vehicle and driver
- Area batching: grouping orders into stable delivery zones assigned to drivers who know them
- Service time: the time a stop takes from arrival to departure
- Travel-time matrix: estimated travel time between every pair of stops, the main input to a solver
- Vehicle routing problem: the mathematical formulation a routing algorithm solves
- Dispatcher override: a manual change to an automated assignment, and the best signal for improving rules
Related reading
See AI in logistics: dispatch, exceptions and customer updates for what sits on top of a dispatch platform, building an offline-first driver app for the data capture side, and integrating TMS, ERP and telematics for connecting existing systems.
Put the rules in software, capture what actually happens at the doorstep, and buy the algorithm only when the data says stop order is the problem.
Frequently asked questions
Do we need route optimisation software for last-mile delivery?
▾
Not at first. Rules-based dispatch and area batching deliver most of the gain in dense urban operations. A solver is worth adding once addresses, service times and constraints are captured as data.
Which routing algorithm works in India?
▾
Any capable vehicle-routing solver works if its inputs are real: geocodes corrected from actual deliveries and service times from measured history. The algorithm is rarely the constraint; the data is.
How do we know if optimisation is helping?
▾
Baseline stops per vehicle-hour, first-attempt rate and time-window compliance under rules-based dispatch for a month, then compare after switching on the solver for specific routes.