Route optimisation in Jordan has a prerequisite most software ignores: you cannot optimise routes until you can reliably resolve a descriptive address to a coordinate.
The core insight was that the addressing problem had to be solved before the routing problem. An optimiser fed unreliable coordinates produces confident nonsense.
Building a usable location layer
We built a location resolution service that combines whatever signals are available: a map pin where the customer provided one, a landmark description matched against a growing gazetteer of Jordanian reference points, and historical delivery coordinates for repeat addresses.
Every successful delivery improves the dataset. After four months the system could resolve roughly 89% of addresses to a usable coordinate without human intervention, against about 40% for the previous product.
Routing that reflects the day
The optimiser accounts for vehicle capacity, driver hours, delivery windows, and observed travel times by corridor and time of day — learned from the fleet's own GPS history rather than from generic map data.
Because a meaningful share of deliveries are cash on delivery, the model also treats cash carried per vehicle as a constraint, which the previous system had no concept of.
Keeping dispatchers in control
The system proposes routes; dispatchers can override any assignment. This mattered for adoption — the dispatchers held genuine local knowledge, and a tool that ignored them would have been ignored in turn. Overrides are logged and fed back, which has improved the model measurably.
