Delivery software is usually sold on routing. Optimised sequences, fuel saved, more drops per vehicle.
Routing matters. But in the operations we have built for, it is rarely where the money is lost. The expensive failures happen at the edges of a delivery — proving it happened, reconciling what was collected, and handling the ones that did not succeed. Those are unglamorous, they do not demo well, and they determine whether the operation is controllable.
The delivery is not the transaction
A delivery is the physical movement of goods. The transaction is the commercial event: what was ordered, what was actually handed over, what was paid, and what remains owed.
When those two are tracked in separate systems — a delivery app and an accounting system, say — every mismatch becomes a manual investigation. The driver marked it delivered; the customer says two items were short; the invoice was raised for the full order. Three records, three versions.
The structural fix is that a delivery updates the same record the order and the invoice live in, which is the argument in what a business operating system actually is. Without it, delivery software adds visibility to a reconciliation problem it cannot solve.
Proof of delivery is a commercial document
Proof of delivery is treated as an operational formality and is actually the evidence in every subsequent dispute.
What it needs to establish:
Who received it. A name, and where practical a signature or photograph. "Delivered" as a status is not proof.
What was actually handed over. Not what was on the order — what left the vehicle. Partial deliveries are common and are where disputes originate.
When. Timestamped at the point of handover, not entered later from memory. A batch of deliveries all marked complete at the end of a shift is not a record; it is a reconstruction.
Condition. For anything fragile or perishable, a photograph at handover ends most later arguments.
The test is simple: if a customer disputes a delivery from three weeks ago, can you produce evidence, or an assertion? Most operations discover the answer during the dispute.
Cash on delivery is a reconciliation problem
Where drivers collect payment, the operation has effectively distributed its cash handling across vehicles.
The failure is rarely dishonesty. It is timing and record-keeping: money collected, recorded on paper or not at all, handed over at end of shift, reconciled against a delivery list that may itself be incomplete. Every gap between collection and recording is a place a figure drifts.
What controls it:
- Payment recorded at collection, against the specific delivery, not at end of day
- Partial payments and refusals as explicit outcomes rather than blanks
- A shift-level reconciliation that surfaces variance the same day
- The collected amount reaching the ledger without re-entry
This is the same daily-close discipline that governs a counter, applied to a vehicle. What breaks a billing system at peak hour covers the equivalent problem at a fixed location.
Failed deliveries are the real cost centre
A successful delivery costs what it costs. A failed one costs the attempt, the return leg, the storage, the rescheduling, and often a second failure.
Most delivery software records failure as a status. That is insufficient. What is needed is:
A reason that is specific enough to act on. "Customer not available" is a category, not a cause. Was the address wrong, the window unsuitable, the phone unanswered? Only a specific reason permits a fix.
Automatic disposition. What happens to the goods now — back to the warehouse, held on vehicle, reattempt tomorrow? If this is decided ad hoc, stock ends up in an undefined state, which is how warehouse discrepancies begin.
Pattern visibility. One failure is an event. The same address, route or time window failing repeatedly is a fixable problem, and it is invisible without aggregation.
In most operations we have seen, a small number of causes account for the majority of failed deliveries, and none of them were being counted.
Where routing genuinely helps
Having argued it is over-emphasised, routing is worth doing well once the above is in place.
It pays most where drop density is high, the vehicle count is fixed, and the route changes daily. It pays least where drops are few and geographically obvious, or where the sequence is constrained by customer time windows anyway — in which case the constraint is scheduling, not distance.
The honest test: could a person familiar with the area produce a sequence nearly as good in ten minutes? For many operations the answer is yes, and the gain from optimisation is smaller than the vendor implies.
What we have seen
Delivery and logistics management are among the ten systems we have delivered, alongside warehouse and distribution operations where deliveries are the last step of a longer chain.
The consistent finding is that businesses ask for tracking and need attribution. Knowing where a vehicle is has limited operational value. Knowing why yesterday had four failed drops, which of them will fail again tomorrow, and how much cash is unreconciled — that changes decisions.
The second finding is that drivers will use whatever is fastest at the doorstep. If recording a partial delivery takes six taps while marking it complete takes one, the record will say complete. Designing the awkward outcomes to be as fast as the happy path is what makes delivery data trustworthy — the same principle that governs counter software, covered in how Truffaire builds software.
Frequently asked questions
Do we need a separate delivery system?
Only if deliveries have complexity the operations system cannot express — multi-drop routes, driver assignment, proof capture. If deliveries are simple and low-volume, adding a second system creates a reconciliation burden larger than the problem.
What about using a third-party courier's tracking?
Fine for visibility of parcels in transit. It will not reconcile your cash, prove what was handed over against your order, or attribute your failures — because it is tracking their shipment, not your transaction.
How do we handle partial deliveries?
As a first-class outcome, not an exception. The driver records what was actually delivered; the balance either returns to stock or stays open on the order. If the system cannot express this, staff will record it as complete and correct it later, and later frequently does not happen.
Should drivers use their own phones?
Usually yes, and it removes a hardware cost. The requirements are that the app works on poor connectivity and that records sync automatically when it returns — otherwise the day's records depend on someone re-entering them.
How do we reduce failed deliveries?
Start by categorising them specifically for a month. Most operations find two or three causes dominate — commonly wrong or incomplete addresses and unsuitable time windows — and both are addressable at the point of order rather than at the doorstep.
Where to start
Before evaluating routing features, count your failed deliveries for a month and record a specific reason for each. Then check whether you could prove a delivery from three weeks ago if a customer disputed it.
Those two exercises usually reveal that the constraint is evidence and attribution rather than route efficiency. Fixing those is cheaper, and it makes routing worth doing afterwards.
SPEXA handles delivery against the same record as the order, the stock and the ledger. If you want a read on where your delivery cost actually sits, get in touch.