Multi-party operations · Mobile
Four parties, one pickup. A facility, a carrier, a driver, and a shipper each hold a different piece of the same event — and no two facilities run it the same way.
The situation
The physical pickup of freight is a single event, and four organisations record it separately. The facility knows what left the gate. The carrier knows who they sent. The driver is the only person actually present. The shipper finds out last.
None of the four is wrong. They simply hold different fragments of the same event, in different formats, at different times — so the fragments get reconciled afterwards, by phone, by someone who has to call three other people to establish something that was already true hours ago.
That phone call is not a habit anyone chose. It is what is left over when an event concerning four parties is only ever recorded one party at a time.
The actual problem
Nobody is missing information. They are missing the same information at the same time.
No two facilities run a gate the same way. Some check in by appointment, some by seal, some by paperwork, some by a guard who recognises the driver. A system that forces one universal workflow is abandoned at the first facility that does it differently — so the workflow itself had to become configurable, without making the app harder for a driver standing in the rain.
Native iOS and Android applications for the people in the yard, kiosk workflows for facilities that prefer a fixed terminal, and web portals giving each party its own view of the same record. Photo and document capture at the point of the event, verification steps, and backend services holding the shared truth. Facility profiles change the sequence of steps without forking the application.
Scope
Working principle
Software should adapt to the operation, not the other way around.
Next case study
A carrier running on Google SheetsStart with the operation
Every engagement starts the same way, whatever the industry: understanding how the work actually happens.
Start a conversation →