Reducing Failed Deliveries and Returns for Couriers in Nepal

A return-to-origin is the worst outcome in a cash-on-delivery network. You paid for the pickup, the line haul, the sorting, one or more delivery attempts, and then you pay again to send it all the way back. The merchant is unhappy, the customer is gone, and nobody was paid for any of it.

Cutting the return rate is usually worth more than cutting cost per delivery, and it is more tractable, because most returns are not random.

Separate the causes before fixing anything

“Failed delivery” is not one problem. Lumping the reasons together is why most improvement efforts go nowhere. The distinct causes, roughly in order of how common they are here:

Customer unreachable. The phone is off, out of service, or nobody answers. Often the number was mistyped at order time, or it belongs to someone else in the household.

Address cannot be found. Landmark-based, incomplete, or describing a locality rather than a place. The rider spends fifteen minutes and gives up.

Customer not available. Correct address, correct number, wrong time. Nobody home during working hours.

Customer refuses. They changed their mind, ordered on impulse, found it cheaper elsewhere, or never seriously intended to pay.

Customer cannot pay. They want the item but do not have the cash today.

Product issue. Wrong item, damaged packaging, different from what was expected.

Each of these has a different owner. Two of them are not the courier’s problem at all — and telling them apart is the first thing the system has to enable.

The system needs distinct failure reasons

If your rider app offers “delivery failed” with a free-text note, you will never fix anything. The reasons have to be a fixed, meaningful list, chosen by the rider at the point of failure, and they have to map to the causes above.

Once they do, the reporting becomes actionable:

• High “address not found” concentrated in one zone → your locality mapping for that zone is wrong
• High “customer refuses” concentrated with one merchant → that merchant has an order-quality problem, not a delivery problem
• High “customer unreachable” across the board → phone number capture at order time is broken
• High “not available” in one zone → that zone needs evening or weekend delivery slots

Without distinct reasons, all of that is invisible and every conversation with a merchant is opinion against opinion.

Fix the phone number first

The cheapest win available to most couriers is validating the customer phone number before the parcel ever moves.

At booking, the system should check the number is a plausible Nepali mobile number and reject obvious junk. Better, where the merchant integration allows, is confirming the order by SMS or a call before pickup — an order that cannot be confirmed is a return waiting to happen, and it is far cheaper to catch it at the merchant’s warehouse than at the customer’s door.

Couriers who introduce confirmation on high-value COD orders typically find a meaningful share never make it to dispatch. Every one of those is a return prevented at close to zero cost.

Call ahead, and give a window

The second cheapest win is calling before attempting. It converts “not available” from a failed attempt into a scheduled one.

For this to work at volume it has to be part of the system, not a rider’s initiative: the call attempt, its outcome, and the customer’s stated availability window recorded against the consignment, so the reattempt is scheduled into the right slot rather than repeated blindly the next morning.

Attempt policy should be per merchant

A blanket “three attempts then return” policy is wrong for everyone. A merchant selling low-value fast-moving goods may prefer one attempt and a fast return. A merchant selling a high-value item will happily pay for five attempts and a week of holding.

Make it a field on the merchant’s agreement: number of attempts, holding period, whether to attempt at an alternate address, whether to offer partial delivery. Then the system enforces it automatically rather than an operations person remembering which merchant is which.

Give the customer a way to intervene

Most returns happen because the customer had no way to change anything. They were at work, the rider came, and the only communication was a missed call from an unknown number.

A tracking link sent by SMS at dispatch — with the expected day, the rider’s contact, and a way to reschedule or change the address — moves a large share of would-be failures into successful second attempts. It costs very little and it shifts effort from your operations team to the person best placed to solve the problem.

Returns need to be as well-run as deliveries

Whatever you do, some parcels return. The return leg is usually the least-managed part of a courier network, and it is where parcels are actually lost — they sit at a branch, unbagged, waiting for someone to decide what to do with them.

Returns should be a first-class flow with the same rigour as outbound: bagged, manifested, custody-tracked, and with a return proof of delivery at the merchant’s end. The merchant should be able to see, at any moment, what is coming back to them and what has been handed over. And the charges for the return leg should be computed and applied by the system, per that merchant’s rate card, not negotiated case by case.

What to measure

• First-attempt success rate, overall and by zone
• Return rate by merchant — the number that starts commercial conversations
• Failure reason distribution, tracked over time
• Reschedule-to-delivery conversion rate
• Average age of parcels sitting in return status at a branch

The last one is the one nobody watches and the one that quietly loses parcels.

We build the logistics management system that courier and cargo networks in Nepal use for structured failure reasons, per-merchant attempt policies and managed return flows. If your return rate is a number nobody can explain, talk to us.