Custom Logistics, Delivery and Parcel Management Web Application Development

A custom logistics, delivery and parcel management web application tracks each parcel from booking to doorstep through clear statuses, assigns parcels to riders by route, reconciles cash on delivery (COD) collected by every rider, gives customers a public tracking page and moves parcels between branch hubs. Tarka Raj Jaishi, a full-stack web application developer in Lamki, Kailali, builds logistics delivery management software around the daily reality of Nepali courier work: COD-heavy orders, riders on motorbikes, failed delivery attempts and hubs connected by overnight buses and trucks.

Several kinds of businesses in Sudurpashchim run delivery operations, even if they would not call themselves logistics companies:

• Courier and parcel services carrying online-shop orders between Kathmandu, Nepalgunj, Dhangadhi and smaller towns.
• Local delivery services running riders within Dhangadhi, Lamki, Tikapur and Attariya for shops and restaurants.
• Distributors delivering to retailers on fixed routes.
• Online sellers with their own riders who have outgrown a WhatsApp group and a notebook.

Signs of trouble are usually the same: customers calling to ask "where is my parcel?", riders and the office disagreeing about how much COD cash was collected, and parcels that sit in a hub for days because nobody noticed them.

A parcel system is only as good as its statuses. Each one should mean exactly one thing, be set by a specific person, and be timestamped. Here is a lifecycle that suits most Nepali courier operations.

"Delivery failed" with a reason is the status most systems handle badly. In Nepal, where many addresses are landmark-based ("behind the school, near the temple") and phones are sometimes switched off, failed attempts are common. Recording the reason makes it possible to call the customer, fix the address and reattempt instead of silently returning the parcel.

Each morning, the dispatcher at a hub looks at every parcel at the hub awaiting delivery and assigns them to riders. A good assignment screen:

1. Groups parcels by area or route, such as Dhangadhi bazaar, Campus Road or the Attariya side.
2. Shows each rider's current load and total COD amount they will carry.
3. Lets the dispatcher assign by area in a few taps, then adjust individual parcels.
4. Generates a run sheet on the rider's phone with addresses, phone numbers, COD amounts and a map link.
5. Lets the rider update statuses from the phone at each stop, with a photo or recipient name as proof of delivery.

The rider's screen must work on a cheap phone in bright sunlight, with big buttons and minimal typing. It should also queue updates when there is no signal and send them when the rider is back in coverage.

Cash on delivery dominates many Nepali parcel operations, and it is the area with the most disputes. Every rupee needs to be traceable from the customer's hand to the merchant's account.

At the end of the run, the system shows exactly how much COD each rider should hand over based on parcels marked delivered. The cashier counts the cash, records it, and any shortfall or excess is logged against the rider for that day. Payments the customer made by QR to the company's eSewa or Khalti account are matched separately.

COD collected for each merchant accumulates in a merchant balance, minus delivery charges and any return fees. Merchants are settled on an agreed cycle by bank transfer or wallet, with a statement listing every parcel included. Merchants should be able to see this statement themselves at any time, because trust in settlement is what keeps them using your service.

• A rider cannot mark a COD parcel delivered without entering the collected amount.
• Changing a delivered parcel back to undelivered needs a supervisor and a reason.
• Daily rider cash reports are locked once the cashier closes them.

A tracking page where the customer enters a tracking number, or opens a link sent by SMS, cuts down a large share of "where is my parcel?" calls. Keep it simple and fast on mobile data:

• Current status and a timeline of past statuses with dates and locations.
• Expected delivery day once the parcel is at the destination hub.
• The delivery hub's contact number, not the rider's personal number.
• No sensitive data: show the town, not the full address or phone number.

When parcels move between hubs, they move in batches. A manifest groups all parcels loaded onto one vehicle for one destination hub. The origin hub scans parcels onto the manifest; the destination hub scans them off. Missing parcels show up immediately as items on the manifest that were never scanned in at the other end. Hub-to-hub movement shares a lot with inter-branch stock transfers, described in the multi-branch inventory and sales post. Online marketplaces that rely on courier partners will recognise this from building an online marketplace in Nepal, and merchants can be given an API to book parcels directly from their own stores, as discussed in business process automation.

Yes, if the rider app is built to queue updates offline. Statuses and COD amounts are stored on the phone and sent when the rider is back in coverage, with the original time preserved.

Each merchant gets a statement listing delivered COD parcels, amounts collected, delivery charges and return fees deducted, and the net amount due. They can view it any time through a merchant login.

An API can let merchant websites create bookings and fetch tracking statuses directly, removing manual entry. Smaller merchants can use a simple booking form or upload a spreadsheet of orders.

Yes. Address fields allow free-text landmarks along with area and town, and riders can save a map pin for repeat customers so later deliveries are easier.

It depends on the number of hubs, riders and merchants, whether offline rider apps and merchant APIs are included, and how COD settlement is handled. A phased rollout starting with one hub is a practical way to begin.

If your delivery operation is losing track of parcels or COD cash, get in touch to map your parcel lifecycle and rider flow into a working system.

• Phone: 9865760285 / 9812636744
• WhatsApp: +977 9865760285
• Website: tarkarajjaishi.com.np
• Facebook: facebook.com/TarkarajJaishi