Why we built QCS: the COD problem we kept running into
The recurring problem was not delivery. It was that a seller could not prove, from any record anyone would produce, what happened to one parcel and one rupee. Three decisions followed, and two mistakes.
QCS exists because of a specific, boring problem that kept recurring: a seller could not tell, from any record anyone would show them, what had happened to a particular parcel and a particular amount of cash. Not whether delivery worked in general. Whether that one parcel was delivered, what weight it was charged on, and where the money went.
That is not a delivery problem. It is a records problem that shows up as a delivery problem, and it is why we built the platform before we built the network.
The three questions nobody could answer
What weight was this charged on?
A charge appears on an invoice. The weight behind it is somewhere inside the courier. If a seller thinks it is wrong, the conversation is one person's recollection against another's system, and the system does not get produced.
So we made the weight, the dimensions, the zone and the rate card version part of the parcel rather than part of a calculation. A re-weigh at the warehouse writes a new charge snapshot and keeps the original byte for byte, so both figures stay visible. Chargeable weight versus actual weight is the arithmetic, and the pricing calculator runs the same engine the booking screen does.
Was this actually delivered?
A status that says delivered is a claim. A seller cannot audit a claim.
So a parcel cannot carry that status without proof of delivery attached, and that is refused at the data layer rather than discouraged in the interface. The customer gets their copy with the delivery notification, you see it on the order, and access to it in the back office is logged. Proof of delivery explained covers it.
Where is my money?
The gap between a parcel being delivered and the amount appearing on a seller's account is where cash goes quiet. If crediting happens at an invoice cycle, there is a window where the money exists and is not anywhere a seller can see.
So the balance moves at the moment of delivery, inside the same database transaction that posts the double-entry journal. No batch. Your statement is current rather than a period behind. The remittance cycle sets out why crediting and paying are still separate steps.
The three decisions that followed
Scan-driven, with no manual override
No scan, no collection. No scan, no warehouse stock. No scan, no return intake. A parcel the rider did not scan at your premises goes back to your booked list with a reason code rather than being counted as collected because somebody remembers it.
The cost of this is real: it makes a busy handover slower than a count would be. We took that trade because a count cannot be produced three weeks later.
Append-only history
Status history, scan events and ledger entries cannot be updated or deleted by the application. A correction is a new row or a reversing entry, never an edit. That means a corrected figure keeps its history instead of replacing it, and it means nobody inside QCS can quietly tidy a record.
Charges only on delivered parcels
A failed collection, a refusal at the door, a parcel returned to you: none of them carry a delivery charge. There are exactly two exceptions, both requiring evidence and both named in the published tariff rather than left to discretion.
We wrote it as a term rather than a goodwill policy because a goodwill policy is withdrawn on a bad month.
What we got wrong first
Two things worth stating, because a company page that describes only good decisions is not a company page.
We required a map pin at booking. It was the accurate option and it was the wrong default, because most sellers do not have one and requiring it blocked bookings for no operational gain. Now a pin is optional, an unresolved zone is marked provisional rather than silently charged at city rate, and the quote says plainly that it is indicative. Lahore delivery zones explained covers the six ways a zone gets settled.
We also built the attempt cycle to run to its threshold automatically. It should not: a fourth van trip to a customer who has refused twice is a cost nobody chose. Now the threshold stops and asks a person, and the decision is recorded against their name.
What we are actually optimising for
Not speed. Not price. The ability for a seller to prove what happened to a specific parcel and a specific rupee, without asking us.
Everything that looks like excessive rigidity from the outside is that one goal applied: the mandatory scan, the mandatory proof, the frozen rate card version, the append-only history, the cash still with the rider being carried as a visible figure rather than absorbed.
If reconciliation is the thing that costs you time and money, that is the problem we built for. Five checks that show whether a courier is short-paying you is the procedure, written to work against any courier rather than only against us.
QCS Private Limited operates from P2 35 Jeff Heights, Gulberg 3, Lahore. The merchant signup form starts a conversation, and we onboard rather than issuing credentials automatically. Email reaches us at info@qcs.com.pk and cs@qcs.com.pk.
Booking in Lahore starts at PKR 180 for the first 0.5 kg. Work out your own figure before you commit.