A driver app should connect each assigned job to the person carrying it out, the quantities delivered, any exceptions and the supporting proof of delivery. A useful workflow is: receive the assignment, confirm responsibility, check the stop, record the delivery outcome, submit evidence and review the result in dispatch. Tapping Complete should not replace those checks.
This guide is for logistics businesses evaluating apps for their own delivery operations. It is not a guide to bidding for work on a public freight marketplace. For the broader purchasing decision, see our transport management system selection guide for Malaysia. The workflow below is a set of design and acceptance-test recommendations; exact screens and capabilities depend on the chosen system.
Confirm ownership when a driver accepts a job
Before starting, the driver needs a job number, pickup and delivery stops, time windows, quantities, handling instructions and the contact details needed for the work. Separate Assigned, Awaiting acceptance and Accepted so dispatch can distinguish an unread assignment from an acknowledged responsibility.
Decide whether drivers explicitly accept work or dispatch assigns it directly. A driver may need to report a vehicle mismatch, a scheduling conflict or an inability to carry out the job, but that does not mean every operation needs an unrestricted decline button.
For example, Nash's driver app documentation separates new work from accepted work and describes both route-level and individual delivery assignments. That is one product's approach, rather than a universal interface standard.
Test reassignment after the original driver has opened a task. Can that driver still act on it? When an offline phone reconnects, does it recognize the latest assignment? Ask for a traceable record of the change, including who made it, when and why. Otherwise, two drivers may both believe they own the same delivery.
Check each stop before recording delivery
A multi-stop route needs stop-level outcomes. Completing one stop should not close the entire shipment. At each destination, verify the recipient or receiving location, the goods and the quantities before recording the handover. Add loading confirmation where the operating process requires it.
Agree whether drivers may change the stop order and who approves an exception. A location update on a map is not, by itself, evidence that goods changed hands.
Keep the main actions easy to find: open the stop, check the goods, record quantities, collect evidence and submit the outcome. Navigation, contact and exception reporting can sit alongside that flow. These actions should be carried out while safely parked, not while driving.
Decide what proof of delivery must contain
Electronic proof of delivery, or ePOD, needs enough context to show which job and stop the evidence belongs to. Consider the following fields against each customer's handover requirements:
Job and stop identifiers: connect the evidence to the right delivery and line items.
Quantities and outcome: expected, received and outstanding or rejected quantities, with consistent units.
Recipient confirmation: the relevant name or role, signature or another agreed confirmation method.
Supporting evidence: useful handover or exception photos and notes, without unrelated people or private information.
Times and responsibility: the time of the field record, the upload time and the account that made it.
Onfleet's proof-of-delivery documentation describes photos and recipient signatures. Ask which evidence is optional, which is required and what happens when an attachment is missing.
Do not make every field mandatory simply because the software can collect it. A business customer requiring a stamped delivery note has different needs from a parcel recipient whose agreement permits a delivery photo. Limit viewing and export by role, and agree how long personal details and attachments should be kept.
Record partial delivery without closing the whole job
Consider a demonstration order with 10 expected items. The recipient accepts 8 and rejects 2 because their outer packaging is damaged. Record all three quantities, the reason and the relevant evidence against that stop.
Record quantities, the exception reason and evidence together so a partial delivery is not mistaken for a complete handover.
A rejection, a shortage, an absent recipient and an unreachable address are different outcomes. Rejected goods may still be on the vehicle; a shortage needs investigation into the missing quantity. One generic Failed status can hide those differences. Onfleet's task completion guidance provides separate failure reasons such as an unavailable recipient, incorrect or missing items, and damage.
Dispatch should be able to assign a next action, such as redelivery, return or investigation, with a responsible person. Preserve the initial field record and add reasons for later corrections. Whether rejecting two items changes the freight charge depends on the business agreement and a separate cost review; the app should not infer that decision solely from quantity.
Separate saved on phone from received by dispatch
Break an offline claim into testable questions. Is the assigned work available before connectivity drops? Can the driver view stops, record quantities and collect evidence without a connection? Does the data survive an app restart? What is sent automatically after connectivity returns?
Onfleet's driver app settings describe configurable offline operation and evidence requirements. This does not establish that every driver app supports unrestricted offline use. Check the product version, enabled settings and limits with the supplier.
For a clear user experience, distinguish Saved on device, Waiting to upload, Upload failed and Received by server. A failed upload should preserve the record and allow a retry. Repeated submissions should not create duplicate delivery evidence.
Also test a task that is cancelled or reassigned while the driver is offline. On reconnection, the system needs a way to resolve the conflict instead of letting the old phone state silently overwrite the current instruction. In dispatch, separate Received, Evidence incomplete, Exception unresolved and Ready for reconciliation. A delivery record is not confirmation that charges are approved or payment has been received.
Run six acceptance tests before rollout
Use a driver phone and a dispatcher account in a test environment, with anonymized or demonstration orders:
Normal delivery: accept the job, verify the full quantity and submit the required evidence. Dispatch can open the matching stop and attachments.
Reassignment after acceptance: the original driver can no longer execute the job, the new driver receives the current task and the change remains traceable.
Partial rejection: expected 10, received 8 and rejected 2 reconcile. The reason and the next handling step for the rejected goods are recorded.
Recipient unavailable: the stop moves to an actionable exception state, not a successful delivery. Dispatch can arrange the next step.
Offline recovery: test local storage, restart and synchronization within the supplier's stated offline limits. Confirm that dispatch receives the complete record.
Retry and correction: repeated submissions do not duplicate the business outcome; quantity corrections retain the original values, the editor and the reason.
For each test, record the result, the gap, the proposed remedy and the responsible party. A tick beside ePOD on a feature list is not enough. For a Malaysian fleet, also test the languages actually used by staff, their usual phones, service-area addresses and warehouse handover instructions. These are deployment checks, not assumptions that localization is already complete.
HUACODE's overseas logistics solution lists driver-side order details, loading and unloading photos, and document upload. Use those as a starting point, then ask for a demonstration of partial delivery, offline recovery and correction history against your own workflow. Through our project enquiry page, share an anonymized order, the current delivery-note format and your three most frequent exceptions. Request a clear breakdown of existing capabilities, configuration and development work.
Sources checked: 11 October 2026.