The driver app is where most of the value of a route system is captured or lost, and it receives the least attention in evaluation because the buyers are not the users. This checklist redresses that.
Take it into demos and score it. Better still, hand it to two drivers and let them score it.
Tier 1 — Essential
Core workflow
- Full day's manifest visible, with sequence and time windows
- Stop detail: customer, address, access notes, contact, items
- Complete a normal stop in three interactions or fewer
- Capture signature, photograph and recipient name
- Item-level confirmation including partial delivery
- Short, specific exception vocabulary with reasons
- One-tap handoff to navigation using the service point coordinates
Reliability
- Full offline operation for an entire shift
- Local storage of all captured data, with queued sync
- Duplicate-safe sync (idempotent submissions)
- Visible pending-sync indicator
- Recovery after app restart or device reboot with no data loss
Usability
- Touch targets usable with gloves
- Readable in direct sunlight and at night
- One-handed operation for primary actions
- Plain-language errors with a next step
The person who will use the app should score the app. Buyers consistently over-value dashboards and under-value the number of taps at a stop, because they never make sixty stops in a day.
Tier 2 — Valuable
- Previous visit notes and history for this customer
- Live ETA calculation and automatic customer notification
- Barcode scanning, with a controlled manual fallback
- Driver-initiated data corrections (wrong address, access change)
- Vehicle checks and defect reporting in the same app
- Break and duty-time visibility where hours rules apply
- Photo compression and upload prioritisation
- Constrained resequencing within time-window limits
- In-app messaging with dispatch
- Multi-language support
- Text scaling and accessibility support
- Practice or training mode with sample data
Tier 3 — Situational
| Feature | Matters when |
|---|---|
| Payment capture (card, cash) | Money changes hands at the stop |
| Mobile invoicing and pricing | Sell-from-truck operations |
| Van inventory view and adjustment | Route accounting operations |
| Temperature reading capture | Cold chain |
| Signature-free contactless flow | Consumer delivery |
| Parts and job details | Field service |
| Time and attendance | Where the app is the clocking system |
| Fuel entry | No fuel card integration |
| Trailer and asset coupling | Trailer operations |
| Hours of service / tachograph integration | Regulated driving |
The tests that reveal depth
Run these in the demo, on a device, not on a slide:
- Aeroplane mode. Complete a full stop with photo and exception. Force-close the app. Reopen. Restart the device. Restore connectivity. Confirm exactly one record synced.
- The awkward stop. Partial delivery, two damaged items, customer refuses one line, driver leaves the rest. How many taps, and is the resulting data usable?
- The sunlight test. Take the device outside. If you cannot read it, drivers cannot either.
- The glove test. Wear work gloves and complete a stop.
- The battery test. Run the app with the screen on for four hours and measure drain. Apps that keep GPS at maximum accuracy continuously will not survive a shift.
- The interruption test. Take a phone call mid-capture. Does the app retain state?
- The wrong-address test. Can the driver report a bad location in under fifteen seconds, and does it reach anyone?
- The update test. Push an app update while there is unsynced data on the device.
Scoring approach
Weight tier 1 at 3, tier 2 at 2, tier 3 at 1 for applicable items only. Then apply two overrides:
- Any tier 1 reliability failure is disqualifying, regardless of total score. An app that loses data offline cannot be fixed with training.
- Task time above five interactions for a normal stop is disqualifying for high-stop-count operations, whatever else it does well.
Questions readers send us
How much should the driver app weigh in the overall decision? Heavily — commonly a third or more of the total score for operations where drivers make many stops a day. The office team can work around a mediocre planning interface; drivers cannot work around a bad app sixty times a day.
Should we insist on a native app? Judge the behaviour rather than the technology. Native apps generally handle background sync, camera, storage and power better, but a well-built progressive web app can meet the requirements. Test against the reliability items above and let the results decide.
What if the best planning product has the worst app? Weigh the daily cost. A weak app costs seconds per stop, data quality and driver goodwill every single day; a weaker planning engine costs a few percent of route efficiency. In high-stop operations the app usually matters more. Also ask whether a third-party driver app can integrate.
Can we build our own driver app? It is technically feasible and rarely wise unless your workflow is genuinely unusual and you have the capability to maintain a mobile application indefinitely — including operating system upgrades, device changes and security patching. Most who try underestimate the ongoing burden rather than the initial build.
How do we test an app before buying? Request a pilot with real routes and real drivers for at least two weeks. Vendors that will not support a pilot on real data are telling you something. Score it with the checklist above at the start and end of the pilot.
