Why supply chain control towers underdeliver and how AI fixes it

The uncomfortable part of many control tower programs is not that the dashboard is wrong. It is that the dashboard is often right, and the work still lands in someone’s inbox.

A late shipment appears. A supplier risk moves from amber to red. A port delay changes an ETA. Then a planner opens the TMS, checks inventory in the ERP, asks a warehouse lead whether a substitution is possible, copies a screenshot into email, messages customer service, and waits for someone with authority to approve the least bad option. The control tower has created visibility, but the organization is still operating through handoffs.

That gap is why the benefits of supply chain control tower investments have disappointed so many teams. FourKites’ 2026 survey of 250 U.S. supply chain leaders found that only 22% of shippers with more than $1 billion in revenue believe their current control tower is highly effective at driving action. Only 2 in 10 organizations said they can understand 75–100% of what is happening in real time, and 75% still need 3–10 systems to make decisions. [1]

A first-generation control tower usually gave teams a shared view of orders, inventory, transportation milestones, and exceptions. An AI-powered supply chain control tower goes further only if it can improve the quality of incoming signals, predict which exceptions matter before they harden into service failures, and push decisions into the systems where people already work. The distinction is simple enough. One shows the operating picture. The other helps change it.

Visibility Was Never the Hard Part

The original promise was reasonable: bring fragmented supply chain data into one place, expose exceptions earlier, and give cross-functional teams a common operating picture. For global shippers dealing with multiple carriers, warehouses, suppliers, plants, and customer commitments, that is not cosmetic. A shared view can reduce arguments about which spreadsheet is current and help leaders see patterns that local teams experience only as daily friction.

But a shared view does not automatically create shared execution. The work after detection is where many control towers thinned out: validating whether the event is real, deciding whether it affects a customer promise, identifying the practical options, choosing who has authority to act, updating the right systems, and telling the next team what changed. When those steps remain manual, the tower becomes another place to learn that the day has gone badly.

That is why broad market enthusiasm is less interesting than the operating evidence. A control tower can be strategically important and still fail at the desk level. The question is not whether visibility has value. It does. The question is whether the visibility is clean enough, timely enough, and connected enough to shorten the path from exception to action.

The First Break: Weak Event Capture

Most control tower failures start before the dashboard loads. If carrier events arrive late, use inconsistent status codes, omit handover detail, or fail to distinguish a routine delay from a true exception, the analytics layer has to guess. That is not a visualization problem. It is a signal problem.

nShift’s 2026 analysis makes this point directly: many organizations keep investing in the analytics layer while underfunding event capture and normalization. The quality of carrier feeds—their timeliness, consistency, exception detail, and handover visibility—determines whether a tower can support action rather than merely display movement. [2]

This is where otherwise sensible programs lose credibility with planners. A lane looks healthy until a milestone fails to update. A shipment is marked in transit, but the last reliable scan is already stale. A carrier reports a delay, but not enough context to know whether to expedite, rebalance inventory, or notify the customer. The tower can still render all of this beautifully. It just cannot support a confident decision.

Data hygiene also changes the economics of automation. An AI model can normalize messy inputs better than a rules-only system, but it cannot create operational truth from missing events. If the organization has not graded its carrier feeds, mapped common status codes, and identified where handovers disappear, it may automate the same uncertainty that used to sit in a spreadsheet.

The Second Break: More Alerts, More Work

Once a tower begins surfacing more exceptions, the next failure mode appears quickly: alert volume rises faster than decision capacity. Teams that wanted proactive management end up with a longer queue of unresolved items.

McKinsey describes a pharmaceutical manufacturer receiving more than 200 exception messages per day after implementing a new planning system. McKinsey has also found that supply chain planners spend 40–60% of their time on transactional activities rather than value-adding strategic work. [3][4]

Those numbers matter because they explain a familiar implementation surprise. Leaders see a control tower generating more exceptions and assume the organization has become more responsive. Planners experience the same result as triage inflation. They now have a better list of problems, but not necessarily better rules for deciding which ones deserve attention, which ones can wait, and which ones should be resolved without human intervention.

Alert overload is rarely solved by tuning thresholds alone. The deeper issue is that most alerts are not equal. A delayed shipment carrying slow-moving inventory does not deserve the same escalation path as a delayed shipment tied to a retail promotion, a production line, or a service-level penalty. A supplier issue on a low-risk component should not compete for the same attention as a shortage that will stop a plant. If the tower cannot rank exceptions by business impact, it forces humans to do that ranking manually.

A dashboard that stops at the left column creates awareness. A working operating model helps resolve the right column.

The Third Break: Detection Without Execution

The most damaging gap is not that control towers failed to see enough. It is that, after seeing, they often left execution scattered across other tools.

FourKites, citing Gartner data, reports that an average disruption requires at least 34 manual system updates across 6 platforms. [1]

That is the post-demo problem in one sentence. The executive view shows the red dot. The operating team still has to touch transportation, warehousing, order management, planning, customer communication, and sometimes finance or claims. Every copy-paste step introduces delay, interpretation, and ownership ambiguity.

Globalia put the limitation plainly in early 2026: control towers “show what is happening, not necessarily how to fix it.” The same practitioner view also warns that “Control towers do not run logistics. People do. The best outcomes happen when technology amplifies human expertise instead of pretending to replace it.” [5]

That is not an argument against control towers. It is an argument against pretending that visibility is an operating model. If a late load requires a rebooking, a customer notification, a revised dock appointment, and an inventory promise update, then the tower has to participate in that chain. Otherwise, the tower is merely a well-lit waiting room for manual work.

What AI Actually Changes

The useful AI story is narrower than the marketing story. AI does not make a control tower valuable by adding a smarter-looking interface. It helps when it changes four mechanical parts of the work: signal normalization, early prediction, impact-based prioritization, and workflow routing.

First, AI can help clean and reconcile messy signals. Carrier events, weather feeds, port status, order data, inventory positions, and customer commitments rarely arrive in a neat sequence. A useful tower has to make those signals comparable enough to support decisions. That includes identifying stale events, resolving conflicting status messages, and translating carrier-specific milestones into operating states the business understands.

Second, prediction gives teams time to act before an exception becomes a failure. A late ETA is only useful if there is still a viable response window. If a model can identify a likely miss early enough to rebook capacity, shift inventory, or warn a customer before a service commitment is broken, the tower has moved from reporting to intervention.

Third, AI can prioritize by consequence rather than by event type. The system should not simply ask, “What changed?” It should ask, “What changed that threatens revenue, service, production, inventory, or cost?” This is where supply chain context matters. The same delay can be irrelevant in one lane and expensive in another.

Fourth, the output has to land where the work happens. That may be a TMS for rebooking, an ERP for order commitments, a WMS for dock or allocation changes, a planning system for supply-demand tradeoffs, a ticketing tool for exception ownership, or a collaboration channel for approval. The control tower does not need to replace every system. It does need to stop handing people a diagnosis with no execution path.

For readers evaluating agentic execution patterns, the important shift is from “AI recommends” to “AI completes bounded work under defined controls.” That transition is covered in more depth in Agentic AI in Supply Chain 2026, but the control tower implication is straightforward: autonomy only helps when the decision is frequent, well-bounded, auditable, and connected to the systems that execute it.

The Benefits Are Real Under the Right Conditions

Vendor-published results show what is possible, not what every buyer should expect. FourKites reports AI-powered control towers achieving 4–8 month payback periods. It also describes a food and beverage manufacturer that reduced detention costs by more than $500,000, cut OTIF penalties by about $800,000, and improved logistics team productivity by 35%. [1]

Those figures are worth taking seriously because they map to operational failure points: detention, service penalties, and planner productivity. They are not just dashboard adoption metrics. But they should not be treated as average-market guarantees. Results like these depend on the volume of repeatable exceptions, the quality of carrier and order data, the organization’s willingness to automate decisions, and the degree of integration with existing execution systems.

This is also where business cases often go soft. They count hours “saved” by better visibility without asking whether the work actually disappears, shifts to another team, or returns during escalation. A stronger case traces one exception type from detection through resolution and measures which steps shrink: fewer status checks, fewer manual updates, faster rebooking, lower detention, fewer penalties, fewer customer-service escalations, or less planner time spent reconciling systems.

Readers looking for a fuller metric compilation can use the companion analysis on control tower software ROI. The point here is more basic: the economics improve when the tower removes work from the exception chain, not when it merely makes the exception chain more visible.

Start by Grading the Feeds, Not Buying Another View

A second-generation control tower program should begin with a feed review that is blunt enough to be useful. Which carriers provide timely events? Which ones send milestone updates too late to support intervention? Where do handoffs disappear? Which exception codes are too vague to trigger action? Which lanes or modes generate the most manual verification?

This is not glamorous work, but it prevents expensive confusion later. A carrier with weak event quality may still be operationally important, but the tower should treat its signals differently. Some events may need confidence scores. Some lanes may require supplemental tracking. Some exceptions may need human validation before automation is allowed. Without that discipline, AI will appear inconsistent when the real issue is uneven input quality.

• Timeliness: whether events arrive early enough to change the outcome.
• Consistency: whether status codes mean the same thing across carriers, modes, and regions.
• Exception detail: whether the feed explains what happened well enough to guide a response.
• Handover visibility: whether the organization can see where responsibility moves between parties.
• Decision usefulness: whether the data supports a specific action rather than another investigation.

The practical test is whether a planner can trust the event enough to skip a manual check. If not, the dashboard has not reduced work. It has only changed where the work begins.

Automate One Frequent Decision End to End

The temptation is to build the comprehensive dashboard first: all lanes, all suppliers, all products, all exceptions. That makes for a strong steering committee slide and a weak operating pilot. A better starting point is one high-frequency decision where the organization already knows the pain.

For example, a shipper might choose detention prevention on repeat lanes, late-load rebooking, customer notification for likely OTIF misses, inbound appointment rescheduling, or inventory transfer recommendations for predictable stock imbalances. The exact choice matters less than the shape of the decision. It should occur often enough to measure, have clear ownership, use data that can be improved, and produce an action in an existing system.

The end-to-end part is non-negotiable. If the tower predicts a likely detention event, the workflow should identify the responsible load, assess appointment and facility constraints, recommend or trigger the next action, update the relevant system, and notify the accountable team. If the process still requires a planner to interpret the alert and manually coordinate across six tools, the AI layer has not solved the control tower problem.

Connect to the Tools People Already Use

Control towers underdeliver when they become one more destination. They work better as an orchestration layer that pushes structured decisions into the daily flow of transportation, planning, warehousing, customer service, procurement, and finance.

That usually means integration with the TMS, ERP, WMS, order management, planning, ticketing, and collaboration tools already carrying operational authority. It also means defining which system owns which record. A customer-service team should not be asked to trust a tower notification if the order promise in the ERP says something else. A warehouse should not receive appointment guidance that conflicts with the dock schedule. A transportation team should not accept a rebooking recommendation if the carrier tender process still lives elsewhere.

This is where organizational design meets system design. Someone has to decide when AI can act, when it can recommend, when it must escalate, and who reviews the exception path. Those controls should be boring, explicit, and visible. Without them, teams either distrust automation or let it create new forms of cleanup work.

The broader supply chain AI ROI trap is assuming that model performance converts directly into financial impact. It rarely does. P&L impact comes when a recommendation changes a cost, service, inventory, capacity, or labor outcome. The same distinction is visible in the move from pilot to P&L: a good prediction is only the middle of the story.

Autonomy Is Coming, But It Is Not Evenly Here

The direction of travel is clear enough. FourKites reports Gartner projections that 60% of supply chain disruptions will be resolved without human intervention by 2031 and that 15% of daily logistics decisions will be made autonomously by AI agents by 2028. [1]

Those are forecasts, not proof that autonomous control towers are operating at scale today. They are useful as a signal of where analyst expectations are moving, but they should not replace implementation due diligence. A company with fragmented master data, inconsistent carrier feeds, unclear exception ownership, and no integration into execution systems will not leapfrog those constraints because a vendor adds agents to the roadmap.

The more credible near-term path is bounded autonomy. Let the system resolve narrow, repetitive disruptions where rules are clear and consequences are understood. Keep humans in the loop for high-value, ambiguous, customer-sensitive, or policy-changing decisions. Expand only when the organization can prove that automation reduced work and improved outcomes without creating hidden cleanup elsewhere.

A Practical Test for the Next Control Tower

Before approving another control tower investment, ask where the workflow ends. If it ends with a dashboard, the program will probably reproduce the old disappointment in a cleaner interface.

A stronger program can answer three questions in operational terms:

• Which data feeds are trusted, which are weak, and how will weak feeds be handled?
• Which high-frequency decision will be automated end to end before the scope expands?
• Which execution systems will receive updates, tasks, recommendations, approvals, or automated actions?

That is the line between visibility and execution. Control towers underdelivered when they detected problems faster than organizations could resolve them. AI can close that gap when it improves data hygiene, prioritizes exceptions by business impact, and routes decisions into daily workflows. If the tower still ends at the screen, it will likely underdeliver again.

References

1. Why Supply Chain Control Towers Didn't Deliver on Their Promise (And What's Changing), FourKites, 2026.
2. Supply chain control tower 2026: dashboard to decision, nShift, 2026.
3. Harnessing the power of AI in distribution operations, McKinsey, 2024.
4. Building a digital bridge across the supply chain with nerve centers, McKinsey, 2021.
5. Logistics control towers: Useful or overhyped?, Globalia, January 2026.