Standard route-optimisation tools assume addresses that geocode cleanly, road networks that are well mapped and travel times that behave predictably. In many Tier-2 Indian cities those assumptions do not hold reliably. Addresses are descriptive rather than indexable, lane-level map data is patchy, traffic varies sharply by hour and day, and drivers carry local knowledge the model does not. Here is an AI dispatch pattern that works in Lucknow, Indore, Kanpur, Coimbatore and similar markets.
Why standard routing assumptions break
- Address resolution. "Behind the SBI ATM, near the temple, ask anyone for Sharma Sweets." Geocoding APIs fail or return a locality centroid. Drivers find the place; the model can't.
- Last-mile time variance. The final stretch — narrow lanes, finding parking, locating the building, climbing stairs — can take longer than the drive itself, and it varies by neighbourhood. ETA models trained on metro data, or on drive time alone, are often badly off.
- Customer availability windows. Many customers expect a call before delivery. Arriving without a heads-up leads to more failed attempts.
- Driver autonomy. Drivers know which gali to skip on a Friday afternoon. Purely algorithmic dispatch that overrides their judgement loses driver trust quickly.
The pattern that works
- Two-stage geocoding. Run a geocoding API first. If confidence is low, fall back to the last successful delivery coordinate for that address or customer from your own database. Over time, build your own address book from drivers' actual drop points.
- City-specific ETA models. Train a separate ETA model per city or cluster, and model service time (parking to handover) separately from drive time. Don't use a single national model.
- Pre-delivery contact built into the route. The driver app prompts a WhatsApp message or call shortly before arrival, and the customer's reply — available, reschedule, leave with a neighbour — feeds straight back into the sequence.
- Driver-suggested routing. The algorithm proposes a route; the driver can override it with one tap and a reason code. The reason codes become training data.
Where AI helps, and where classic optimisation does the work
Be precise about which tool does what. Deciding which vehicle takes which stops, in what order, within time windows and capacity limits, is a vehicle routing problem, solved with operations-research methods such as Google's OR-Tools routing library. Machine learning improves the inputs to that solver: ETA and service-time predictions, and the probability that a delivery succeeds at the first attempt. Language models handle the messy text: parsing and normalising descriptive addresses, matching them to known locations, and turning free-text and voice notes from drivers into structured reason codes.
Mobile app design notes
The driver app is your data-collection surface. Make it offline-first, because connections drop in basements, markets and older buildings. Keep input minimal: one-tap reason codes and voice notes rather than forms. Ship it in the languages your drivers actually use. An app drivers find easy keeps them using it properly; a confusing English-only one pushes them to workarounds, and your data quality falls with it.
What the dispatch model should optimise
Don't optimise pure distance. Optimise expected completed deliveries per shift. A route that is a few kilometres longer but avoids a cluster of hard-to-find addresses at peak hour may deliver more parcels on time. Driver hours are usually the binding constraint, not kilometres.
A worked example
Take a hypothetical fleet of 40 riders in one city, each with around 30 drops a day — 1,200 drops in total. Suppose 15% fail at the first attempt, mostly because the customer is unavailable or the address can't be found. That is 180 failed drops a day, each costing a second trip and a day's delay. Pre-delivery confirmation and a learned address book attack both causes directly; if they remove even a third of those failures, the same riders complete 60 more deliveries a day. Measure your own baseline first so you can see the change.
Per-vehicle and per-shift patterns
Two-wheeler and four-wheeler dispatch follow different optimisation logic. Bikes handle narrow lanes and short stops well; vans suit clusters of larger parcels and bulk drops. Morning and evening shifts also face different traffic and customer availability. Ship separate dispatch policies rather than forcing one to cover everything.
Metrics to track
- First-attempt delivery rate by city, zone and vehicle type.
- ETA error — predicted versus actual — including service time.
- Driver override rate and the most common reason codes.
- Deliveries per driver hour.
A rising override rate in one zone is a signal: either the map data is wrong there, or the drivers know something the model doesn't.
FAQ
Do we need a custom routing engine?
Rarely. Proven solvers handle the optimisation; the advantage comes from better inputs — cleaner addresses, local ETAs and feedback from drivers.
How long before the learned address book helps?
It starts helping as soon as repeat customers appear, and improves with every successful drop. Dense urban routes with repeat buyers benefit first.
How we approach this at Velura Labs
Our mobile app development service ships driver apps with offline-first sync, multilingual interfaces and one-tap reason codes. The language-heavy parts — address parsing and note classification — come from our custom LLM applications work, alongside conventional routing and ETA models. Read our Bharat design patterns for the broader UX framing. Talk to us if your reattempt rate is climbing despite a dispatch system being in place.
We ship work like this for clients in the US (California, Texas, Washington, New York), across Europe (France, Italy and the EU), the Gulf (UAE and Saudi Arabia) and India — with an India delivery base that keeps cost down and time-zone overlap high. Talk to us.