Type a parcel ID into a tracking page and a timeline appears: booked, picked up, at hub, out for delivery, delivered. It looks simple — which is exactly why many courier owners in Bangladesh underestimate what a courier tracking system involves, and why so many “tracking pages” in the market show information that is hours old or simply wrong.
Tracking is not one feature. It is a chain of events flowing from a merchant’s booking screen through hub scans and a rider’s Android phone to a public web page — and the chain is only as trustworthy as its weakest link. This post explains how the whole system works, step by step, so you can evaluate tracking properly whether you are buying software or building a courier operation.
The foundation: one parcel, one identity
Everything starts with a unique tracking ID assigned the moment a parcel is booked. That ID — printed on the label as a barcode or QR code — is the parcel’s identity for its entire life. Every scan, status change, cash collection, and proof of delivery attaches to it.
This sounds obvious, but it is precisely what manual operations lack. When a parcel is a line in a register, its identity depends on someone reading the right line. When it is a scannable ID, identity is instant and error-proof: point a phone camera at the label and the system knows exactly which parcel — out of thousands in the building — it is looking at.
A practical note for Bangladesh operations: dedicated barcode scanners are nice at high-volume hubs, but modern systems scan perfectly well with the camera on an ordinary Android phone. Your riders and hub staff already carry the hardware.
The status lifecycle
A tracking system is fundamentally a state machine — a defined set of statuses a parcel moves through, with rules about which transitions are allowed:
| Status | Triggered by | What it means |
|---|---|---|
| Booked | Merchant or staff entry | Parcel exists in the system |
| Pickup assigned | Ops or auto-assignment | A rider is tasked to collect |
| Picked up | Rider scan at merchant | Parcel physically in the network |
| At hub | Hub scan on arrival | Received at branch or sorting hub |
| In transit | Dispatch scan | Moving between branches |
| Out for delivery | Rider scan at dispatch | On a rider’s bike, heading to customer |
| Delivered | Rider confirmation + proof | Handed over, COD collected |
| Failed / rescheduled | Rider with reason code | Attempt failed — customer unreachable, address wrong, refused |
| Returning / returned | Return workflow | Going back to the merchant |
Two design details separate good systems from bad ones. First, enforced transitions: a parcel cannot jump from booked to delivered without passing through the physical steps, which blocks both accidents and fake-delivery marking. Second, reason codes on failure: “customer phone off” versus “refused to pay” versus “wrong address” are different problems requiring different fixes, and lumping them together hides your biggest source of returns.
Where updates come from: scans and the rider app
Every status change in the timeline is created by a real-world event, captured one of three ways:
- Hub scans. Staff scan parcels on arrival and dispatch. Bulk scanning matters here — receiving a transfer bag of 200 parcels must take minutes, not an hour.
- Rider app events. The rider’s phone is the most important tracking device in the system. Accepting an assignment, scanning at pickup, marking out-for-delivery, confirming delivery with photo, signature, or OTP, recording the COD amount — each action stamps the timeline with a time and a name. This is why rider management and tracking are inseparable: tracking data is only as good as the app riders actually use.
- System events. Auto-assignments, SLA alerts for parcels stuck too long in one status, and bulk operations by ops staff.
The engineering reality of Bangladesh matters here: riders work on mid-range Android phones over patchy mobile data. A serious tracking system handles this with offline capture — the rider marks the delivery in a dead zone in Kishoreganj, the app stores it locally, and syncs the moment signal returns. Systems designed for always-online conditions produce the familiar failure: parcels delivered at noon that show “out for delivery” until night.
Who sees what: the three views of one timeline
The same event stream feeds three different audiences:
The customer view
A public page — enter a tracking ID, see the timeline. No login. Clean statuses in plain language, ideally with SMS notifications at booking, out-for-delivery, and delivery. This page carries your brand, and it quietly does two jobs: it eliminates status calls, and it makes a small courier look as professional as a national one. See Drix parcel tracking for what a complete customer view includes.
The merchant view
Merchants — your F-commerce sellers and online shops — see all their parcels at once inside the merchant panel: filterable lists, failed-delivery alerts they can act on (call their customer, correct an address), and the COD status of every order. For merchants, tracking is inventory and cash flow visibility, not curiosity.
The operations view
Your team sees the network: every parcel, every branch, every rider, with exceptions surfaced automatically — stuck parcels, repeated failed attempts, transfer discrepancies. Aggregated over time, this stream becomes your reports and analytics: success rate by zone, average delivery time, failure reasons ranked. Tracking data is the raw material of every operational decision you will make.
Machine-to-machine tracking: APIs and webhooks
Beyond human eyes, tracking data increasingly flows system-to-system. Two mechanisms matter:
- APIs let a merchant’s software ask your system questions — “what is the status of parcel X?” — and push new bookings in automatically from WooCommerce or Shopify stores.
- Webhooks reverse the direction: your system proactively notifies the merchant’s system the instant a status changes, so their store updates the customer without anyone polling. This is how larger merchants expect to work, and offering it is a genuine competitive edge for a growing courier. The mechanics are covered in our guide to webhook parcel status updates.
If you plan to serve serious e-commerce merchants, ask any software vendor to show both — a tracking system without an API caps the size of merchant you can win.
Why tracking accuracy is a COD problem
In Bangladesh, tracking and cash are the same system wearing two hats. The scan that marks a parcel delivered is the same event that records 1,850 taka collected from the customer — which means every tracking failure is also an accounting failure. A parcel falsely marked delivered is missing cash. A delivery that synced late is cash-in-hand you cannot see. This is why tracking integrity, proof-of-delivery capture, and COD management have to be designed together: the timeline is not just customer service, it is the ledger of where your merchants’ money physically is.
Get this right and the operational benefits compound quickly — fewer disputes, faster settlements, visible rider performance. We covered the full list in 10 benefits of a courier management system.
What to check before trusting any courier tracking system
- Latency. How long between the rider’s action and the public page updating? Real time should mean seconds on a working connection.
- Offline behavior. Watch a status update made in airplane mode sync correctly afterward.
- Proof of delivery. Photo, signature, or OTP attached to the delivered event — not a checkbox.
- Enforced transitions and audit trail. Who changed this status, when, and was the change legitimate?
- Failure reason codes. Structured reasons, not free-text notes.
- Bulk scanning speed. Time how long 100 parcels take to receive at a hub.
- API and webhooks. For the merchants you want next year, not just the ones you have now.
How Drix handles tracking
Drix was built with the chain described above as one connected system, designed for Bangladesh conditions. Parcels get scannable IDs at booking; hub staff and riders update statuses through phone-camera scans; the rider app captures proof of delivery and COD amounts together, with offline sync for weak-signal areas. The same event stream drives the branded customer tracking page, live merchant visibility in the merchant panel, stuck-parcel alerts for your ops team, and the dashboards in reports and analytics — with API and webhook access for merchants who integrate their stores.
The best way to judge any tracking system is to watch it handle your real workflow — a booking, a hub transfer, a failed attempt, a delivery with COD — end to end. Book a demo to see that flow live, or visit pricing to learn how Drix quotes each operation.
The bottom line
A courier tracking system is a chain: unique IDs, an enforced status lifecycle, scans and rider-app events feeding one timeline, three tailored views of that timeline, and APIs carrying it to merchant systems. Every link you skip becomes a blind spot — and in a COD market, blind spots are not just service problems but cash problems. Whether you buy software or evaluate what you already run, judge it link by link.
