A courier's software is partly an internal tool and partly a customer-facing product. The features that win contracts are the ones your clients and their customers touch.
Tracking that answers the actual question
"In transit" is not an answer. A consignee wants to know when it will arrive and, if it is late, why.
What good looks like:
- Scan events at each handling point, timestamped and located
- An expected delivery date that updates when it changes
- Exception reasons in plain language — address not found, consignee unavailable, out of delivery area
- Proof of delivery with signature or photograph, retrievable months later
Every unanswered tracking query becomes a call to your support line and then to your client's. Tracking quality is a direct support cost.
A rate engine that survives real contracts
Courier pricing is rarely simple. The engine needs to handle:
- Weight slabs and volumetric weight, applying whichever is higher
- Zone-based pricing from an editable pincode master
- Client-specific rate cards, since every significant client negotiates
- Surcharges — fuel, remote area, handling
- COD collection charges, fixed or percentage
Mis-rating is a silent margin leak: consignments booked at the wrong rate are usually only discovered when a client queries an invoice, and by then the pattern has been running for months.
COD settlement that reconciles cleanly
For e-commerce clients this is the most scrutinised part of the relationship. Cash collected at the door has to be tracked from delivery staff, through the hub, to the bank, to the client's settlement.
- Collection recorded against the specific consignment
- Deposit reconciliation per delivery person per day
- Settlement reports per client matching your bank transfers
- Clear handling of returns and undelivered COD
Clients evaluate couriers on COD settlement speed and accuracy as much as on delivery performance.
An API your clients can build against
E-commerce clients integrate. If your API is difficult, they will choose a courier whose is not.
- Booking, tracking, cancellation and rate enquiry endpoints
- Webhooks for status changes rather than requiring polling
- Bulk booking for clients shipping in batches
- A sandbox and documentation with working examples
- Stable versioning, so your changes do not break their integration
That last point becomes a contractual expectation once you have a few integrated clients.
A delivery app that works in the field
Your delivery staff decide whether your tracking data is accurate.
- Works on inexpensive Android phones
- Functions offline and syncs later — connectivity is unreliable in exactly the areas deliveries happen
- Few taps to mark delivered, with proof capture
- Structured exception reasons, not free text
- Reasonable battery consumption across a full shift
If the app is slower than a phone call, staff will phone the hub and someone will key it in later — and your tracking becomes retrospective fiction.
Hub operations
Inbound and outbound scanning, bag and manifest management, route allocation, and a clear view of what is sitting at a hub longer than it should. That last report is where systemic delays are found.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
