When a delivery goes wrong, the argument is rarely about the part. It is about whether it arrived, when, and who took it. A driver app earns its keep by answering those three questions in seconds, months later, without anyone remembering the day. That only works if the app records a small, fixed set of things at every stop, every time. This article lists that set, explains why each item matters, and names the things that are tempting to collect but better left out.
The five things to record at every stop
Keep the list short enough that drivers do it on a wet afternoon with one hand. In our experience five items are enough:
- The assignment: which invoice or order the stop belongs to, who assigned it, and when. This links the stop to the paperwork the customer already has.
- Arrival time and place: the moment the driver marks “arrived” and the device location at that moment. One point, not a trail.
- Proof of delivery: a photo of the goods where they were left, or the name of the person who received them. For counter and back-door drops a photo is faster and harder to dispute than a scribbled signature.
- The outcome: delivered, partially delivered, or not delivered, with a reason from a short list (closed, refused, wrong address, damaged). Free text is optional; the reason code is not.
- Completion time: when the driver marked the stop done, so dispatch can see the run progress and the customer can be told what happened.
Everything else, from route order to mileage, can be derived or added later. These five are the ones that settle disputes and feed billing.
Why each item matters
The assignment link is what turns a photo into evidence: a picture of a box on a step means nothing unless it is tied to invoice 10432 and the stop that was meant to deliver it. Arrival time and location answer “you never came” and “you came after we closed”. The proof answers “we never got it”. The reason code is what makes the exception list useful the next morning: three refusals at the same address are a conversation with the customer, not three re-deliveries. Completion time closes the loop for dispatch and for anyone who has to say when the next run leaves.
Recording the same five things for every stop also means reports are comparable. Average stops per run, failed-stop rate by reason, and time between arrival and completion become real numbers instead of impressions.
What to leave out, and why
A phone can collect far more than a delivery needs, and the extra data creates risk without adding value. In Canada, personal information handled in commercial activity falls under the federal privacy law (PIPEDA) or, in British Columbia, the provincial law considered substantially similar to it; both are built on principles that include limiting collection to what the purpose needs and limiting how long information is kept. Three practical consequences follow for a driver app:
- No always-on tracking. Record location at the moments that matter (arrival, completion) rather than a continuous trail of where a driver was all day. If live vehicle location is needed for dispatch, keep it to shift hours and say so to the drivers.
- Photos of goods, not people. A proof photo should show the parcel and the doorway, not the customer’s face or the inside of their premises. Keep the camera pointed at the delivery.
- A retention rule. Decide how long stop records and photos are kept (long enough to cover warranty and billing disputes), write it down, and delete on schedule.
Leaving these out also keeps the app fast. Fewer fields means fewer skipped fields.
What this looks like in ORCA
Our Track module grew out of the driver and delivery app we run for our own parts deliveries: stops are created from invoices, drivers work a list on a phone, each stop closes with a photo and a status, and dispatch sees progress and history. Live vehicle location, trips and replay come from the separate tracking platform for supported devices. Location limited to shift hours and signature capture are in development, so today a photo is the proof of delivery. The service businesses workflow shows how delivery fits with jobs and customer history, and the pricing page lists what a Track setup includes.
What to do this week
- Write the five items on one page and compare them with what your drivers record today, on paper or in chat.
- Agree the short list of reason codes for a failed stop; keep it under eight.
- Decide the retention period for stop records and photos, and who deletes them.
- Tell drivers exactly what the app records and when, before the first run.
- Review failed stops by reason every Friday for a month; the pattern will tell you what to fix first.
Sources
- PIPEDA requirements in brief – Office of the Privacy Commissioner of Canada (accessed 2026-10-21)
