Courier and Delivery Management System: Where the Money Actually Leaks

Part of our guide hub: Business software by industry

Delivery software is usually sold on route optimisation. In Pakistani logistics, route optimisation is rarely where the money is lost.

The margin leaks in two places: deliveries that fail and have to be attempted again, and cash collected by riders that takes a week to reconcile. A system that fixes those two and does nothing clever with routes will outperform one that does the reverse.

The four parts of the system

1. The rider application

The part that decides whether everything else works. It runs on a mid range Android phone, on mobile data, for a ten hour shift.

What it must do: show today’s assignments, capture proof of delivery with a photograph and a signature, record cash collected, and log a failed attempt with a reason. Four things, done fast.

Battery is a requirement, not a detail. Continuous GPS tracking will flatten a phone by mid afternoon, and a rider with a dead phone is an invisible rider. Sensible tracking intervals matter more than precision.

2. The dispatch and control view

Who is where, what is undelivered, what is running late, and which parcels need reassigning because a rider called in sick. This is an operations screen, not a dashboard, and it is used continuously through the day.

3. The merchant view

If you carry parcels for ecommerce sellers, they need to book pickups, print labels, track shipments, see failed attempts and reconcile their cash on delivery remittances. Forgetting this is a common scoping error, and it is a complete application.

4. Finance and reconciliation

The unglamorous half that decides profitability. Covered below because it is where the real requirements hide.

Cash on delivery is the hard problem

A very large share of Pakistani ecommerce is cash on delivery, and that turns a logistics business into a cash handling business.

The chain: customer pays the rider, rider deposits at the hub or to a bank, hub reconciles against parcels marked delivered, finance remits to the merchant minus charges. Every step is a point where money and records diverge.

What the system must handle:

• Rider cash ledger. Opening balance, collected today, deposited, closing. A rider who is short at the end of the day must be visible immediately, not at month end.
• Partial deposits and deposits across multiple days.
• Merchant remittance cycles with holding periods, per merchant.
• Deductions: delivery charges, return charges, fuel adjustments, damages.
• A remittance statement the merchant can check parcel by parcel. Disputes over cash on delivery money destroy merchant relationships faster than late deliveries.

If a demo cannot show a rider short by two thousand rupees and how that is traced, the system will not survive contact with your operation.

Failed deliveries are the second problem

Customer not available, wrong address, phone switched off, refused on arrival, asked to deliver tomorrow. In Pakistani ecommerce the failed attempt rate is high enough that reattempts are a significant share of total cost.

Requirements that follow:

• Structured reasons, not free text, so you can measure and act.
• Attempt limits and rules. Three attempts then return to origin, configurable per merchant.
• Customer contact before arrival, which is the cheapest single intervention available. An SMS or WhatsApp an hour ahead measurably reduces failures.
• Return to origin as a first class flow, with its own tracking and its own charge. Returns are often the most disorganised part of a courier operation.

What gets bought and underused

• Advanced route optimisation. Valuable at high density with many stops. For most operators, sensible zone assignment and rider knowledge of the area does nearly as well.
• Live customer tracking maps. Nice, and customers mostly want an accurate window and a call, not a moving dot.
• Automated dispatch. Usually overridden by the dispatcher who knows which rider handles which street.
• Fleet telematics without the hardware installed.

What to ask in a demo

1. Mark a delivery failed with a reason and a photo, on a phone, offline. Then show the reattempt scheduled.
2. Close a rider’s day where cash collected does not match cash deposited.
3. Produce a merchant remittance statement with deductions, parcel by parcel.
4. Process a return to origin end to end.
5. Show the failed delivery rate by reason for last month.
6. Ask about battery consumption over a ten hour shift.

Build or buy

Buy if you are a standard parcel operator and can find a system that handles cash on delivery reconciliation the way your finance team needs. Build when you have an unusual model: multi leg logistics, temperature controlled goods, integrated warehousing, or a marketplace of independent riders.

Related: fleet and logistics management software and inventory management software.

Frequently asked questions

What should a courier management system include?

A fast offline capable rider app, a dispatch view, a merchant portal, and cash on delivery reconciliation. The last one decides whether the business is profitable and is the most commonly underspecified.

How much does it cost in Pakistan?

Off the shelf systems charge per parcel or per user monthly. A custom platform with rider and merchant apps plus reconciliation generally starts around 3,000,000 PKR and rises with integrations.

Does it need to work offline?

Yes. Riders lose signal in basements, markets and rural areas. Full offline data capture with reliable sync is a hard requirement, not a preference.

Can it integrate with ecommerce platforms?

It should pull orders from Shopify, WooCommerce and marketplaces and push tracking back. Confirm the specific platforms your merchants use before buying.

Ezitech builds logistics, delivery and field operations platforms with offline capable mobile apps. Tell us your daily parcel volume and cash on delivery share and we will scope from there.