← Back to Supply Chain Review Logistics Technology

Kuehne + Nagel Rolls Out Digital Control Tower for Peak Planning

Source: Kuehne + Nagel · 2026-05-18 · 16 min read
中文

Supply Chain Action Points

Read this first — the conclusion, and the moves to make:

  1. Start 60 days before peak: establish four baselines with your own finance definitions — exception rate, alert-to-decision latency, exception closure time at median and 90th percentile, and surprise cost as a share of total freight spend.
  2. Write the thresholds into the contract before go-live: high-severity alerts acknowledged by a named owner within 15 minutes, exception closure at median under 24 hours and 90th percentile under 72 hours, and false alarms under 1.5 per shipment-day.
  3. Hold arrival estimate deviation to plus or minus 1.5 days at the 85th percentile and require 99.5 percent telemetry uptime, with the data source list and definitions attached to the agreement.
  4. Assign a named owner to every alert class, and give operators a dollar-denominated spend authority so routine exceptions can be cleared without escalation.
  5. Fix the decision layer in writing — what triggers a reroute, who it escalates to — and put the write-back interface to your transport management system (TMS) into the acceptance criteria.
  6. Cut surprise cost below 1.5 percent of total freight spend within two quarters, measured by your finance team, and review alert precision and configuration drift every quarter.
Skip to the detailed analysis ↓
Summary

Kuehne + Nagel rolled out a digital control tower giving customers a unified view of ocean, air and road shipments with configurable alerts. The forwarder said the tool improves exception management and capacity decisions, and is being adopted broadly ahead of the summer peak to cut surprise costs.

The Analysis

A control tower is a queue with a nicer dashboard, and I mean that as a compliment. Kuehne + Nagel has rolled out a digital control tower that gives customers one view of their ocean, air and road shipments, with alerts they can configure. The forwarder says the tool improves exception management and capacity decisions, and it is being adopted broadly ahead of the summer peak. The stated goal is to cut surprise costs.

Notice what is and is not in that sentence. What is in it: a unified view, configurable alerts, exception handling, capacity calls, and a cost target. What is not in it: a single number. A control tower without numbers is just a screen, and a screen does not move cargo.

So I am not going to review this product, and I would not trust anyone who reviewed it from a press release anyway. What I will do is tell you how to accept one if you are the one buying, because the technology is not the hard part. The hard part is agreeing, in writing, what it must do.

Start with the queue. A control tower is not a magic window into your supply chain. It is a queue with a better dashboard. Think about what actually happens to a shipment: it passes a series of steps, each with a service rate, and problems surface as exceptions — a vessel slipping, a flight cancelled, a truck missing a slot, a customs hold. A control tower does one thing: it makes the exception visible earlier than you would have found it yourself. That is valuable, and it is also exactly all it does. Everything that happens after the exception becomes visible is still up to you.

So the first question is not what the dashboard looks like. It is: how much earlier? A unified view of ocean, air and road is only worth something if the visibility arrives before a decision window closes. If an alert tells you a vessel is late when the cargo has already missed the connecting truck, you have bought a very good history book. The metric for visibility is not coverage, it is lead time.

Then come the configurable alerts. I love this feature on paper and I fear it in practice, and I will explain why. Configurable means someone has to configure it. If nobody owns the configuration, you get either a firehose of alerts that everyone mutes, or a trickle so thin that you miss the events that matter. The configuration is not a settings menu; it is a policy. Treat it like one, with an owner, a review date, and numbers attached.

Then exception management. Here I want to slow down, because this phrase hides the whole problem. Managing exceptions has three parts. Detecting them — the tool's job. Deciding about them — a human job, with an authority limit. And closing them — a sequence of actions that ends when the exception is genuinely resolved, not when somebody has replied to an email. Most systems are good at part one and silent about parts two and three, and parts two and three are where the money is.

Then capacity decisions. This is the part a control tower can genuinely change, and it is worth understanding why. Capacity decisions are made against a forecast, and the forecast is only as good as the visibility feeding it. If you can see next week's ocean and air volumes in one place, two weeks before peak, you can book slots earlier, negotiate from a position of certainty, and avoid the spiral where late booking forces airfreight at ten times the cost. The value of the tower is not the screen. It is the booking date it lets you hit.

One thing about that unified view that the brochure will not tell you. Ocean, air and road do not agree on what a shipment is. An ocean booking, an air waybill and a road consignment carry different identifiers, different event vocabularies and different timestamps, and the hard, unglamorous work of a control tower is reconciliation — deciding that four separate messages describe one movement. If that reconciliation is wrong, the dashboard is confidently telling you the wrong story, and a confident wrong answer is worse than no answer at all. So when you evaluate a tool like this, ask to see the matching logic run on your own messy data, not on a clean demo file. A shipment count that differs by 5 percent between your transport management system and the tower is normal in month one; the question is whether anyone has been given the job of chasing that gap.

A control tower is not your transport management system and it is not your warehouse system either. It sits above them, and it is only as useful as the connections beneath it. If the tower sees the ocean leg but your transport management system holds the truck appointment, then the exception you actually care about — the one where a late vessel breaks the truck — lives in the seam between two systems, which is exactly where nobody is looking. Map your exception types onto your systems before you buy anything. Any exception that spans two systems needs one named owner, or it will fall into the gap and stay invisible to both.

Now the bottleneck. With a control tower, the bottleneck is almost never the data. It is decision rights and definitions. Two things kill these projects. First, nobody agrees what counts as an exception, so the exception list is either bloated with noise or missing the real ones. Second, nobody can act on an exception without escalating, so the queue grows while the tool suggests increasingly urgent fixes. A control tower does not remove the bottleneck; it puts the bottleneck in front of you, in a nicer colour, and the only question is whether you have the authority structure to clear it.

An analogy, because it helps. Think of a control tower as a hospital monitor bank — heart rate, blood pressure, oxygen, all on one screen, alarms when something crosses a line. The monitor does not treat anyone. It decides who the staff should look at first. If staffing is thin and the alarm thresholds are badly set, the monitor is just a more efficient way to feel helpless. If staffing and thresholds are right, it is transformative. Same screen, opposite outcome. The variable is never the monitor.

Now, quantify first, then optimize. Before you sign for any control tower, measure four baselines over a full quarter. One: your baseline exception rate, with a specific definition. Two: your current alert-to-decision latency — from the moment a problem could have been known to the moment someone decided. Three: your exception closure time, median and 90th percentile. Four: your surprise cost, the share of total freight spend that lands as unplanned. Without these four, you cannot tell whether the tower helped, and you will end up arguing with the provider about vibes.

Let me put numbers on it, assumptions stated. Assume 200 shipments a month. Assume an exception rate of 8 percent, so 16 exceptions a month. Assume your current median closure time is 36 hours, and you do not actually know your 90th percentile, which is itself a finding. Assume a stuck shipment costs 150 dollars a day all in — detention, expedited freight exposure, and some allowance for customer pain. Cutting median closure from 36 to 18 hours recovers about three quarters of a day on each of the 16 events, roughly 1,800 dollars a month, over 21,000 a year.

That is the routine saving, and it is not the reason to buy. The reason is the tail, and it is bigger than people expect. Assume that out of a year's 192 exceptions, four are severe — the missed vessel, the customs hold that runs a week, the peak-season shortfall. Assume each severe event costs 40,000 dollars in expedited freight and penalties. If better visibility and a faster decision process convert even two of those into manageable events at half the cost, you have saved 40,000 dollars. That is more than the entire routine saving, from four events.

Now the peak scenario, because that is what this class of tool is being sold for. Assume the exception rate rises from 8 to 15 percent in the two months before peak — 30 events a month instead of 16. Assume that during peak the cost of a stuck day doubles to 300 dollars, because the only recovery is expedited airfreight. Over those two months you have 60 exceptions, and every day of decision latency you remove is worth 60 times the daily damage avoided. That is why a control tower is a peak tool: the same latency costs far more in June than in February.

Surprise cost deserves its own paragraph, because it is the one the forwarder named and it is the one you should check yourself. Surprise cost is not a technology metric; it is a financial one. It is the money that shows up because a decision was late or invisible — airfreight you did not plan, detention you did not budget, a penalty you did not see coming. Take your total annual freight spend, isolate the unplanned part as a percentage, and that is your number to beat. If it is 4 percent of a 24 million dollar spend, that is 960,000 dollars of surprise. Getting it to 1.5 percent recovers 600,000 dollars. That is the bar a control tower has to clear, and it is a bar, not a slogan.

And one on the operating model, because tools get blamed for structure problems that were always there. How many people will work the exception queue, and at what hours? A tower that alerts around the clock but has staff for nine hours a day is telling you the truth about your coverage, whether you like it or not. Assume 16 exceptions a month and 20 minutes of human work per routine exception — that is five and a half hours a month, trivially absorbable. Now assume peak at 30 exceptions a month with severe events needing an hour of work each, and you suddenly need a named operator on call. Size the team to the peak exception load, not the average, or the queue will clear itself by being ignored.

Now the thresholds, the ones I would actually put in a scorecard. Alert-to-acknowledgement: a high-severity alert must be seen by a named owner within 15 minutes during operating hours. Lower than that and your alerting is theatre. Exception closure time: median under 24 hours, 90th percentile under 72 hours. Arrival estimate deviation: hold it to plus or minus 1.5 days at the 85th percentile, because that is where warehouse labour, trucking slots and customer promises start to hold.

Three more, and the scorecard is complete. Alert precision: at least 75 percent of fired alerts should be genuine, with false alarms under 1.5 per shipment-day, because alert fatigue is the fastest way to make an expensive system worthless. Telemetry uptime: 99.5 percent or better on the data feeds you depend on — a tower that goes dark during a system-wide disruption is dark exactly when you need it. And surprise cost share: down to 1.5 percent of total freight spend within two quarters of full adoption, measured by your finance team, not the provider's dashboard.

Notice, again, that none of these thresholds mention the words digital, smart, platform or solution. That is on purpose. Those words describe an invoice, not an outcome. If a provider cannot put the numbers above into a contract with a measurement method, you are not buying a control tower, you are buying a subscription to a nicer screen.

One caution on the metrics providers love and I distrust: activity numbers. Dashboards viewed, alerts generated, exceptions logged. Those measure that people are opening the tool, not that the tool is working. An operation can log a thousand exceptions and close none of them, and the activity chart looks wonderful. The only numbers that decide anything end in a decision or a dollar — closure time, precision, surprise cost. If the monthly report leads with logins, read that as a signal.

Now to build versus buy, which for control towers has a specific shape. Buy the aggregation and the plumbing — pulling ocean, air and road data from multiple sources into one view is genuinely hard and genuinely commodity, and you should not build it. Build the decision layer — who owns which exception, what the escalation path is, how much money an operator can spend without asking, and what triggers a reroute. That layer is your margin and your differentiation, and it is exactly the part a platform cannot give you, because it depends on your customers, your contracts and your appetite for risk.

One more number worth tracking, and it is the one your commercial team will cheer for. On-time-in-full delivery measured against the promise you made to your customer, not against the carrier's schedule. Those are two different numbers, and control towers historically move the first quickly and the second slowly. Track both. Assume you ship 2,400 orders a year at a 94 percent order promise; lifting it to 96 percent stops 48 orders a year from turning into a service failure, and at 500 dollars in credits and rework per failure, that is 24,000 dollars on top of everything else — before you count the renewals it saves.

The pitfalls, in the order I see them. Alert fatigue: if the configuration is not owned and tuned, the team mutes the tool within a month. The definition trap: two groups disagree on what an exception is, and the numbers become unusable. The latency illusion: a unified view that updates every four hours is not real-time, and it will arrive after the window it was supposed to protect. Integration debt: a tower that does not write back into your transport management system (TMS) leaves staff copying between screens, and copying is where errors are born. And the ownership gap: nobody has been given the authority to act on what the tower reveals, so it becomes a very expensive way to watch problems happen.

Before any demo, send the provider four questions. Show me your reconciliation logic on a file I supply, with my messy identifiers. What is the median and 90th-percentile detection latency in your production system, not in your reference architecture? Which of my thresholds do your standard commercial terms accept, and where is that written down? And how does the platform behave when a feed goes stale — does it alert on its own blindness, or does it simply go quiet? A provider that answers those in writing earns a scoped pilot. One that answers by booking another slide deck does not.

One more, and it is the one that decides renewal almost every time. Peak passes, volumes drop, and somebody asks whether the subscription still earns its keep. If you never established the surprise cost baseline and the closure time baseline, you cannot answer, and the contract quietly lapses or quietly renews by inertia. The providers that get renewed are not the ones with the prettiest screens; they are the ones whose customers can prove a number moved.

So how would I actually take delivery of one of these? Pick the peak. Not the whole network — one peak window, one trade lane or one business unit. Instrument the four baselines before you start. Set the thresholds above in the contract, with the measurement method written down: who counts, from what timestamp, by what definition. Assign a named owner for every alert class. Give operators a spend authority in dollars, so they can act without a meeting. And agree a quarterly review where precision and closure times are checked, because configuration drifts and forecasts age.

Keep one thing straight in your head the whole time. A control tower does not reduce uncertainty. It reduces the lag between uncertainty appearing and you responding to it. The uncertainty was always there, sitting in a spreadsheet nobody refreshed, in a phone call somebody meant to make. The tower just makes it show up earlier. That is a real and often large saving, but it is a saving in latency, not in risk. If you buy it expecting risk to disappear, you will be disappointed by a very good tool.

Let me close the loop. Queue, bottleneck, thresholds. A control tower is a queue with a nicer dashboard, and the dashboard is the cheap part. The bottleneck is decision rights and definitions, and the value is the surprise cost you stop paying because your decisions now land before the window closes. Configure the alerts with an owner, measure the four baselines, put the thresholds in writing, and score the whole thing on the tail, not the average.

If I had to give your operations lead one line for Monday, it would be this: a control tower is only as good as the decision it accelerates, so write down the threshold and the owner before you sign, and measure surprise cost yourself.

↑ Back to the key points

— By Ravi Chandran

Kuehne + Nagelcontrol towerdigitalvisibilitypeak