“Customs clearance for a single DHL shipment moves through five separate parties - broker, customs authority, classifier, permits officer, auditor - each owning a distinct stage. The existing system tracked what was inside it. Nobody tracked where a shipment was stuck or who was responsible. Delays accumulated in the coordination gaps, not in the data entry.”
DHL's customs clearance operation in Israel handles hundreds of active shipments at any given moment. Each clearance moves through a chain of five parties, each owning a distinct stage of the process. The system in place was a legacy Hebrew form platform - functional for data entry, built for one shipment at a time. Monitoring the whole queue, chasing status from government offices, and coordinating between the five parties in the chain all happened outside the system: by phone, by email, by paper. I was brought in to design a new monitoring and coordination layer that would sit alongside the existing system and replace the paper process entirely.
How the coordination layer was built.
Five parties, one clearance
Research started with PM system requirements review and interviews with lead managers and customs brokers. The clearance process required coordination across five distinct roles: broker, GSC (customs authority), classifier, permits officer, and auditor. Each owned a separate stage and operated independently. The research confirmed what the managers already suspected - delays were almost never caused by data entry errors. They came from status gaps between parties. Nobody had a complete picture of where a shipment stood across all five stages at once. The initial brief framed the problem as data entry inefficiency. Two interviews overturned that. Data entry was fine. The delays happened in the gaps between parties - nobody could see which stage was stuck, or whose problem it was. The issue wasn't the system. It was everything that happened between systems.
A worktable, not another form
The legacy system was a form engine - powerful for data entry into a single shipment record, useless for managing 150 active shipments in parallel. The core design decision was to build a separate monitoring layer. Each shipment becomes a row. Each clearance stage - GSC, OCR, classification, permits, audit - becomes a column. Color-coded urgency flags on the left (red, amber, green) tell the broker where to focus before they read a single label. The component library and color system were built from the urgency logic outward: high urgency first, status indicators as secondary density.
My first design was exactly what the brief asked for: a better version of the existing form. A manager review ended it in one sentence - "this handles one shipment faster. We need to manage 150 at once." I abandoned the single-shipment mental model entirely and rebuilt around the queue. That meant walking away from weeks of work and telling the client the thing they had asked me to design was the wrong thing to design.
Chat as the paperless bridge
The operational problem was not the data - it was the communication. Every coordination step between a broker and a government office happened by phone or email, leaving no record and creating delays that had no trail. The solution was a chat component embedded inside each shipment row. A broker opens a shipment and sees every party in the clearance chain listed - GSC, Classifier, Permits, Auditor, Manager. Messages go directly to the right party, in context, attached to the shipment record. The conversation becomes the audit trail.
The lead PM rejected this component in the first review. His position was that brokers would never run government coordination through a chat interface. Nobody had asked for it, and dropping it would have cost me nothing. I argued to keep it, on the grounds that the delays lived in the coordination gaps and no amount of better data entry would touch them. I was carrying a feature the client did not want, against the person who owned the roadmap. After launch it became the most-used component in the system.
What we shipped.
The DHL Mini Dashboard: a worktable of 150+ active shipments, each row carrying the full clearance status across five stages and a live urgency flag. The chat panel opens inline, keeping broker-to-authority communication attached to the shipment record and out of email. Built in parallel with the existing legacy entry system, not as a replacement - as the coordination and monitoring layer that was missing.
What it changed.
The whole paperless argument had been aimed at eliminating paper forms. That was the visible half. The real paper was in the phone calls and the emails between five parties, none of which left a record anybody could audit - and nobody had framed that as a design problem because it was not happening inside any system. What I take from this project is that the brief describes the work people can already see. The thing worth building is usually sitting in the gap between the systems, which is exactly where nobody has thought to ask for it.
Comms Mission Planning
Plan Connectivity in the Battlefield