The Problem
Every bike dispatched with a van was money on fire
Before MMOT, last-mile dispatch at Amazon India operated on blunt rules. Vans for large orders. Bikes for small ones. The threshold logic was static — it couldn't see real-time fleet availability, couldn't account for geocode-level delivery density, and couldn't factor in whether a nearby bike was already heading in the right direction.
The result: over-dispatching. Vans running half-empty routes that bikes could cover. Bikes turned away from orders they could handle. Delivery windows missed not because drivers were slow, but because the wrong vehicle was assigned to the wrong order from the start.
At Amazon's scale — hundreds of thousands of daily dispatches across 5 markets — even a 5% improvement in vehicle matching translates to millions of dollars annually.
The Engine
How MMOT makes the decision in real time
MMOT processes three classes of signal for every order at the moment of dispatch:
🛵
Bike
Small packages · High-density routes · Sub-3km radius · Fast turn
🚐
Van
Mid-size orders · Mixed routes · Consolidated deliveries · Scheduled slots
🚛
Truck
Large / heavy · B2B nodes · AMXL · Out-of-area delivery windows
- Geocode signal: Delivery address mapped against real-time route density — is there a cluster of orders within 500m? A bike with two adjacent stops beats a van covering the same ground empty.
- Product attributes: Dimensions, weight, fragility, and category fed into vehicle eligibility rules. Not just "large = van" — a light but bulky item might still be bike-eligible with the right packaging constraint.
- Real-time fleet utilisation: Live visibility into which vehicles are available, their current load, and their position — so the routing decision is made against actual fleet state, not a theoretical dispatch table.
Design principle
MMOT is deliberately not a black-box ML model. Dispatchers can see the rationale for every assignment — which signals drove the decision, and what threshold the order crossed. This was critical for adoption: dispatch teams trust a system they can interrogate, not one that just says "trust me."
Multi-Market Rollout
Same platform, five different market realities
Rolling MMOT across India, UAE, KSA, Qatar, and Japan wasn't a simple copy-paste. Each market had different fleet compositions, different regulatory constraints on vehicle categories, and different driver-app integrations.
- India: High bike density, extreme geocode variety (dense city centres vs. suburban sprawl), monsoon seasonality affecting bike eligibility windows
- UAE/KSA/Qatar: Higher van-to-bike ratio, different 3PL relationships, Arabic-language driver app requirements, customs considerations for cross-emirate delivery
- Japan: Strict time-slot delivery culture requiring MMOT to optimise for punctuality over cost, different vehicle category definitions, high-precision geocoding requirements
The platform architecture was built to be market-configurable from day one — routing thresholds, vehicle eligibility rules, and fleet weightings are all market-level parameters, not hard-coded logic.
Results
Fleet efficiency, at scale
- 12% fleet utilisation improvement — fewer empty vehicle-miles, better load factor per dispatch across the network
- $MM+ annual savings — direct cost reduction from eliminated over-dispatching and improved route consolidation
- Live in 5 markets — India, UAE, KSA, Qatar, Japan — from a single platform with market-level configuration
- Named product with longevity — MMOT is still live and being extended, not replaced — a sign the architecture held up
Routing EngineML / AIFleet OperationsLast-MileMulti-marketReal-time SystemsCost Optimisation
Related Work
Other projects from this era