Driver Application and Proof of Delivery
A delivery business dispatching through a WhatsApp group, where proof of delivery is a photograph in a chat or a signed waybill that reaches the office days later.
The problem
The record of what happened on the road exists only as chat history and paper in transit. Every downstream question — where is it, was it delivered, why was it not, can we invoice — waits on a person.
In scope
- Job assignment
- Driver mobile application
- Status progression
- Proof capture
- Failure reasons
- Cash-on-delivery collection
- Offline operation
- Office dispatch board
Out of scope
- Rate cards
- Invoicing
- Fleet maintenance
- Customer portal
- This system records what happened to a delivery; it does not price or bill it.
- Also out: route optimisation, which is frequently requested and almost never the actual constraint.
What this would cover
Grouped by module — open the ones you want to read.
Dispatch board
- Unassigned, assigned, in progress, completed; assignment to driver and vehicle; reassignment with a recorded reason
Multi-stop trips
- Several deliveries grouped into one run, sequenced
Driver application
- Today's jobs in order, on a low-end Android phone, small download, low data use
Job detail
- Addresses with saved landmark notes, contact numbers, package details, special instructions, handoff to the driver's preferred map application
Status progression
- Accepted, en route to pickup, collected, en route to delivery, delivered; each event stamped with device time and location at capture
Proof of delivery
- Recipient name, on-screen signature, photograph, timestamp; mandatory before a job can close
Failure capture
- Structured reasons: recipient absent, address wrong, refused, access denied, rescheduled by recipient; free text secondary
Cash on delivery
- Amount collected recorded at handover, tracked as a liability against the driver until remitted
Sync
- Full offline operation for an entire shift, queued and reconciled on reconnection
Data model
- Job → StatusEvent
- Trip → Stop
- ProofOfDelivery
- FailureReason
- Driver
- Vehicle
- CodCollection → Remittance
Invariants
- Status events are append-only; a job's history is a sequence, never a mutable current-state field.
- Proof of delivery captures device time and location at the moment of capture, not at sync.
- A job cannot be marked delivered without a proof record.
- Cash-on-delivery liability is tracked independently of delivery status, because a delivered job with unremitted cash is still an open item.
Offline behavior
Offline-first in the strict sense — designed for a full shift with no connection. Conflict resolution favours the driver's device for status and proof, because the driver was there.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Where riders are contracted rather than employed, the business may have no authority to mandate the application at all.
This has to be established before the build. A rider paid per delivery, using their own phone and their own data, is being asked to absorb a cost for the company's benefit. The workable answers are a data allowance, a small per-job uplift, or employment — all commercial decisions, none of them software. A business that assumes compliance will discover at go-live that half its riders are still using WhatsApp.
End state
What would be true about their day once this is running.
- Dispatch is a board with a history, not a chat scroll.
- Proof of delivery exists at the moment of handover, with a location and a time, and reaches the office instantly.
- Failures carry structured reasons that can be counted and fixed.
- Cash collected is tracked per driver until it is remitted.
This is a deliberate first step toward Fleet Dispatch & Delivery Control Tower — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review