Future of TMS Shifts from Software Purchase to Operating Model

The Analysis

Let me put this in system terms before I put it in market terms, because the market language is where people lose the thread. A transportation management system is a queue controller. Loads arrive, the system matches each one to a carrier and a price, the load moves, exceptions arrive on top of the moves, and at the end of the month the whole thing settles. Arrivals, matching, movement, exceptions, settlement. That is the entire machine. What the 23 June Logistics Viewpoints report is describing is this machine increasingly being sold with people and capacity attached to it, and that is a much bigger change than any feature comparison suggests.

I have been on both sides. I have sold the system, and I have been the person who had to make the system's output true at seven in the morning when the truck did not come. In every one of those situations, the thing that broke was not a feature. It was the exception queue. The load nobody was watching, the carrier that accepted the tender and then quietly did not cover it, the appointment that slipped by a day and turned into a stockout three days later. Those are queue events, not software events. In its polite market language, the report is telling you exactly that: the software does not clear that queue by itself.

So hold on to the load-bearing sentence the report actually printed. A TMS can enable better transportation management, but it does not automatically create transportation excellence. I would put it harder. A TMS is a measurement layer and an assignment layer. It has no arms. Where the arms are missing, it just records the failure faster and in a better font. Everything below comes out of that one distinction.

The factual claim in the report is narrow, and I want to keep it narrow. The boundaries between TMS, managed transportation, freight brokerage, digital freight platforms, control towers and 3PL services are getting less clean. A buyer may walk in asking for software and actually need a better transportation operating model. The package being assembled is technology, execution capacity, market access, analytics, workflow automation and outcome ownership. Those are the report's own words. I am not going to add to them, and I am not going to name vendors, because naming vendors is how a column turns into an advertisement.

Translate that into a system diagram. Historically each of those six categories owned one box in the flow. The TMS vendor owned planning, execution and settlement. The broker owned capacity sourcing. The managed transportation provider operated freight on the shipper's behalf. The 3PL provided logistics services. The visibility provider tracked shipments. The control tower monitored network performance. Six boxes, six contracts, and between every pair of boxes an interface that somebody maintained by hand, by email, by spreadsheet, or by memory. Every one of those interfaces is a place where the queue grows.

Convergence is not a marketing event. It is an interface-removal event. When a broker ships a shipper-facing platform that behaves like a light TMS, one interface goes away. When a TMS vendor adds embedded procurement and capacity access, another goes away. When a managed transportation provider bundles software, people, analytics and carrier management into one contract, three or four go away at once. Fewer interfaces means shorter queues, and shorter queues are worth real money. That is the part of this I want you to act on, and it has nothing to do with which category a provider files itself under.

Think of it as a queue, because that is what it is. Work arrives at some rate. People or systems serve it at some rate. As the arrival rate approaches the service rate, waiting time does not rise in a straight line, it curves. Run a queue at 50 percent utilisation and it feels calm. At 80 percent you can still manage. Past 90 percent, waiting time stops being proportional to anything you recognise. You do not have to take the mathematics on faith. Take two points: at 80 percent utilisation, average waiting runs at roughly four times the service time; at 95 percent it runs at roughly nineteen times. Same team, same process, same people. The only thing that changed is how close to capacity you are running.

Apply that to a transportation desk. Your team is the server. Exceptions are the arrivals. Assume, and these are my assumptions rather than facts from the report, that you move 400 loads a month and 18 percent of them generate at least one exception requiring a human. That is 72 exceptions a month, about 3.3 a working day, and if each one costs 22 minutes of real work including the calls and the follow-up, that is 26.4 hours a month, or 6.6 hours a week.

On a 40-hour week that is 16.5 percent utilisation. It looks fine. Now assume the exception rate moves from 18 percent to 26 percent because a carrier mix changed and one lane got tight. That is 104 exceptions, 38.1 hours a month, 9.5 hours a week, 23.8 percent utilisation. Still fine on paper. But exceptions do not arrive evenly. They arrive in bursts, on Mondays, at month end, after a storm, when a terminal closes. In burst conditions you are not running at 24 percent, you are above 90 percent for three hours at a time, and the waiting time inside those three hours is where your service level dies. This is why having capacity and hitting your service commitment are two entirely different statements, and why nobody should be allowed to say the first one in a review meeting as if it answered the second.

Where is the bottleneck here? Everyone assumes it is the planning engine, because the planning engine is what gets demonstrated. It almost never is. A modern system will build a load plan in seconds. The bottleneck is the loop between the moment the system notices something and the moment a human with authority does something about it. That loop has four stalls. Detection: does anybody see the exception at all, or does it surface only when the customer calls. Triage: of the forty things flagged today, which four matter. Authority: can the person looking at it actually rebook, or do they have to escalate. Closure: does the fix get written back so the same exception does not fire again next week. Work those four stalls and you will get more out of an average system than out of an excellent one with all four left wide open.

Quantify first, then optimize. I say it in every column and I will keep saying it. Before you sit through another demonstration, measure four things for four weeks. Exception rate, as exceptions per hundred loads, split by lane and by carrier. Detection lag, the hours between the physical event and the flag in the system. Recovery-cycle time, the hours from flag to confirmed fix. Manual touch rate, the share of loads needing a human to do something the system could have done. Those four are your baseline. Without them every claim you hear is unfalsifiable, and you will end up buying on the strength of a demo, which is the worst reason to buy anything.

If you want thresholds to argue with, here are mine. Exception rate: under 8 per 100 loads is healthy, 8 to 15 is manageable, above 15 means your carrier mix or your master data is broken rather than your software. Detection lag: under 30 minutes for anything touching a customer promise, under 4 hours for internal-only events. Recovery-cycle time: under 2 hours for a same-day load, under 8 hours for everything else. Tender acceptance: above 90 percent on contracted lanes is normal, below 80 percent means your routing guide is fiction and no amount of automation will rescue it. Manual touch rate: above 20 percent and your master data is the real project. ETA accuracy: measure predicted arrival against actual gate-in and hold it to a mean absolute error under 12 hours on domestic legs and under 36 hours on ocean legs. Worse than that and every downstream inventory decision is running on noise.

Now the arithmetic, with every assumption on the table. Assume 400 loads a month, an 18 percent exception rate, so 72 exceptions. Assume 22 minutes of human work each, so 26.4 hours a month. Assume a loaded labour cost of 60 dollars an hour, so 1,584 dollars a month of direct handling. Now assume that in 12 of those 72 cases the exception is detected late and the recovery costs you an expedite, a premium spot cover or a missed appointment, at an assumed 420 dollars each. That is 5,040 dollars. Total 6,624 dollars a month, about 79,500 dollars a year, on exception handling alone.

Take the other side. Assume the kind of bundled model the report describes brings your exception rate from 18 percent down to 12 percent, not through magic but because somebody else owns carrier onboarding, routing guide maintenance and the after-hours exception desk. Twelve percent of 400 is 48 exceptions, 17.6 hours a month, 1,056 dollars of handling. Assume the late-detection cases fall from 12 to 5, so 2,100 dollars. Total 3,156 dollars a month, about 37,900 dollars a year. The gap is roughly 41,600 dollars a year, or 3,468 dollars a month. Whether that gap is larger or smaller than the fee for the bundled model is the only question that actually matters, and it is a question you can answer in an afternoon using your own numbers. Mine are scaffolding. Replace them.

That is the whole buying test, and it is why feature checklists leave me cold. A feature moves one task. An operating model moves a rate. Rates compound and features do not. If a provider cannot tell you which rate of yours they intend to move and by how much, you are not buying an operating model, you are buying a licence.

The report's explanation of why brokers and TMS vendors are walking toward each other is the most useful paragraph in it, and it is worth restating in system terms. Brokers historically earned their margin by sourcing capacity and managing the transaction. As digital freight models mature, they need interfaces that let a shipper quote, tender, track and analyse without picking up the phone, because the phone does not scale. Meanwhile the TMS vendors have worked out that execution decisions depend on capacity availability and market pricing, and that a system which can recommend a carrier but cannot help solve the underlying capacity problem is limited exactly where it hurts most. Neither side is trying to become the other. Both are trying to remove the interface between recommending and covering. If you are a shipper, that is good news, because the gap between recommendation and coverage is where a great deal of your expediting cost is generated.

The report also lists what buyers are actually short of, and I would compress its list into three system problems. Shippers lack transportation staff. They run fragmented regional operations. They struggle with carrier performance. They lack freight procurement analytics. They lack the data quality a sophisticated system needs. They need processes redesigned rather than merely digitised. Collapse those and you get capacity, data and process. Every one of them shows up in your four baseline metrics. Staff shortage shows up as detection lag. Fragmented regions show up as manual touch rate. Weak carrier performance shows up as exception rate. Poor data quality shows up everywhere at once, and it is the one that quietly invalidates the other three. If your master data is wrong, your exception rate is not measuring your operation, it is measuring your data entry.

The report says there is no single right answer, and I agree, but I want to make that operational rather than diplomatic. There is no single right answer at the market level. At the level of your own four numbers there is usually exactly one right answer, and you can compute it. If your exception rate is high and your detection lag is long, an operating model is the answer. If both are low and your manual touch rate is high, automation inside your existing system is the answer. If your tender acceptance is below 80 percent, none of the above is the answer, because your routing guide is not being followed and you should fix that before spending anything. Run the numbers first and the category debate becomes boring, which is the best outcome available.

The control tower is where this gets genuinely confusing, and the report is honest about it. Companies want one integrated view of transportation performance, exceptions, inventory impact, customer risk and network disruption. That requirement does not fit inside any legacy category, so it gets delivered by a software vendor, a 3PL, a managed transportation provider, or an internal team stitching four tools together. My rule on this is unglamorous. Pick one system as the source of truth for where a load is, and make everything else read from it. Two systems disagreeing about the same container is not redundancy, it is an argument your operations team has to settle every morning, and they will settle it by trusting whichever screen they looked at last.

Here is what I would actually do, starting the week this report came out. The week of 29 June, have your transportation lead start a four-week exception log. One row per exception, five columns: lane, carrier, event type, time detected, time closed. Do not automate it and do not buy anything yet, just get the log. By 10 July you will have two weeks of data, by 24 July four weeks. From it, compute your four baseline numbers. Then apply one gate. If your exception rate is above 15 per 100 loads, or your detection lag is above 4 hours on customer-facing events, you do not have a software problem and you should not be running a software selection.

You have an operating problem, and you should be shopping for an operating model. If your numbers sit below those lines, software alone is a legitimate answer and a normal selection is fine. Hold it to one condition: the demonstration runs on your lanes with your historical loads, and you score it on tender acceptance achieved rather than screens shown.

The hardest part of the bundled model is not the technology, it is the measurement clause. If you are buying outcome ownership, you have to define the outcome in a way both sides can compute from the same data on the same day, and you have to do it before signing. Four things go on the page: which events count as exceptions, whose clock starts them, what counts as a recovery, and who owns the write-back. I have watched more of these deals sour on that clause than on anything technical. A provider who cannot explain how they compute their own service level does not have a service level, they have a story, and you will be the one paying for the difference.

There are three real alternatives and one false one. The false one is waiting for the categories to settle back down. They will not, and waiting costs you a year of measured improvement you could have banked. The first real alternative is best-of-breed software you operate yourself, and the report says plainly that this is right when you already have the transportation staff, the procurement discipline and the process maturity to use it well. It stops being right the moment your exception rate climbs past what your team can absorb in bursts. The second is managed transportation with strong technology, which is right when the queue itself is the problem and you do not want to hire for it. The third is embedded brokerage and procurement, which is right when capacity access rather than process is your binding constraint. Choose on which variable is actually binding, not on which brochure reached you first.

The pitfalls are worth naming because they are all cheap to avoid and expensive to discover. Buying software when the real problem is operating capability, which the report names as one of the two wrong answers, and which I see more often than any other mistake. Outsourcing execution when what you actually need is better internal process control, which is the second wrong answer and is underrated. Signing an outcome-based deal in which the outcome is undefined. Onboarding carriers faster than you can clean the master data, because a routing guide built on stale capacity data fails in a way that looks exactly like a software failure. And assuming the algorithm will carry you. It will not. It will tell you where the queue is. People, process and capacity clear it.

None of this makes the model the hero, and I want to be blunt about that because the last thing this market needs is another season of believing the software will do the work. The reason the 23 June report matters to me is not that it predicts a new category. It is that it quietly admits what anyone who has run a transportation desk already knows: the software was never the hard part. Getting the exception queue down, week after week and quarter after quarter, with a number attached to it that you can argue about, that is the hard part. Start measuring on Monday.

↑ Back to the key points

— By Ravi Chandran