“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. The feature the lead PM rejected in the first review became the most-used component in the system.
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. The first design was exactly what the brief asked for: a better version of the existing form. A manager review ended it - "this handles one shipment faster. We need to manage 150 at once." The worktable came from abandoning the single-shipment mental model entirely.
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 pushed back on this feature in the first review. He did not think brokers would use it. 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 lead PM rejected the chat component in the first review. His position was that brokers would not use a chat interface for government coordination. He was wrong. The paperless transition argument had always focused on eliminating paper forms - but the real paperless work was in the communication. Moving coordination into the system, attached to the shipment record, was the thing nobody had explicitly asked for and the thing that actually changed how the process ran.
Comms Mission Planning
Plan Connectivity in the Battlefield