In short: Last-mile delivery in Kenya is the final movement of goods from a merchant to a customer's door, almost always on a motorcycle, in a city with few usable street addresses. A delivery passes through five stages — creation, assignment, collection, transit and handover — and each one either creates a record or creates a dispute. The operators who make it work reliably do three things: they route by corridor rather than by zone, they batch scheduled work instead of chasing single jobs, and they generate proof at both ends of the journey rather than only at the door.
Why Kenya's last mile is its own problem
Every market has a last mile. Kenya's has four characteristics that make imported playbooks fail.
Addresses are descriptive, not systematic. Most Kenyan delivery destinations are not a house number on a named street. They are a landmark, a building, a floor, a shop name and a phone number — "Ronald Ngala Street, opposite the mosque, second floor, ask for Kimani". No routing algorithm resolves that on its own. Every serious operation in this market is, in practice, a hybrid of software and a phone call, and the operators who pretend otherwise generate failed deliveries.
The motorcycle is the vehicle. Not a compromise, a genuine advantage. A boda moves through traffic that stops a van, reaches roads a van cannot use, and costs a fraction as much per drop. The trade-off is capacity — you are designing around a load of roughly 20 to 30 kilogrammes and a box, not a pallet.
Payment and delivery are entangled. M-Pesa made it normal for money to move at the moment of handover rather than at checkout. That is why pay on delivery remains a dominant expectation in Kenyan commerce, and why a delivery operation here is also, unavoidably, a payment-handling operation.
Trust is the scarce resource. Not speed, not price. Merchants have been trained by years of informal arrangements to expect that a parcel handed to a rider is a parcel they can no longer account for. That expectation, more than traffic or fuel, is what actually limits how much commerce moves.
The five stages of a delivery
Every delivery, however it is dressed up, passes through the same five stages. What separates operators is how many of these stages produce a record.
Stage 1 — Creation
A delivery job is created, either by a merchant in a dashboard or automatically from a storefront through an API. This is where the pickup point, the destination, the recipient's details and the declared contents and value are captured.
Contents declaration is not optional housekeeping. Under Kenya's courier framework, senders must be able to declare contents, and operators must maintain records of all articles handled and produce them to the Communications Authority, the Kenya Revenue Authority or law enforcement on request. A delivery record that says "goods" is a record that fails at exactly the moment it is needed. Make the declared-contents field mandatory in whatever system you use.
Stage 2 — Assignment
The platform assigns a rider. On a well-run operation this is not simply "nearest available". It weighs the rider's current position and direction of travel, the corridor the job sits on, existing jobs on that run, the parcel profile, and whether the rider is verified for the category of goods involved.
Assignment speed is the metric most operators advertise. It is the least important of the three. A rider assigned in two minutes who then spends forty minutes crossing the city against the grain is a worse outcome than a rider assigned in eight who was already heading that way.
Stage 3 — Collection
The rider arrives, inspects the parcel against the declaration, and takes custody.
This is the stage most operations leave unevidenced, and it is the single most consequential gap in Kenyan last-mile delivery. If the first record of a parcel is created at the customer's door, then everything between the merchant's counter and that door is unaccounted for. Every dispute about a parcel that never arrived becomes an argument about whether it ever left. Neither party can win it, which means the merchant absorbs it.
A collection that generates its own authenticated record — in our case a one-time PIN confirmed at the counter before the rider departs — converts that argument into a lookup. It also satisfies a practical regulatory point: the framework requires the state of an article to be verified at both acceptance and delivery, not only at handover.
Stage 4 — Transit
The rider moves. The merchant and the customer both see live position. The operations desk watches for exceptions — a stalled job, a rider off-corridor, an approaching SLA breach — and intervenes before the customer notices rather than after they call.
The distinction worth drawing here is between tracking and monitoring. Tracking is showing a dot on a map to a customer. Monitoring is somebody whose job is to notice when the dot stops moving. Most platforms do the first. The second is what actually protects a delivery window.
Stage 5 — Handover
The rider arrives, the recipient's identity is confirmed, the parcel changes hands, and the record closes.
Where the delivery is pay-on-delivery, this is also where money moves — collected at handover and reconciled against the delivery record, not held ahead of it. Tying the payment event to the same confirmation that closes the delivery means the two can never disagree in your books, which is a reconciliation advantage that compounds quietly over thousands of orders.
Corridors, rings and zones: the part most operators get wrong
Here is the piece of operational architecture that separates a delivery business that scales from one that merely grows.
Most Kenyan delivery operations use a single spatial scheme — "zones" — for three different jobs: deciding how a rider moves, deciding what a delivery costs, and reporting to the client. Collapsing those three into one map is why so many operations look profitable on a spreadsheet and lose money in the field.
They are three different geographies.
The corridor is how the rider moves. Nairobi radiates outward along a small number of arterial roads. A rider heading up Limuru Road can drop in Ngara, Parklands, Gigiri, Ruaka and Kabete on a single run because those places are beads on one string. A rider crossing between two corridors is fighting the city's shape. We plan against nine corridors out of the centre — Limuru Road, Thika Road, Mombasa Road, Waiyaki Way, Ngong Road, Langata Road, Jogoo Road, Eastern Bypass and Kiambu Road — and each behaves differently enough that treating them as interchangeable is a costing error.
Average achievable speeds vary by a factor of more than two across those corridors. In our routing model, Thika Road and the Eastern Bypass plan at roughly twice the throughput of Ngong Road or Jogoo Road. A flat "Nairobi average speed" therefore over-promises on the slow corridors and under-uses capacity on the fast ones. (These are planning assumptions used in our own routing model, not published measurements.)
The ring is what it costs. Distance bands from the dispatch origin — roughly 0 to 12 km, 12 to 25, 25 to 40, and beyond 40. Cost tracks distance and time. It does not track the client's mental map.
The zone is what the client calls it. Useful for reporting, invoicing and conversation. Useless for routing or pricing, because client zones are drawn around commercial relationships rather than around geography. A single "Kiambu" zone can contain a destination 14 km out and another 35 km out — same label, radically different cost.
Keep the three separate and you can route by corridor, price by ring, and report by zone without any of the three corrupting the others. Collapse them and you will systematically underprice long destinations inside near-sounding zones, which is precisely the error that quietly destroys margin.
On-demand versus scheduled: where the economics actually live
There are two ways to sell last-mile delivery in Kenya, and they are not variants of each other. They are different businesses.
On-demand, point-to-point. A job appears, a rider is dispatched for it alone, the rider returns. Simple to sell, simple to operate, and structurally expensive — the customer pays for the outbound leg, the return leg and the dispatch overhead, all attributed to one parcel.
Look at how point-to-point operators price and you can see the shape of the business in the numbers. Their rate cards, whatever zone names sit on top, resolve almost perfectly to a base fee plus a per-kilometre rate. The zones are cosmetic. The pricing is linear, forever, because the cost is linear, forever.
Scheduled and batched. The run goes out anyway. The corridor is being served regardless. Each additional drop on a run already in motion carries only its own marginal cost — the incremental stop — rather than a share of the outbound and return legs.
The gap between marginal and average cost per drop is the entire economic argument for scheduled delivery, and it is large. On our own model the marginal cost of an additional drop on an existing run is roughly two thirds of the average cost per drop across the run. That difference is not a discount the operator is choosing to give. It is a genuinely different cost structure, and it is the only honest way to sell aggressive price points without underpaying riders.
Which leads to a conclusion worth stating plainly for anyone building or buying in this market: if an operator is quoting point-to-point rates well below the market, the money is coming out of the rider. There is no third source. The rider absorbs it in unpaid waiting time, in fuel, or in the maintenance they defer. That is not sustainable, and it is not a supply base you want your customer promises resting on.
The practical consequence for a merchant is that your delivery pattern determines the price you can reasonably expect. Predictable, schedulable volume on a consistent corridor can be served at genuinely lower cost. Unpredictable single jobs to scattered destinations cannot, and an operator who prices them as though they can is either subsidising you or squeezing the rider.
What a delivery actually costs to run
Ignore rate cards for a moment and look at the cost base. Per drop, in a Kenyan urban motorcycle operation, the dominant components are:
- Rider time — by a wide margin the largest single input, and the one most often understated. Time is not just the ride; it is waiting at the merchant's counter, waiting at the destination gate, and the return leg.
- Fuel — a function of corridor distance and, critically, of traffic, since idling consumes fuel and produces nothing.
- Dispatch and support overhead — the operations desk, the platform, the customer service function.
- Failure cost — the redelivery, the return, the refund, the lost customer. This is the component nobody models and everybody pays.
Two implications follow. First, waiting time is a real cost and should be treated as one; a merchant whose counter routinely holds a rider for fifteen minutes is consuming a resource they are not paying for, and it will show up in their pricing eventually. Second, the cheapest lever available to any merchant is not negotiating the rate. It is reducing failed deliveries — which is a data problem, not a price problem.
Proof: the part that decides whether any of it works
Most conversations about delivery in Kenya are about speed and price. The thing that actually determines whether a merchant can grow is neither. It is whether the delivery can be accounted for afterwards.
A delivery generates four kinds of evidence, and most operations produce only the last one:
- What was sent — the declared contents and value, captured at creation.
- That it was collected — an authenticated record created at the merchant's counter, before the rider departs.
- Where it went — the tracked route, retained.
- That it was received — an authenticated record at the door, tied to the recipient.
The second is the one almost nobody has, and it is the one that makes the rest defensible. With collection evidence, a missing parcel is a question with an answer. Without it, every dispute collapses into the merchant's word against the rider's, and the merchant loses by default because they are the one with a customer to keep.
Our own approach is two one-time PINs: one authenticating collection at the counter, one at the doorstep that simultaneously confirms handover and releases payment. Identity, proof and payment are locked to the same events, and revenue is only recognised on a verified completion. Other operators will solve it differently. What matters is that the collection end is evidenced at all — and, increasingly, that it is evidenced because the regulatory framework requires the state of an article to be verified at acceptance as well as at delivery.
Why deliveries fail — and what to do about each
Failed deliveries are the most expensive line in last-mile and the least examined. In Kenyan urban delivery the recurring causes are consistent:
| Cause | Fix |
|---|---|
| Recipient unreachable at the destination | Confirm the phone number at order creation, not at the door. Notify on dispatch, not only on arrival. |
| Address resolves to a landmark that the rider cannot find | Capture a landmark plus a pinned location, and let the rider call before entering the last kilometre rather than after circling it. |
| Recipient unavailable in the delivery window | Offer a window at creation and hold to it, rather than promising "today" and arriving at 18:40. |
| Access refused — gates, estates, buildings, reception desks | Capture access instructions as a field, not as a note nobody reads. Corporate and estate deliveries need a named contact. |
| Payment not ready on a pay-on-delivery order | Confirm the amount with the recipient at dispatch. Most pay-on-delivery failures are surprise-about-the-amount failures. |
| Parcel not ready at collection | This one is the merchant's. It is also the most common, and it is invisible in most operators' reporting because it is recorded as a late delivery rather than a late collection. |
Note what that last row implies. If your operator reports lateness but not the stage at which lateness entered, you cannot tell whether your delivery problem is theirs or yours. Ask for it split.
What to measure
Four numbers. Everything else is decoration.
On-time rate against a stated window. Not "average delivery time" — an average conceals the tail, and the tail is what customers complain about. Against a window, with the window defined in advance. For reference, our own measured on-time performance was 95.6% across 285 deliveries completed to 20 August 2026.
First-attempt success rate. The proportion of deliveries completed without a second attempt. This is the truest single indicator of whether an operation is actually working, because it captures address quality, communication, and windowing all at once.
Time to exception notification. How long between something going wrong and somebody telling you. An operation that reports failures within minutes is one you can manage around. One that tells you at end of day is one you find out about from your customer.
Cost per successful drop — not cost per booking. Failed deliveries are paid for twice and should be counted that way.
Where the regulation now sits
As of 2026 this is no longer an unregulated space. Kenya has created a Courier Hailing Service Provider licence for digital delivery platforms, with obligations that bear directly on everything above: content declaration and verification, sender and recipient verification, real-time tracking, consumer verification of rider identity, complaint filing and tracking, published prohibited-articles schedules, filed tariffs, published compensation policies, and record retention of at least five years, producible to the Authority or a competent government agency on request.
For merchants, the practical effect is that the operational qualities described in this guide — evidenced collection, retained records, accurate declarations, published terms — have stopped being marks of a good operator and become the baseline of a lawful one. We have written the detail in a separate explainer on the licence and a seven-point checklist for choosing a partner.
Frequently asked questions

Kepha M. Sitati
Founder, Chief Executive Officer & Chief Operations Officer
Kepha Sitati is the founder and CEO of TumaBoda, operating last-mile delivery infrastructure across Nairobi, Kiambu and Bungoma. Operating figures cited are from TumaBoda's own delivery records.
