The vast majority of freight dashboards currently available display an enormous amount of information. Trips in transit, trips delivered, trips delayed, compliance flags, vehicle locations, and SLA counters ticking down lane by lane. Somewhere in that wall is the one trip that actually needs a phone call in the next ten minutes. Finding it is the ops team's job, and on a network running hundreds of trips a day, that job is close to impossible to do well, every single day, without missing something.
The real failure of these systems is that they stop displaying data to the user and have the operations team manually prioritize the hundreds of trips. This is not how a supply chain control tower is supposed to function. A control tower should be able to tell the user which 12 of 428 active trips it needs to pay attention to and why.
Most freight visibility and control tower vendors promoted ‘more visibility’ as the core value proposition over the years. The approach suggested that as long as shippers could see more of their network in real time, they would perform better. This became less effective as more and more shipment-level data became available to large shippers and was processed by increasingly sophisticated systems. However, turning this information into timely enough actions remained a challenge.
McKinsey’s research on supply chain nerve centers has found that a shift from monthly/weekly planning and control tower review cycles to near-real-time decision-making is underway. Rather than having the decision surface appear on a weekly basis for review, planners make and resolve a decision in near real time. The missing function of a control layer is to determine on an ongoing basis what needs a human to manage.
There is considerable evidence that the future of supply chain technology development will be around the control layer of the supply chain and how it can identify meaningful variation in data to affect on-time delivery to market. The control layer of the supply chain must then classify this variation in terms of importance and respond accordingly. Simply having more data than currently is not in itself a competitive advantage; the harder problem is deciding what matters. In fact, as more and more data is collected, the competitive disadvantage of being unable to make timely decisions as to what to do with the data in question will increase. Seeing more was the last decade's competitive edge in logistics management systems. Deciding faster is this decade's.
What alert fatigue actually costs a freight team
There's a well-documented cost to getting this wrong, and it isn't unique to logistics. Research on operational alerting across industries, such as IT operations to security monitoring, consistently finds that when every event gets flagged with the same urgency, people stop responding to any of them with real attention. One widely cited analysis found that attention to a repeated alert drops by roughly 30% with each additional reminder and that a majority of alerts in high-volume systems turn out to be redundant, noise the recipient has learned, correctly, to filter out.
Freight operations are not exempt from this. A planner or ops lead fielding dozens of low-priority pings a day for things like a five-minute GPS gap or a routine geofence check-in learns, over time, to skim past all alerts a little faster, including the one buried in the middle of the list that's actually an SLA breach in progress. The system that cries wolf on trivial deviations is the same system that gets ignored on the day a genuinely urgent one shows up.
What exception-first design looks like in practice
This is the specific design problem Libera's control tower is built to solve. Rather than surfacing every trip with equal visual weight, it treats the shipment count as background information and puts the exceptions front and center: out of hundreds of active trips running on-time in the high 90s percentile, it shows only the handful genuinely at SLA risk, ranked by urgency, with the reasoning attached rather than left for a human to reconstruct.
That same design principle runs through Libera's AI agents. The trip monitoring agent doesn't just log GPS pings; it's built to detect missing signals, delay risk, and compliance exceptions automatically, so a dropped tracking signal that's genuinely a problem gets flagged, while a brief, expected gap in a low-connectivity zone doesn't generate noise. The freight intelligence agent lets a planner ask, in plain English, what's actually driving cost or SLA risk on a given lane, instead of manually cross-referencing three separate reports to find the answer. And the platform doesn't stop at flagging problems; it's designed to surface savings opportunities the same way it surfaces risk, translating pattern-level cost leakage across a freight network into a concrete monthly number a finance team can act on, concerning line items no one has time to review.
This mirrors where the wider industry is heading with AI in supply chain and logistics operations. Recent analysis of AI-driven control towers argues that the technology only earns its investment when it moves from monitoring to decision execution, when it stops being a viewer that shows more dashboards and starts functioning as a coach that converts insight into a resolved outcome. A control tower that can't compress a fleet's status into a short, ranked action list is still, functionally, just a very detailed dashboard.
Why this matters more as freight networks scale
The value to a shipper of having a TMS exception-first design does indeed increase as the number of shipments managed by the TMS increases. For a shipper with 10+ shipments per day managed by a TMS, it is generally relatively easy for a planner to maintain all of the various details of all of the various shipments in his/her head. But for a shipper with hundreds and even thousands of shipments per day managed by a TMS, it will very quickly become apparent that the planner will not be able to maintain all of the various details of all of the various shipments in his/her head and that the amount of low-value ‘noise’ that needs to be dealt with by them will increase at roughly the same rate as the volume of signals of value to the planner.
Also, the problems of managing supply chain risk and saving costs are very similar. That is why a supply chain control tower that only automates the saving of the service level (i.e., an SLA breach is detected early) is not a full automation of the supply chain. A system that also automatically detects cases of cost leakage is a full automation of the supply chain. Such a system flags all exceptions in order to save them. These exceptions can be delays, non-compliance, rate anomalies or underutilization of lanes
Predictive logistics plays a role here too: catching a delay risk or a compliance gap before it becomes an SLA breach only works if the system is forecasting forward from live signals, not just reporting what already happened. Real-time tracking data is the raw material; the exception layer is what turns it into something a planner can act on before the problem, not after it.
Two control towers, one network
It's worth walking through the same freight network under both approaches, because the difference only shows up in what happens next.
Visibility first: A shipper's ops lead opens the morning dashboard and sees 428 active trips, most of them green, a handful amber, and a few red. Nothing on the screen tells her which amber flags are drifting toward a real SLA breach and which will self-resolve in the next hour. She scans the list the way she does every morning, opens the trips that look most concerning based on gut instinct and yesterday's memory, and starts making calls. By the time she reaches the trip that was actually the most urgent, which is a compliance flag on a lane with a tight delivery window, 40 minutes have passed, and the window has narrowed considerably.
Exception-first: The same ops lead opens a control tower that has already done the ranking. Of the 428 active trips, it tells her 12 need attention, ordered by how close each one is to breaching its SLA or its compliance window, with a one-line reason attached to each: "Compliance flag, tight delivery window, escalate now" sits at the top, not buried in position 30 of an alphabetized list. She acts on the first item within minutes, not after a 40-minute scan of a board that treated every trip as equally worth her attention.
Nothing about the underlying freight changed between these two mornings: the same network, same 428 trips, same handful of genuine problems. The only difference is whether the system did the work of deciding what mattered before handing the screen to a person or left that decision, silently, to whoever happened to be looking at the dashboard that morning.
When demoing potential TMSs, the pertinent question could be, "Out of all the things happening on my network right now, how many things does your system think I actually need to look at, and why?”
This is a really good test for any TMS demo. The demo should not be about how to show all the trips. Any serious transportation management system can do that. The demo should test the transportation management system’s ability to automatically keep all stakeholders up-to-date on all relevant information and, automatically, bring to the attention of the human decision-maker the information that can be used to make a decision. This is what we designed in the Freight TMS; this is what we designed for freight settlement and margin recovery; this is what we designed for capacity planning; and this is what we designed for route planning. We have tried to build a system that will automatically make as many decisions as possible and bring to the attention of the people the few decisions that they need to make. And we have tried to make sure that those decisions are brought to their attention as quickly as possible. A system that brings to the attention of a human decision maker a decision that they need to make in a list of 428 other numbers, all looking the same until one of them ceases to look the same, is not a very good system.