Route Optimization for Ethiopian Distribution Fleets

The dispatcher's hardest hour

Every morning, a dispatcher at an Ethiopian distribution company faces a planning problem. Deliveries need to go to 30, 50, sometimes 200 stops. Each truck has a capacity limit. Each driver has working-hour rules. Some stops have time windows ("must arrive between 09:00 and 11:00"). Some customers are priority.

The dispatcher solves the problem in their head, in an hour, producing a plan that's good but rarely optimal. The plan gets followed; deliveries happen. The next morning the dispatcher does it again.

Route-optimization algorithms solve the same problem in seconds, often producing solutions 5–15% better than the dispatcher's. Five to fifteen percent doesn't sound like much, but on a daily basis it compounds. Fuel savings, fewer overtime hours, more deliveries fit per truck, happier customers receiving on schedule.

This article walks through how route optimization works for Ethiopian distribution, what's required, and what to expect.

What route optimization actually does

The technical problem class is Vehicle Routing with Time Windows and capacity constraints (VRPTW). Inputs:

• A list of stops with addresses (lat/lon).
• Each stop's demand (volume, weight or units).
• Each stop's time window.
• Vehicle capacities.
• Driver shift rules.
• Depot location.
• Service time per stop.
• Travel-time matrix between every stop pair.

Output: a set of routes (one per vehicle) that visits every stop, respects every constraint, and minimizes total cost (fuel + time + overtime + opportunity cost).

The math is hard — VRPTW is NP-hard, meaning exact solutions for large instances take exponential time. Modern solvers use heuristics (simulated annealing, large-neighborhood search, hybrid approaches) to produce very-good-but-not-provably-optimal solutions in seconds.

The Ethiopian-context wrinkles

Several things complicate the textbook problem:

Road realities. Travel times between Ethiopian addresses depend on road quality, time of day, weather and unpredictable events. Static travel-time matrices computed from Google or OSM are starting points — but actual travel times often differ by 20-50%. Better implementations learn from actual delivery telemetry.

Address geocoding. Many Ethiopian customers don't have precise addresses. "Behind the Total station, next to the blue gate" works for a human courier but not for an algorithm. Implementations need to handle approximate or learned coordinates.

Time windows that aren't fixed. Time windows in Ethiopian operations are softer than in some markets. A "morning delivery" window has more flexibility than "between 09:00 and 10:30 sharp". Implementations need to handle soft constraints.

Last-mile reality. The driver's last 100 meters — finding the actual gate, getting paid, getting a signature — varies more in Ethiopia than in highly-formalized markets. Service-time estimates need to be calibrated from actual deliveries.

Multi-day routes. Some deliveries to distant regions require overnight stays. The optimization needs to handle multi-day shift scheduling, not just same-day return.

What the gains look like

In our Ethiopian deployments, well-tuned route-optimization for distribution typically delivers:

• 5–15% reduction in total kilometers driven vs the dispatcher's manual plan.
• 10–20% reduction in driver overtime.
• 5–10% more deliveries per truck per day on the same fleet.
• Better on-time performance on time-windowed deliveries.
• Faster planning — minutes instead of hours.

The gains compound across daily operations. A fleet of 20 trucks driving 5% fewer kilometers daily saves substantial fuel over a year.

What's required to make it work

Three preconditions:

1. Geocoded customer addresses. The address book needs lat/lon for every customer. NYLOS implementation typically includes a one-time geocoding pass with manual review for ambiguous cases.

2. Calibrated travel times. Generic map-API travel times are starting points but need calibration with actual telemetry. NYLOS implementations track actual GPS telemetry from delivery vehicles and feed back into the travel-time model.

3. Honest service-time estimates. How long does a delivery actually take door-to-door? This varies wildly between customer types — a corporate dock-delivery is different from a small-shop drop-off. Service times need empirical calibration.

Without these foundations, the algorithm produces plans that look great on paper but fail in practice.

The driver-side reality

Even with a great plan, the driver has to execute it. The driver app matters as much as the planning algorithm. NYLOS provides:

• The day's route on the driver's phone.
• Turn-by-turn navigation.
• Customer details for each stop.
• Service-completion checklist.
• Issue logging (no-show, refused delivery, partial delivery).
• Real-time updates to dispatcher.

Without the driver app, the plan can't adapt to reality during the day.

Mid-day adaptation

Reality changes during the day. A delivery takes longer than expected. A customer cancels. A truck breaks down. Static plans break. Dynamic plans adapt.

NYLOS supports mid-day re-optimization: when something disrupts the plan, the algorithm re-plans the remaining stops within minutes. The driver app shows the updated sequence.

Audit and accountability

For distribution operations with customer SLA commitments, route execution needs to be auditable. NYLOS preserves:

• The planned route per truck per day.
• The actual route driven (from GPS telemetry).
• Stop-by-stop arrival times, service times, completion outcomes.
• Variance analysis (where actual diverged from plan, why).

When a customer complains about a late delivery, the answer is one query away.

Common pitfalls

Five patterns to avoid:

1. Algorithm-only deployment. Route optimization without driver-app deployment is half a solution.
2. No telemetry feedback loop. The model needs to learn from actual travel times; static maps don't reflect reality.
3. Treating time windows as hard constraints when they're soft. Soft windows with priority weighting produce better real-world plans than hard ones.
4. No mid-day adaptation. Static plans fail; dynamic plans recover.
5. Optimizing only for distance. Time, overtime, customer priority and other factors matter too.

How NYLOS handles route optimization

NYLOS builds route optimization as an extension of the Sales, Marketing & Dispatch module — connected to the inventory, sales order and customer master data already in the platform. The implementation pattern: 1-week discovery to understand the operation, 2 weeks of geocoding and data prep, 2 weeks to deploy the algorithm and driver app, 1-2 weeks pilot before full rollout.

Read more

• [NYLOS AI & Automation](/solutions/ai-automation)
• [Multi-Warehouse Inventory Management in Ethiopia](/blog/multi-warehouse-inventory-ethiopia)
• [Demand Forecasting for Ethiopian Inventory](/blog/demand-forecasting-ethiopian-inventory)