Rider Dispatch and Route Planning in Kathmandu
Logistics, courier & cargo7 min read
Route optimisation built for grid-planned cities fails in Kathmandu. What actually improves deliveries per rider per day in Nepali conditions.
Every logistics vendor sells route optimisation. Most of it is built on assumptions that do not hold in Kathmandu: that addresses geocode reliably, that road networks are mapped accurately, that travel time is a function of distance, and that a rider follows the sequence the algorithm produced.
None of those are true here. Which does not mean dispatch cannot be improved — it means the improvements come from somewhere else.
The constraint is not distance
In a city with reliable addressing and predictable traffic, the optimisation problem is a travelling salesman problem and shortest-path routing wins real time.
In Kathmandu the binding constraints are different:
- Finding the address. A meaningful share of delivery time is spent locating a place from a landmark description and a phone call, not travelling to it.
- The customer being available. A perfectly routed delivery to someone who is not home is a wasted trip and a reschedule.
- Traffic that is time-dependent, not distance-dependent. The same two kilometres is five minutes or forty depending on hour and route.
- Rider knowledge. An experienced rider on a familiar zone beats an algorithm on an unfamiliar one, consistently.
Optimising distance when the constraint is address-finding produces a beautiful route that takes longer.
Zones beat routes
The single highest-leverage change most couriers here can make is not route optimisation. It is stable zone assignment.
Give riders consistent geographic zones and keep them there. Within a few weeks a rider knows the lanes, the landmarks, the building names that do not appear on any map, the shopkeeper who accepts parcels for the flats above, and which customers are reliably home in the morning.
That accumulated local knowledge is worth more than any routing algorithm, and it compounds. A rider rotated across the valley every week never accumulates it.
The system’s job is to support this: zones as first-class objects, riders assigned to zones, consignments auto-assigned to the zone that covers their locality, and a locality-to-zone mapping that operations staff can correct as they learn.
Call ahead, and record the outcome
The cheapest improvement available to most couriers is calling before delivery. It converts a failed trip into a rescheduled one before the trip happens.
For this to be more than a habit, the system has to record it:
- Attempted call, and the outcome — answered, no answer, number unreachable, wrong number
- Customer’s stated availability window
- Any address correction given on the call
The address corrections are the valuable part. A customer who explains where they actually are should never have to explain it again. If that correction lives in the rider’s head or a WhatsApp message, it is lost. If it updates the customer record, the next delivery to that address is faster for whoever takes it.
Sequence as a suggestion, override as data
Riders will reorder their runs. They should — they know things the system does not.
The mistake is treating this as non-compliance. The right response is to let riders reorder freely, record what they actually did, and compare it to what was suggested. Persistent deviation in one direction is information: either the zone mapping is wrong, or the traffic assumptions are wrong, or two localities that the system thinks are adjacent are separated by a river crossing.
A system that fights its riders loses. A system that learns from them gets better every week.
Load, not just count
Assigning 40 parcels to each rider treats all parcels as equal. They are not. A rider carrying three bulky items and a cash-heavy COD run has a very different day from one carrying 40 documents.
Assignment should account for:
- Piece count and rough volume, because a motorcycle has a hard physical limit
- COD cash total, because a rider carrying a large amount of cash is a risk and often has to bank mid-route
- Delivery type mix — a run with several bulky items needs a different vehicle
- Reattempts, which are usually faster than fresh deliveries because the address is already known
Measure the right thing
Deliveries per rider per day is the headline number, but on its own it drives bad behaviour — it rewards skipping the hard addresses.
Better set:
- First-attempt success rate. The number that actually matters. Everything else follows from it.
- Average attempts per delivered consignment. Should be trending toward one.
- Time from arrival at branch to out-for-delivery. Dwell time at the branch is invisible and often large.
- Reschedule-to-delivery conversion. How many rescheduled parcels eventually deliver rather than becoming returns.
- Return rate by zone and by merchant. Some of it is geography; a lot of it is a specific merchant’s order quality.
That last one is worth separating carefully. A merchant with an unusually high return rate is usually not a delivery problem — it is a merchant taking orders from customers who do not intend to pay, and it is a commercial conversation, not an operations one.
What to build first
If you are improving dispatch, the order that tends to pay back fastest:
- Stable zones and rider-to-zone assignment
- Locality-to-zone mapping that operations can edit
- Address corrections persisted on the customer record
- Call-ahead outcomes recorded as structured data
- First-attempt success rate visible per rider, per zone, per merchant
Route sequencing comes after all of those, and by then you will have the data to make it actually work.
We build the logistics software that couriers and cargo operators in Nepal use for zone assignment, rider dispatch and delivery tracking. If your dispatch is a whiteboard and a group chat, talk to us.
Read next
- Cash on Delivery Reconciliation for Courier Companies in NepalWhy COD reconciliation breaks down at scale in Nepal, and what a courier's software has to track to close the books daily instead of weekly.
- 3PL Software in Nepal: Running Logistics for Other People's GoodsServing multiple merchants under different rate cards and SLAs needs multi-tenancy, not a bigger courier system. What third-party logistics software must handle.
- Designing Tracking Numbers That Do Not Break at ScaleTracking number schemes fail in predictable ways: collisions, transcription errors, and numbers that leak volume. How to design one that lasts.
