Pilot offline ePOD capture with a controlled billing handoff

A driver records a delivery in an area without coverage. The application says “saved”. Later, the upload times out. The driver submits again, and the office sees two delivery records while a partial-receipt remark appears on only one.

An offline pilot should prove how one observed handoff becomes one accepted business record, even when messages repeat or arrive late. Scope the first delivery to a known route group and evidence policy. Preserve the driver's observation and let the authorised review process decide what it means for shipment and billing status.

Define what can be captured offline

Agree the required shipment reference, route/stop context, quantities, remarks and approved evidence fields. Decide how the device receives the assignments it may act on and what happens when those assignments change while offline.

Do not permit the device to invent a new destination or customer commitment from free text. Where a stop is cancelled or redirected, the reconciliation process needs to compare the offline assignment with the authorised change.

The pilot requires the mobile capture application, local protected storage, synchronisation service, TMS test interface, evidence repository and a review queue. Identify the operational owner, mobile/IT owner and billing or customer-service reviewer before testing.

Give each state a precise meaning

“Saved” should never imply destination acceptance unless that acknowledgement exists. A service response can also confirm technical receipt without confirming business validation; the interface needs to make that distinction visible.

Replay a small route with difficult stops

In this illustrative pilot, ten stops are assigned across two test devices. Six are complete online deliveries, two are captured offline, one is a partial receipt and one contains a wrong-assignment correction. These primary categories sum to ten.

For the partial stop, ten cartons are expected and eight are recorded received. The remaining two stay unresolved through upload and destination processing. A successful synchronisation must not turn the event into a full ten-carton receipt.

For an offline stop, restart the application after capture but before upload. Then reconnect twice and interrupt the response after the server may have accepted the first request. Confirm that the same capture identity survives all attempts and produces no additional delivery quantity.

Use fictional or appropriately authorised redacted records. The test should prove the relationship between observations and outcomes without exposing real recipient data unnecessarily.

Trace a capture into the billing review queue

For a combined offline/partial case, use the illustrative capture C41. The driver records eight of ten cartons and the required attachment, then saves both durably on the device before it reports “captured”.

If the service has the metadata but lacks the required attachment, keep the submission incomplete and retry the file transfer under the same capture. If the TMS has accepted D19 but the device missed the response, recover that acknowledgement. Neither failure should require the driver to record the delivery again.

Define the exact billing output for the pilot: for example, a review task containing the accepted receipt reference, expected/received quantities, outstanding evidence and applicable customer policy. Creation of that task is distinct from invoice creation. Repeat the handoff and require one review case per accepted receipt. A policy revision updates that case through a recorded review; it does not create a second billable delivery.

Design retries around business identity

Assign a stable identity to the capture before the first transmission. Preserve source device/capture context, event time, submission time and the shipment/stop relationship. A retry should carry the same business identity; it is a new transmission attempt, not a new delivery.

Keep the device-recorded time and offset separate from server receipt time. An offline device clock can be wrong; retain the observation and flag implausible timing for review rather than replacing it silently with upload time. Assignment versions also matter when a stop was cancelled on the server while the device was offline.

If the destination cannot report whether an uncertain request was accepted, stop automated resubmission and route reconciliation to the support owner. A network error does not prove that no business action occurred.

Corrections need a separate version or linked action. If a driver selected the wrong consignment, do not silently edit the original identifier and resend it as a new clean event. The reviewer should see what changed and confirm how the original destination record is corrected.

Keep device and server authority aligned

The device can capture an observation within its assigned scope. The server validates the identity, permitted action and evidence policy. Customer operations decides disputed delivery outcomes; finance applies the billing rule.

OWASP's object-level authorisation guidance is relevant when a mobile API accepts a shipment identifier: permission must cover the requested record and action. OWASP — Broken Object Level Authorization. Test with controlled users and shipments that are deliberately outside the user's assignment.

Define how long offline authorisation remains usable, what happens when access is revoked and how retained evidence is protected on a lost device. Those are policy and implementation decisions that require explicit testing. Do not assume that later server rejection removes data already stored locally.

Set acceptance around recovery and truthful status

A proposed acceptance pack should show that every seeded capture survives the approved restart test, duplicate submissions create no duplicate business record, partial quantities and remarks remain intact, and wrong-assignment cases are held or corrected through the approved path.

Test failure before local persistence too, including unavailable storage. The app must show that the record was not saved and offer the approved fallback; the later upload process cannot recover data that never persisted. Reconcile the ten planned stops to accepted captures, unresolved local records, corrected attempts and explicit fallback records so an omitted stop cannot disappear from the result.

Measure capture time, correction effort, time from reconnection to acknowledged evidence and the age of unresolved uploads. A route with no network coverage should not be judged by the same elapsed-time target as an online stop; show the states and dependencies separately.

Test the evidence file and its metadata together. A successfully uploaded image with a missing shipment relationship is still unusable evidence.

Define the fallback before the route starts

If capture or sync fails, the driver needs an approved fallback for recording the handoff. The office needs a way to identify which stops use that fallback and how they will be reconciled. Do not require staff to fabricate a digital signature later to make the record appear complete.

The stop procedure disables new automated destination actions while preserving authorised captured data. Reconcile locally stored, received, accepted and uncertain records before resuming. Already-accepted records require supported corrections rather than deletion.

Prove one handoff through an unreliable network

The pilot's value is truthful state and recoverable evidence. The office should know what was observed, what remains on a device, what the TMS accepted and which decision still belongs to a person.

Next actions

1. Select the route group, devices and customer evidence policy.
2. Agree capture, authorisation, correction and fallback rules.
3. Run the ten-stop test with restart, interruption and repeated uploads.
4. Reconcile every capture against the destination and review queue.
5. Approve a supervised route only after the recovery evidence is complete.

Scope the offline pilot around a route group, mobile/TMS systems and the failure that currently loses or duplicates delivery evidence.