Status capture in customer portals — once, not twelve times

The forwarder runs its own TMS and serves a dozen major customers, each of whom wants its status updates entered into its own portal — every customer with its own schema, its own status codes, and its own login world: supplier portals, cloud platforms, EDI, CSV via SFTP.

Dispatch and back office typed every status event multiple times — once in the TMS, then into each affected portal. With thousands of shipments per week and 4–8 events per shipment, this choked operational control.

“Loaded” meant something different everywhere: “loaded” in the TMS, “LOADED” in portal A, “AT_DOCK_LOADED” in portal B, IFTSTA code “6” in the EDI feed. The mapping knowledge lived in the dispatchers’ heads.

Penalties for SLA breaches (EUR 50–500 per missed status) were an operational norm. Every new major customer meant a new portal project with weeks of mapping clarification.

Piko captures the TMS activity as a structured status event — shipment, status type, timestamp, location — and distributes it automatically to the relevant portals, each with the right mapping of field translation, status code, and time zone.

Every portal handoff carries its evidence source and mapping version, so that in a penalty dispute the full trail is visible. The mapping is a curated file per portal — maintainable by account management, with no software release.

The TMS remains the system of record; activities are read, not overwritten. Dispatch steps in manually only for edge cases, while routine statuses run automatically.

Seven minutes of manual, repeated data entry per loading event became an automatic distribution — dispatch is back to steering operations instead of filling portals.

The SLA rate per major customer has become measurable: the gap between TMS capture and portal handoff, per status type, per month.

A new major customer is now a new mapping file, not a new integration project — the vocabulary of ‘shipment / stop / status event / mapping’ carries any number of portals.