Eight branches, one account of what happened.

Eight branches, and no way to know what happened yesterday.

A parcel booked at one counter travels to a hub, onto a dispatch, out to another branch, and finally to a person who has been waiting for it. Along the way it passes through the hands of several staff across eight branches. Every one of those handovers is a moment where the parcel is somewhere, and where the only record that it is there might be that somebody remembers putting it down.

Three things follow from that, and none of them look like a crisis on any given day. A customer rings to ask where their parcel is, and the answer depends on who picks up. A price gets adjusted at the counter because the customer is a regular, or the box is an awkward shape, and by the evening nobody can say which parcels were adjusted or why. And at closing, the cash is counted by the same person who took it, which is not a suspicion about anybody, it is a structure. Structures have to be answered structurally.

• 01A parcel’s location lived in whoever last handled it
• 02Customers were told where their parcel was by telephone, one call at a time
• 03Prices moved at the counter with no record of who moved them, or why
• 04The night’s cash was counted by the person who had taken it

Make the parcel write its own history.

We did not start by building a tracking screen. We started by deciding what a parcel is: not a row that gets edited until it is finished, but a thing that moves through six named states and leaves a dated entry behind at each one. Booked. At the hub. Dispatched. Arrived. Delivered. Cancelled. Nothing else is allowed, and no state changes without writing down who changed it and when.

That single decision is what everything else stands on. Across 2,040 parcels the system has written 13,660 of those entries, an average of 6.7 per parcel. It means the answer to “where is it” is a query rather than a phone call, and the answer to “who had it when it went missing” is a list of names and times rather than a conversation.

The price got the same treatment, from the other direction. Real courier pricing has irregular cases in it, so a system that refuses to let staff change a price is a system people work around with a paper note. We let them change it and made the reason mandatory: the database will not store a changed price without a written explanation and the name of the person who wrote it. That converts an invisible decision into a visible one without slowing anybody down at the counter.

Cash close is where the separation of duties lives. The staff member counts, an approval sits on top of that count, and the person who reviews is not the person who took the money. 136 nights have been closed this way, carrying 159 approvals.

Counted in the system, on a date we can name.

Every figure here was read directly out of the operator’s own system on 25 August 2026, not reported to us and not estimated. In 51 days the lane has handled 2,040 parcels across eight branches, booked by ten staff, moved in 222 dispatches and 538 bags, priced against a 190-row rate card.

486 manual price changes have been made, and all 486 carry a written reason and the name of the person who made it. Not most. All of them, because the system will not accept one without. About a quarter of real bookings need a human price decision, and we would rather that quarter were loud than pretend it does not happen.

3,325 arrival and delivery notices have gone to customers automatically. Each of those is a call that somebody used to have to make, or a call a customer used to have to make instead. Booking confirmations and payment receipts are deliberately not counted here: the customer is standing at the counter for those, so they replace nothing.

Customers have left 37 ratings, averaging 4.89, and 33 of those are five stars.

The operator’s revenue and margins are theirs to disclose, not ours, so no rupee figure appears here.