For twenty years, the transport management system has been the backbone of logistics operations. Today it is reaching its limits on two fronts at once: the networks it serves have changed beyond recognition, and the way TMS software is built and bought has barely changed at all.
It is 7:40 on a Monday morning. The plan was locked on Friday afternoon. Before the first coffee is finished, two carriers have reported capacity problems, a production line is running three hours late, a key customer has moved a delivery window, and the planner who knows how the northern region really works is off sick.
None of this is unusual. That is the point.
By mid-morning, the plan the TMS is executing describes a network that no longer exists. So the team does what logistics teams have always done. They pick up the phone, open a spreadsheet, override the system and firefight their way to the end of the day. Tomorrow, they will do it again.
These teams are not doing anything wrong. They are running a modern, volatile, multi-party network on a model that was designed for something else. The transport management system, as a category, is reaching its limits.
At Bluerock, we have built and implemented TMS software for years. We have seen these limits from the inside, in our own product as much as in our customers' operations. This article is our honest account of why the model is running out of road, and what we believe comes next.
The TMS was built to do one job well: take a plan and execute it. Receive the orders, plan the loads, tender to carriers, dispatch, track, settle the invoices. In a stable network with predictable volumes and one planning logic, that job is enormously valuable.
And it delivered. For two decades, the industry optimised transport inside its own box: cheaper freight, fuller trucks, tighter tours, better carrier rates. Those gains were real, and many companies still have some left to capture.
But the curve is flattening. Squeezing another percent out of a route matters less and less, because the biggest costs and risks no longer sit inside the transport department. They sit in what transport decisions do to the rest of the business.
Consolidating loads to save 3% on freight is not a good decision if it quietly pushes up stock and working capital somewhere else. The value has moved outside the box, and a system designed to optimise the inside of the box cannot see it. Later in this series, we look at how transport decisions ripple across production, procurement and finance → and why local transport optimisation is not the same as true orchestration.
The networks a TMS has to run today look nothing like the ones it was designed for. Transport management as it was built breaks under multi-leg, multimodal, multi-party complexity. Four forces have changed them, and none of them is going away.
Fewer people, more complexity. Europe alone has around 502,000 unfilled truck driver positions, a 13% shortage, and roughly 660,000 drivers are expected to retire within five years (IRU, 2025). The same squeeze hits planning offices. Volumes grow, but the number of people who really understand the network does not. Too much depends on a handful of experienced planners and the knowledge in their heads.
Volatility is the norm, not the exception. In a 2025 survey of 401 supply chain leaders, 54% said they face disruption every day, and "firefighting mode" was named the top obstacle to improving their processes (Celonis, 2025). When disruption is daily, a plan made once and executed as written is a fiction.
Networks grew by addition. Acquisitions, new sales channels, new countries and outsourced flows have each added a new leg, a new partner and, often, a new tool. The result is a set of planning islands: one tool per leg, per mode or per partner, each optimising its own piece. Email and spreadsheets fill the gaps between them: in a 2025 survey of forwarders, 3PLs and carriers in Europe and the Middle East, 61% of logistics teams still relied on email and spreadsheets to work with overseas partners (Deep Current, 2025). A local fix in one island creates a problem in the next, and nobody sees the chain reaction until it lands. → To help companies break this cycle, we have quantified the hidden costs of running logistics on disconnected systems.
Take a common case. A sea freight shipment arrives late. The transport team cannot see stock levels at the factory warehouse, so it pays to expedite goods that were not urgent. The expensive decision was perfectly logical inside the transport island, and wrong for the business.
Customers expect more. Narrower delivery windows, real-time visibility, white-glove and installation services: every promise made at the point of sale has to be kept in a network that is getting harder to control. In a 2025 survey of 5,000 online shoppers in the US, UK, France and Germany, 40% wanted home deliveries within a specific time slot, typically two to three hours (Avery Dennison, 2025).
We see the effects in our own conversations with logistics teams. Planners spend hours checking vehicle compartment capacity and cleaning rules in spreadsheets. Orders travel across several hubs, but no system follows them from first leg to last. Teams want to automate consolidation, but every rule still lives in a person's head.
The industry's answer to all of this has been exception management. Plan once, execute, and when something goes wrong, raise an alert so a person can fix it.
It was a genuine step forward fifteen years ago. Today it carries a hidden assumption: that the plan is right and reality is wrong. Every deviation is treated as an anomaly to be corrected, one alert at a time.
But when disruption is daily, deviations are not anomalies. They are the normal state of the network. A system built around exceptions turns into a stream of alerts, and planners turn into full-time firefighters. The more volatile the network, the more people it takes to keep the plan alive, at exactly the moment those people are hardest to find.
Exception management also works at the wrong level. It flags the late truck. It does not tell you what that late truck means for the production line, the warehouse dock, the customer promise or the next three loads that depend on it. It reports problems one by one, while the consequences travel across the network.
The real upgrade is not a better alert. It is moving from managing by exception to resolving issues before the customer ever sees them, with people involved where their judgement matters most.
If the network had changed and the software had kept pace, this would be a story about features. It is not. The way TMS software is built, sold and implemented has stayed remarkably stable for twenty years, and we include ourselves in that.
You adapt to the software, not the other way round. A traditional TMS arrives with its own screens, its own data model and its own idea of how transport should work. The customer's process bends to fit. Where it does not fit, users build workarounds: side spreadsheets, manual checks, emails that never reach the system. A management system ends up recording what people did, rather than helping them decide what to do.
Every change becomes a project. A new customer, a new rule, a new depot: each one turns into a change request to the vendor, a quote and a release cycle. The business moves weekly; the software moves quarterly.
Implementation risk sits with the customer. A typical TMS project takes many months, sometimes years, disrupts the organisation while it lasts, and still ends with something that does not quite fit. The customer pays for the software, the configuration and the consultants, and carries the risk that the business case never materialises. The vendor and the customer describe the same process in different words, write it down in documents that each side reads differently, and discover the gaps after go-live.
"Standard" is chosen out of fear. Customers ask for standard software not because their business is standard, but because they have learnt what customisation costs: technical debt and painful, expensive upgrades. So they accept a poor fit to avoid a worse one.
Everyone works the same way. The senior planner with fifteen years of experience and the new hire in their first week get the same screens and the same level of automation. Automation tends to be all or nothing, switched on for everyone or for no one.
Closed by design. Many TMS platforms were built as one large system around a closed data model. That makes them hard to scale as the network grows, hard to connect to the data of partners and other systems, and hard to open up to AI: an agent cannot act inside a system that was never designed to let anything else in. In the same 2025 survey, 47% of logistics executives named integration with legacy systems as the biggest barrier to adopting new technology (Deep Current, 2025).
None of this is a failing of any one vendor. It is the shape of a software category that was designed when networks were simpler and change was slower. Bluerock has built TMS software in exactly this model, and we have felt its limits in our own projects. That is precisely why we no longer think the answer is a better version of the same thing.
One way to put it: the S in SaaS is switching places. Software as a Service, a tool your people operate and work around, is becoming Service as a Software: software that does more of the work itself and fits the way each business actually runs.
The obvious response to both fronts is AI. Add an assistant, bolt on an agent, and let it handle the alerts.
It is tempting, and it misses the point. An AI agent placed next to a TMS inherits every limit described above. It works on top of the same planning islands and the same rigid process. Worse, whatever the agent does outside the system of record, the TMS still has to do itself to keep the process moving, so the work is duplicated rather than removed.
AI can make a broken model faster. It cannot make it whole. That is why Bluerock chose not to follow the race to bolt AI onto existing software, and to rethink the foundations instead. We will come back to what "AI at the core" means in the next article in this series.
If the TMS has reached its limits, what replaces it is not a bigger TMS. It is a different operating model: orchestration. Transport orchestration is the continuous coordination of transport decisions across the whole network, its legs, modes and partners and the functions that depend on them, with people deciding where their judgement matters. → For a side-by-side view, see what a TMS does compared with an orchestration layer.
Managing transport means executing a plan and reacting when reality disagrees. Orchestrating transport means coordinating decisions across the whole network, continuously, as reality changes. In practice, that means:
Orchestration is not the same as autonomy. It is not a promise of lights-out logistics or a system that takes decisions away from your people. How much the system decides, and for which tasks and which users, should be a choice the business makes, and can change as circumstances change.
It also requires software that fits the business rather than the other way round: software that is connected, not closed, that follows how a company actually operates, that changes as fast as the network does, and that grows from one urgent problem to the next without a big-bang project.
This is not a feature upgrade. It changes how transport decisions connect to inventory, production, service and procurement, which makes it a leadership conversation as much as an operational one.
Where does your organisation stand? These questions are a good place to start.
If the answers make you uncomfortable, you are not alone. They are the symptoms of a model reaching its limits, not of a team doing a poor job.
The TMS has served logistics well, and its core strengths in planning, execution and settlement still matter. But a model built to execute a fixed plan, in software that customers must adapt to, cannot carry the networks companies run today.
Over the coming weeks, this series explores what comes next: why AI belongs at the core rather than on top, why autonomy should be a dial you control, how orchestration connects transport to the rest of the business, and how to get there without a big bang.
Every network reaches its limits in a different place. Talk to our team about your answers: we will look at where your planning loses time today, and what it would take to orchestrate it without a big-bang project.
Not ready to talk yet? Follow Bluerock TMS on LinkedIn to read the next article in this series: