A logistics operation almost always runs two systems side by side. The TMS manages routes: orders, drivers, stops, ETAs. The WMS manages the warehouse: picks, packs, stock levels, receiving. Both produce events. Neither was designed to talk to the other.

The result is that the dispatch manager opens the TMS to check route status, then opens the WMS to check if a pick is ready, and carries the answer between the two systems in their head. When the numbers do not match, which happens more often than it should, there is a phone call.

This is the problem a shared operations board solves.

What you are actually connecting

A TMS and a WMS share a natural join key: the order ID. Every route event in the TMS maps to one or more warehouse events in the WMS. The order ID threads them together.

Once you have that join, you can answer questions neither system can answer alone.

  • How long does an order spend in the warehouse between pick complete and driver assignment?
  • Which routes have the most exceptions, and does the pattern trace back to a WMS pick error or a TMS routing issue?
  • When the afternoon hub is overloaded, is it because picks are running late or because route assignments came in too close together?

The dashboard does not replace the TMS or the WMS. It reads from both and puts the joined picture on one screen.

The three tiles that make it worth doing

A logistics operations board needs exactly three tiles before it becomes indispensable. Everything else can come in week two.

End-to-end on-time delivery rate

Not the TMS-reported rate, which counts only the last-mile leg, but end-to-end: from order received in the WMS to delivery confirmed in the TMS. You need both systems to calculate it.

Most teams discover their actual rate is three to five points lower than the TMS reports, because warehouse dwell time was never counted. The tile shows the rolling seven-day rate, broken down by depot, with a trend line so the team sees direction not just today's number.

Exception queue

Every order that has missed a trigger threshold gets a row: address validation error, pick mismatch, carrier delay, damage reported. Each row carries the SLA clock from the moment the exception was raised, the order ID, the owner in each system, and a single-click link to the source record.

TMS and WMS exceptions live in the same list, sorted by customer impact. The dispatch manager does not need to know which system owns the row to triage it. They see the priority and the clock.

Capacity forecast

Tomorrow's planned order volume against today's available pick slots and driver assignments. When these three numbers are on the same screen, the planner can move orders between facilities before the morning shift rather than reacting once a hub is already behind.

This tile alone has saved more than a few 06:00 panic calls in the operations we have worked with.

The schema that makes it work

The tricky part is not the connectors. It is normalising timestamps. TMS systems tend to use UTC internally but display local time. WMS systems vary, and some use event sequence numbers rather than wall-clock time. Before any connector goes live, we agree three things: the time zone, the granularity (minute-level is enough for dispatch), and which WMS event counts as "dispatched" versus "packed".

A minimal shared schema looks like this. One order state table: order ID, state (one of received, picked, packed, dispatched, on route, delivered, exception), timestamp, source (tms or wms), exception type (nullable). One row per state transition, append-only. The dashboard queries the latest state per order for the live view and the full history for dwell time calculations.

Most TMS systems offer a webhook or a polling endpoint for order events. Most WMS systems have a database or a short-interval CSV export. We have rarely needed to build custom parsers, though a small number of older systems require a flat-file import. If a system cannot be connected, a manual upload for that data source is a usable fallback while a proper connector is built.

What changes for the team

The dispatch manager stops tab-switching. The morning standup takes three minutes instead of fifteen. The duty manager can answer "is the south hub behind?" without picking up a phone.

The WMS operator gets fewer calls asking for pick status because the dispatch manager can already see it on the board. The TMS planner gets fewer panic reroutes because overloads are flagged the evening before rather than surfaced mid-shift.

These changes happen in week two, not after a six-month integration project.

What it does not fix

The board surfaces problems faster. It does not solve them. If WMS pick accuracy is low, the exception queue will be long. If TMS route planning is suboptimal, the on-time rate will stay low. A connected view makes these patterns visible quickly enough to act on. It does not make them disappear.

We have built this board for a handful of logistics operations. The outcome they share: within a month, the team stops arguing about whose system is wrong and starts talking about what to fix. That conversation is worth more than any individual tile.

If this sounds like your operation, see how we work with founding clients.