“I canceled my own product demo because the route workflow underneath was not optimal.”
At 6:30 in the morning, I called the executive vice president of a fleet and canceled the demo we had scheduled for later that day. It was the second time in two weeks I had called it off. On their side, three dispatchers and five drivers were already lined up to run the test.
We were discussing our fuel optimizer. It tells a driver when to buy, where to buy, and how many gallons to take on his specific route. What was not ready was the route underneath it, and fuel optimization follows the route. Those five drivers are opinion leaders in that fleet. Hand them a route that doesn’t match what they know about those lanes, and they will decide the whole solution cannot be trusted, and no amount of accurate fuel math afterward will help rebuild trust.
AI adoption in transportation goes wrong one step earlier than most people look. We are collectively promising more than this industry can implement. The model is rarely what decides whether a project works. What determines it is the quality of the underlying data, how the data is structured in a single environment, the optimal workflow processes the software runs on, the people who have to work differently once it is live, and whether the technology was built for freight in the first place. Those are the fundamentals, and a company that skips them buys an expensive version of the problem it already had. Knowing when to apply AI, and when the honest answer is plain automation or a better process, is the actual skill, and it is in short supply. Consequently, a company is much better off if its TMS and Services vendor, like EKA, has both deep experience in key workflows and deep operational intimacy with the customer’s business, and understands where AI can be most helpful in solving key customer pain points.
So I told that executive vice president I did not want to spend his time or his operations chief’s time on something that would not work as we all want it to and cost us both credibility. He appreciated the honesty. We will demo the Fuel Optimizer with optimal underlying route workflows in a few weeks when it is fully “locked and loaded” for success.
Eight Clicks Down to Two Clicks
What I told my own team about the optimized route workflow enhancements had nothing to do with artificial intelligence. I wanted the workflow to go from eight clicks to two, underpinned by a high-quality and robust route. Do it in two clicks to generate a robust route, and you have a winner.
A great deal of the value sitting in front of transportation companies right now is ordinary automation, clean data, and fewer screens. Some of it needs AI. A good deal of it never did. You cannot tell the difference from a demo, which is exactly why demos sell so much software that never gets used.
Every vendor in this market is using the same large language models. We use them too. We test them against real freight data and build proprietary workflows that are optimally deployed in a single environment. The model is not generally the differentiator, and anybody telling you their model is the differentiator is likely selling you the least durable part of the stack.
AI Does Not Rescue Bad Data
Layering AI on top of poor data fidelity, broken or sub-optimal workflows, missing variables, and technology that was never purpose-built for freight produces a more expensive version of the same mess. The fundamentals have to be in place first, and then AI has a solid foundation to work from.
Take estimated time of arrival, which almost every company in this industry says it wants and almost none of them trust. The reason ETA underperforms at small, medium, and large companies alike is rarely the algorithm. The underlying practice is wrong. The data going in is wrong. The variables that decide the answer are missing, starting with dwell time at pickup.
I had a version of this conversation with a fleet recently about data capture. I asked the vice president how much of their operating data gets captured automatically rather than typed in by a person. Telematics, sensors, anything that removes a human from the data entry step. Without that foundation, you cannot implement AI effectively, whether you are doing exception handling, analysis, decision support, or anything more autonomous than that.
Exceptions First, Autonomy Last
There is a sequence to adopting this technology, and companies that skip steps do not arrive faster.
The sequence starts with exceptions. An exception is the source, the thing that tells you where to look, and you do not need AI to generate one. Operations has been finding exceptions for as long as there has been freight. The question worth asking is what happens next. How fast does your team get from an exception to a decision?
A control center exists to exactly fill that gap. It puts the problem in front of a person without sending them across three screens and two databases to assemble the story. It tells them what the problem is, provides the analysis behind it, identifies the root cause and what needs fixing, and then supports the decision. That is a semi-autonomous model, and it is tier one. We built the same pattern into load and asset optimization and into the fuel work, and we wrote about running an operation that way earlier this year.
People talk about fully autonomous agents, what the industry has started calling agentic AI, as though the hard part is building it for key freight workflows. The hard part is earning the right to turn it on. The amount of trust a company has to build before it will let a system act without a person in the loop is enormous, and a company builds that trust in stages: exceptions, then analysis that identifies the root problem, then decision support, then autonomy, where the operation can carry it out. A company that gets the first three stages working has already claimed most of the available benefit.
Implementation Reaches All the Way to the Driver
For a trucking company, implementation does not stop at the head office or the regional operation. It ends at the driver, because that is where much of the data, health, and automation enhancements actually happen.
Route optimization and fuel optimization do not deliver unless you are willing to put compliance behind them. That means looking, in real time or at least monthly, at whether the driver followed the plan. If a company is not willing to do that, my advice is to leave the money in the bank and skip the project, because it will not go anywhere. The same holds for the hardware. Automation at the driver level falls apart when drivers switch the GPS on and off as they see fit, and no one follows up.
None of that is an argument against drivers. It is an argument for treating them as part of the implementation rather than as recipients of it, which is why the five opinion leaders on that canceled demo mattered more to me than the software did.
The Hard Conversations About the 10%
Some of this work involves telling a customer something they do not want to hear.
A company will tell me they need a step where somebody approves the delivery. I ask why they want to approve a delivery that has already happened, when we captured it automatically, and why the driver has to key it in at all. The answer comes back that sometimes a truck arrives early, gets in and gets out, and the record needs a human eye. We can put logic in place for that. Then we get to the real number: it happens perhaps 10% of the time. So the process is built around the 10%, and it taxes the 90%.
Those are the conversations you have to be willing to have, and you can only have them if you know the business well enough to ask the second and third questions rather than accepting the first answer.
What We Do Before a Product Reaches the Market
Our engineering group tests what it builds against the specification and use-case scenarios, but that is not the gate that decides whether something goes out.
Before an AI product goes to market, including load auto processing, I sit down with my key salespeople and our sales implementation coordinator to review it from a business perspective. Not only what got built, but what still has to be finished to make the thing easy for a customer to adopt. If the implementation step is missing, we do not release it. I have held products back for exactly that reason.
The best technology in this industry does not survive a bad implementation. You have to know the people and where the traps are.
Some Companies Will Never Take AI
I will say the part most vendors leave out. Some companies are not going to adopt this, and their reasons are usually structural rather than stubborn.
The pattern I see is a company working bottom-up, neutralizing an implementation exception one at a time. They will accept a control for one part of the operation and refuse it for another. Each exception looks small and reasonable on its own, and together they cancel the project. Multifactor authentication goes the same way, which is why we wrote about it separately.
If that is your company today, what changes it is a decision about how you want to operate, and that decision belongs to the person running the business.
The Bottom Line
A TMS is a system of record that people operate. AI infrastructure is an operational layer that runs the business and calls a person when it needs one. Those are different products with different requirements, and a platform built for the first cannot become the second by moving to the cloud.
I moved this company toward AI infrastructure because it allowed EKA Omni-TMS, take full advantage a data and other infostructure foundation that was already organically AI infrastructure ready. This gave EKA an AI native launch pad to take-off from what we had built and to move faster than any other TMS companies that have to build this AI foundational infrastructure that a customer can trust before they can start to implement AI solutions.
When a customer tells me they just want a TMS, my answer is that they are getting one with AI infrastructure underneath it that runs operations, handles exceptions, and takes them further, faster, and more cheaply as they are ready for it. The order of those words matters. AI is what makes the employee work smaller, faster, and more empowering.
And it’s the work we are removing here, not the people. Eliminating work is the point. The screen pushers go away, and the people who solve problems and make decisions are the ones who will still be here, more empowered.
If you are evaluating AI in transportation right now, ask the vendor which parts of their answer require AI and which parts are plain automation they could have delivered 10 years ago. Ask what has to be true about your data before any of it works. Ask what they would refuse to install in your operation, and why. Ask who at your company has to change how they work, and whether that person is in the room. A vendor who has never canceled a demo has probably never earned one.
Talk to EKA about where your operation actually sits in that sequence.