A customer portal that answers the questions the phone used to

A mid-sized freight operator running domestic and cross-border shipments. Operations ran on a transport management system that worked well internally and was invisible to customers. Every status question – where is it, when will it arrive, where is the paperwork – arrived by phone or email and was answered by an operations coordinator reading a screen aloud.

The company did not want to replace the transport management system. It wanted its customers to see what it already knew.

Discovery ran for three weeks and started with the operations team rather than the customers. Two weeks of logged status requests were categorised, which showed that four question types accounted for the large majority of contact: current status, expected delivery date, proof of delivery, and where an invoice-related document was.

That finding set the scope. The portal did not need to expose the transport management system. It needed to answer four questions extremely well, and to say clearly when it could not answer.

We also established what the portal must not do: it must not become a second place where operational data could be edited. Read access to operational data, write access only to the things customers own – booking requests, contact details, notification preferences.

The interface is organised around a shipment rather than around the systems the data comes from. A customer sees one shipment record with status, timeline, documents and contacts, regardless of which of the three back-end systems each field came from.

Two design decisions did most of the work. First, the shipment list defaults to the shipments that are actually in motion, because that is what people open the portal to check. Second, every status carries a plain-language explanation and a timestamp for when it was last confirmed, so an unchanged status reads as a known state rather than a stale screen.

The layout was designed mobile-first, in a plain, dense, high-contrast style intended for someone checking a delivery from a loading bay rather than reading at a desk.

The portal is a separate application with its own database, synchronised from the source systems rather than querying them live. This was the central architectural decision: it protected the transport management system from portal traffic, kept the portal fast and available if a source system was briefly down, and made access control a property of the portal rather than a modification to operational software.

Synchronisation runs on a short interval with an explicit source of truth for every field, idempotent writes, retry with backoff, and a reconciliation job that compares both sides and reports divergence. Every sync is logged and inspectable, so a coordinator asking why a shipment looks wrong gets an answer in a minute.

Account hierarchies are modelled as an organisation tree with permissions resolved at the record level, so a forwarder sees their own shipments and those of their sub-accounts, and nothing else.

The operations team stopped being the interface to its own data. Status questions that arrive now tend to be genuine exceptions rather than routine lookups, which is a different and more valuable conversation.

Because the portal was built as a separate application over a synchronisation layer, the company also gained something it had not asked for: a place to add customer-facing capability without touching operational software. Booking requests and delivery notifications were added in the months after launch without a single change to the transport management system.