A 35-person freight and 3PL operation. Five systems, 90 minutes every morning, delayed shipments discovered by customer complaint. Here is what we connected, the six tiles we built, and the three specific outcomes that were measurable in six weeks, including the Monday morning email chain that stopped on its own.

This is a case study from a build we completed in the first quarter of 2026. The client is a mid-size freight forwarding and 3PL operation, 35 people across three depots, handling 400 to 600 consignments a day. We have anonymised the company name and kept the numbers as close to real as we are able to share.

Before: the 90-minute morning check

The operations director started every working day with a 90-minute reconciliation exercise. Not by choice, she had tried to get it under an hour several times, but because the data she needed to run the day lived in five separate places.

The TMS (transport management system) showed consignment status as of the last carrier update. The WMS (warehouse management system) showed stock and dock movements as of the previous evening's batch. The carrier tracking portal required her to log in per carrier, three logins, three interfaces, to get exception alerts. The customs status dashboard was a separate system again, updated twice daily. The customer service inbox was the fifth source: when something went wrong overnight, the first she usually heard about it was a complaint.

The morning routine was: TMS, then WMS, then each carrier portal, then customs, then inbox. Write up a summary. Send the Monday morning email chain with status for each depot. Arrive at the 9:30 ops call with a picture of the day that was already 30 minutes out of date.

The things this process missed regularly:

Delayed shipments that had not yet generated a customer complaint but would by noon. Depot capacity imbalances that became overflow problems by end of week. Carrier SLA deterioration that was visible in aggregate across the week but invisible on a day-by-day check. Customs clearance delays that sat in one system and did not surface until a driver arrived at the border with incomplete paperwork.

None of these were dramatic failures. They were the chronic cost of a process that required a senior person to spend 90 minutes assembling context that already existed, just distributed across five systems that did not speak to each other.

What we built

The brief from the discovery call was straightforward: the operations director needed to walk into the ops call at 9:30 knowing exactly what was late, what was at risk, and whether any depot was heading for trouble, without spending her morning pulling it together.

We connected four sources: the TMS (via API), the WMS (via scheduled export, updated every 15 minutes), the three carrier tracking portals (via their respective APIs), and the customs status system (via a daily export that refreshes at 6am). The board has six tiles:

Consignment pipeline. Total in transit, on dock, and delivered today, split by depot. Updates every 15 minutes from the combined TMS and WMS feed. The number the ops director previously had to calculate manually from two systems.

Delayed shipments by carrier. Any consignment more than two hours past its expected scan, grouped by carrier and flagged by severity. Pulls from the carrier tracking APIs so exceptions surface before the customer calls.

Customs clearance queue. Shipments awaiting clearance, by origin country and broker, with the expected clearance window. Pulls from the customs system's 6am export. Not real-time, but enough to flag what needs a call before the driver departs.

On-dock vs in-transit split. By depot, by shift. Lets the depot manager see whether they are accumulating or clearing, the signal that predicts end-of-day overflow three to four hours before it happens.

Daily throughput vs target. Consignments despatched today against the daily plan, by depot. The number that drives the Monday morning email.

Carrier SLA by week. On-time delivery rate per carrier over the rolling seven days. Surfaces deterioration before it becomes a formal review conversation. Pulls from the TMS delivery confirmation feed.

Build time was six days. Day one: discovery and data source mapping. Days two and three: connecting the TMS and carrier APIs, validating the consignment pipeline tile. Days four and five: WMS integration, the on-dock split, and the throughput tile. Day six: customs feed, SLA tile, review with the ops director. The board went live on day seven, with a one-hour handover call and a written walkthrough of how each tile is populated.

After: six weeks in

The morning check is now eight minutes. The ops director opens the board, reviews the delayed shipments tile and the customs queue, checks the on-dock splits across the three depots, and goes into the 9:30 call with current data. She described the difference as the gap between reporting on the past and managing the present.

Three specific outcomes that were measurable within six weeks:

Delayed shipment flag, three hours earlier. In week two, a consignment stuck at a carrier depot overnight appeared on the delayed shipments tile at 7:15am, before the customer service inbox had a single complaint. The ops director called the carrier at 7:30, rerouted the shipment by 9am, and the delivery landed on time. Under the old process, the first signal would have been a complaint call at 10am.

Depot overflow avoided on a Wednesday. The on-dock split tile showed Depot 2 accumulating faster than clearing at 11am on a Wednesday. The ops manager redistributed two afternoon collections to Depot 3. No overflow by end of day. The previous week, the same pattern had caused a weekend backlog that took Monday to clear.

Customer service tickets down 40% in six weeks. The team did not set out to measure this, but the customer service lead noticed and flagged it. The most common ticket category, "where is my shipment?", dropped from an average of 34 per week to 20. The ops director's read: when the team can see exceptions as they form, they resolve them before they become customer problems.

The Monday morning email chain stopped in week two. Not because we asked them to stop it, because the dashboard answered the question the email was trying to answer. The ops director mentioned it at the six-week check-in as the thing she had not expected to notice.

What made it work

None of the underlying data was new. The TMS, WMS, carrier portals, and customs system all had the information before we built the board. The five-system morning routine existed because the data was correct in each system and wrong everywhere else, no single view combined it.

The build was straightforward technically. The APIs were documented. The WMS export was consistent. The customs system's 6am refresh was a known cadence. What took time was the discovery, understanding what the ops director was actually asking when she ran the morning check, and which of the hundreds of data points available in those five systems answered her real questions versus the ones she had learned to ask because they were the only ones she could get.

The delayed shipment tile is the one she checks first every morning. Not because we designed it that way, because it answers the question she was spending 30 of her 90 minutes trying to answer manually.