Drivers kept using WhatsApp. The paperwork stopped being typed.

The problem

Every container movement generates an Equipment Interchange Receipt — the handover document recording the box, its condition and its times at the gate. It carries the container number, ISO type, seal, depot, condition codes and timestamps. It is printed by someone else's system and handed to the driver on paper.

Nothing downstream can happen until that paper becomes data. The operator could not raise an invoice, verify a charge, or contest a damage claim until a person had read each receipt and typed it into a spreadsheet. Receipts arrived in batches, late, creased, photographed in bad light. Billing waited on data entry, and every typo became a disputed line item weeks later.

First attempt — and why it failed

The obvious solution was a driver app: a form to capture the receipt at the gate. It was built and deployed. It failed.

The drivers could not read it. Literacy was the constraint nobody had specified, and it made the entire interface — fields, labels, menus, validation messages — unusable by the only people who would ever touch it. No amount of redesigning the form was going to fix a product that assumed its users could read.

This is the part worth reading twice. The adoption cost of the second design was zero — not low, zero — because the driver's job did not change at all. There was nothing to install, nothing to train, nothing to read, and no reason for anyone to resist it. The integration work moved off the driver and onto the server, where it belonged.

How it works

Driver behaviour ends at step 1. Everything after it is server-side.

Validation is where the accuracy comes from

OCR alone is not trustworthy enough to bill from. The container number is the exception: under ISO 6346 it is four letters and seven digits, and the final digit is a check digit computed from the rest. That makes the single most important field on the document self-verifying — a misread can be caught deterministically rather than hoped about. Around that, rules cross-check dates, depots and duplicate movements, so a clean receipt passes untouched and only genuine exceptions cost anyone attention.

Results

From the live system: 3,115 work orders processed · ~2,000 per month, each with one to four photographs · 20 WhatsApp groups monitored · 121 drivers on the roster.

Why the output can be billed from

Extraction is the easy half. The reason the operator can raise an invoice off this data is that every work order passes 22 automated checks before it is marked invoiceable — and anything that fails is flagged for a human instead of quietly going through.

Live flag counts. Every check on this list exists because that failure actually occurred.

The container number anchors each record. Under ISO 6346 it is four letters and seven digits with a trailing check digit computed from the rest, so the most important field on the document is self-verifying — a misread is caught arithmetically rather than discovered on a disputed invoice. Around it, the rules pair each gate-out with its gate-in, reconcile truck against container, cross-check terminals and seals, and cost the trip.

The rest of the portal

Capture was the entry point, not the product. Around it sits the system the office actually works in: driver self-registration with approval gating, so only cleared drivers can submit; a truck register; configurable rules and trip costs; reconciliation of unrecognised phone numbers to drivers; user access control; a full activity log; and recoverable deletions. Every photograph stays attached to its work order — which is why retrieval went from hours to seconds.

Built with

What I do