RouteSync did not start as a product. It started as a specification written against the way one ITC wholesale distributor in Hyderabad actually runs its last mile — and every feature in it survived a real operator, real drivers and real order files before it was called finished.
The distributor receives orders through ITC’s Trishul system and delivers them to roughly twelve hundred kirana shops across the city. Vans go out each morning; each driver covers around thirty retailers on a run, sometimes making a second trip after lunch.
The dispatch-and-monitor part of that operation ran entirely on paper and phone calls. A salesman printed the day’s order list, decided which orders were physically ready, grouped them by beat, and wrote out the stop order from memory. Once a van left the warehouse there was no way to know where it was or which shops had been served, other than calling the driver. Deliveries were confirmed verbally. Nothing about the day was measurable afterwards.
The beat system — retailers grouped into fixed weekly routes — was doing a job it was never designed for. It existed so a human could remember roughly where shops were. It was being used as the planning constraint, which meant a van’s load had nothing to do with the day’s actual orders. Quiet days went out at a third full. Peak days were overloaded and nobody could tell until the van was on the road.
The scope was deliberately narrow: replace the dispatch-and-monitor portion of the flow, leave the ERP alone as the source of commercial truth, and give each person exactly the screen they need.
Onboard distributors, manage the shared product catalogue, and see every distributor’s day in the same shape.
Import, plan, dispatch, track, report. The operator’s whole day lives here.
Installable on any Android phone, in English, Hindi or Telugu. Stops, navigation, OTP confirmation, GPS capture.
Fix a wrong retailer pin, mobile number or address from the field, with a photo and a GPS accuracy reading.
The first version gave the operator better information — road distances, retailer coordinates, order weights — and let him sequence the trip himself. It worked, and it was faster than paper. But it still asked a person to solve a clustering problem every morning.
These are the things that were not in any specification. They came from watching the system meet real drivers, real shopkeepers and real Tuesday afternoons — and they are the reason the product holds up.
No nightly rollover, no auto-cancelling of stale trips. The dashboard detects a stuck state and offers a button; the record only changes when a person clicks it. Silent corrections destroy an operator’s trust faster than bugs do.
The driver app speaks English, Hindi and Telugu — but every stored status, role and code stays in English. Reports, queries and audits are identical no matter what language the driver picked.
We investigated complaints that driver GPS was “kilometres off.” Around nine in ten fixes were accurate to within fifty metres. The largest apparent errors were good GPS readings sitting far from a wrong retailer pin — a master-data problem wearing a GPS costume. That finding produced the field pin-correction queue.
It would have been easy to build monitoring dashboards. We deliberately didn’t. The effort went into making the app accurate and fast for the drivers who use it properly — which is a better lever than watching the ones who don’t.
A driver marks a stop delivered by accident. An operator closes a trip with orders still attached. Both got an explicit correction path in the UI, because the alternative is a support request and a hand-written SQL statement.
Road distance between two fixed shops never changes. Caching it permanently, and invalidating only when a pin is edited, turns mapping from a per-trip cost into a one-time one. It is the difference between a product that scales to fifty distributors and one that doesn’t.
The pilot distributor runs its full delivery day on RouteSync — import to dispatch to proof of delivery to report — with the same fleet and the same people.
Screen values shown throughout this site are representative of the pilot instance. In a walkthrough we’ll show you live figures and explain exactly how each one is computed.
There is no pilot version and production version. Scaling is an onboarding sequence, not a rebuild, and every distributor added runs the identical codebase on the identical schema.
Code, name, city and warehouse coordinates — the origin point for every distance the system computes.
One primary user with the distributor role. Login is a mobile number; password resets are admin-side.
Registration, rated weight and volume, and whether each one participates in auto-routing.
Mobile number is the login. Import the retailer master, and the distributor is ready to plan its first day.
Send one day’s order file and your vehicle list. We’ll plan it on the live system and walk you through what came out — including whatever didn’t fit, and why.