How to Choose Logistics Software for a Courier Company in Nepal

Most logistics software evaluations go the same way. Three vendors demo, all three demos look fine, the cheapest one wins, and eighteen months later the operations team is running half the business in spreadsheets alongside the system nobody wanted to admit was wrong.

The demos look fine because demos show the happy path: a parcel is booked, assigned, scanned, delivered. Every system does that. What differs is everything around it — and that is where a courier in Nepal actually lives.

Here is what to evaluate instead.

Start from your exceptions, not your process

Ask each vendor to walk through your five most common exceptions, not your standard flow. For most couriers here those are:

• A customer is unreachable and the parcel needs rescheduling twice before it becomes a return
• A parcel is delivered but the customer pays less than the COD amount because part of the order was wrong
• A consignment is booked in Kathmandu, transferred through a hub, and delivered by a franchise branch that is not your own staff
• A merchant disputes a settlement three weeks after the fact
• A rider goes out with 40 parcels and comes back with cash, returns and reschedules mixed together

If a system handles those as first-class states, you will see it immediately. If the answer involves a note field, a manual status override, or “you can export that and handle it outside the system”, you have found the spreadsheet you will be running in a year.

Cash on delivery is not a feature, it is the product

In a market where most orders are COD, the money side of the system matters more than the tracking side. Tracking is table stakes. Reconciliation is where couriers win and lose merchants.

Check specifically:

• Is COD amount modelled separately from delivery charge and from amount actually collected?
• Is there a per-merchant rate card the system applies automatically, including zone-based and volume-tiered pricing?
• Can you see a merchant’s outstanding balance right now, without running an export?
• Is there a custody chain — rider to branch to bank to merchant — with each handover as its own record?
• Can you settle daily if you want to, or does the process force weekly?

We wrote about this in more depth in cash on delivery reconciliation for courier companies in Nepal.

Branch and franchise structure

Nepal’s courier networks are rarely a single company with owned branches. They are a mix of owned branches, franchise partners, and agent-run collection points, and the commercial arrangement differs for each.

The system has to know:

• Which branches are yours and which are partners
• How revenue is split for a consignment that touches more than one
• What a partner branch is allowed to see — a franchise should see their own consignments and settlements, not the whole network’s
• How stock of packaging material, waybills and float moves between branches

Systems built for a single-entity logistics company handle none of this well. Retrofitting it later is expensive because it touches the permission model, the ledger and the reporting layer at once.

Addresses in Nepal

Most international logistics software assumes a postal address system that resolves to a point. Nepal largely does not work that way. Addresses are landmark-based, house numbering is inconsistent, and the operationally useful unit is a locality plus a phone call.

Practical questions:

• Can the system store a landmark-based address without forcing a postcode?
• Does routing work off zones and localities you define, rather than off a geocoder that will fail on half your addresses?
• Is the customer phone number treated as a required, first-class field, because it is the actual delivery mechanism?
• Can a rider correct an address in the field, and does that correction persist for the next delivery to the same customer?

A system that rejects a booking because the postcode is invalid will be worked around within a week.

Who fixes it when it breaks

This is the question most evaluations skip, and it is usually the one that decides the outcome.

When you need a new report, a change to a rate card structure, an extra field on the rider app, or an integration with a merchant’s store — what happens? For an off-the-shelf international product, the honest answer is usually “you submit a request and wait, and if you are a small customer in a small market, you wait a long time.” For a local build, the answer should be a conversation and a timeline.

Ask concretely:

• Who wrote this system, and are they reachable?
• What is a realistic turnaround for a small change? For a new module?
• What happens if we need something during a festival-season traffic peak?
• Is support in a timezone and language that matches our operations team?

Migration is the real project

Whatever you choose, the hard part is not the software. It is moving your live operation onto it: historical consignments, merchant balances, rate cards, branch structures, user accounts, and doing it without a day where parcels stop moving.

Ask each vendor how they have done this before, and specifically:

• Can we run both systems in parallel for a period?
• What happens to consignments that are in transit at cutover?
• Do outstanding merchant balances carry over, or do we settle everything to zero first?
• Who does the data cleaning — us or them?

A vendor who has done this in Nepal will have opinions about all four. A vendor who has not will say it is straightforward.

A shortlist question that works

If you only ask one thing, ask this: show me how a consignment that was booked in Pokhara, transferred through Kathmandu, delivered by a franchise partner, paid partially in cash, and disputed by the merchant three weeks later, appears in your system today.

Everything you need to know is in the answer.

We build and maintain logistics software for couriers and cargo operators in Nepal, and the systems described here are in daily use by courier networks across the country. If you are running an evaluation, talk to us — we are happy to answer the hard version of these questions.