Every ops planner who has worked with an automated routing system has a version of the same story. The system produces a route that looks perfectly reasonable on a screen, and it sends a truck straight into a road that's been closed for construction since Tuesday, or down a street a 32-foot trailer physically cannot turn into, or to a dock that everyone on the ground already knows stops accepting deliveries after 2 PM on Fridays. The algorithm wasn't stupid. It simply didn't know something a person standing in that market already knew.
This is a legitimate objection to automated planning, not a resistance-to-change complaint that should be argued away. In a recent survey of more than 500 supply chain leaders, just 10% said they would trust AI to make fully independent decisions, while a majority wanted AI to recommend and a human to decide. The right response to it isn't to insist the AI is right often enough that the exceptions don't matter. It's to design the system so a planner can override a specific decision, freeze it, and move on without that one override turning into a fight with the platform or a reason to quietly stop trusting the automation altogether.
Why does one bad recommendation cost more trust than it should
There's a well-documented asymmetry in how people respond to a mistake made by an algorithm versus a mistake made by a person, and it explains why this issue matters more than it might seem. Research on human-machine trust has found that after witnessing an algorithm make an error, people lose significantly more trust in it than they do after seeing a human make the exact same mistake, which is a pattern that has been replicated consistently enough to earn its own name in the literature: algorithm aversion. A human colleague who gives bad advice once is forgiven as fallible. A system that gives bad advice once is often written off as fundamentally unreliable, even if its overall track record is considerably better than the human alternative it replaced.
This has a direct operational consequence in freight planning. A planner who gets burned by one bad automated route, like a closed-road scenario or the impossible dock window, doesn't just note the exception and move on. They frequently start second-guessing every subsequent recommendation, manually re-checking routes the system was actually right about, which erodes the entire efficiency case for automating planning in the first place. The system doesn't need to be perfect to be worth using. But if the platform makes it hard to correct the moments it isn't perfect, every one of those moments does disproportionate damage to whether the tool gets used with confidence going forward.
Two ways to get the human-AI balance wrong
Management research on this exact tension identifies two opposite failure modes that teams consistently fall into: accepting AI recommendations uncritically, known as automation bias, or rejecting them prematurely and too broadly, known as algorithm aversion, both of which degrade decision quality, and both of which stem from a lack of practical guidance on when to actually rely on the system versus when to step in.
A TMS that only supports full automation with no override path pushes planners toward the first failure mode, forcing them to either accept a route they know is wrong or work around the platform entirely with a side channel of manual instructions the system never sees or learns from. A TMS that makes override so cumbersome that planners route around the automation entirely by falling back to manual planning out of frustration and pushes toward the second, discarding genuinely good recommendations along with the bad ones. Neither failure is really about the quality of the underlying algorithm. Both are about whether the system was designed with a real mechanism for a human to intervene on a single decision, without that intervention requiring a fight with the platform or a wholesale rejection of it.
The difference between "override and fight" and "override and freeze"
An even more subtle differentiation within this set of characteristics is critical: will the system recognize that only one route has been corrected for one special reason and permit the planner to freeze that special route while permitting automated reoptimization of all other routes and shipment events on the same planner screen?
By enabling “override and freeze," the planner can specify a constraint for a single route (e.g. the road to a distribution center is closed) and apply that constraint for that one route only. The rest of the network continues to run under automated planning. In this way the planner only has to work around a single exception, not a whole host of others. Just as you would expect to work with another human planner on the exceptions to normal planning, the planner needs to be able to work with the AI exceptions too.
In the worst case the override only fixes today’s problem for tomorrow to cause exactly the same complaints as before. By storing the override as data (the closed road, the dock’s real closing time, and the special treatment of an exceptional customer by means of an unusual vehicle), it can be used to improve the automated planning in the long run. The human planner’s corrections can be used to improve the AI in the long run.
Why the override itself should feed back into the model
The best version of this design is one where the correction gets logged as data (the closed road, the real dock cutoff time, and the special customer handling requirement) and is then used in subsequent planning. This means that the correction that the planner put in to fix one instance of a problem gets to be used to fix subsequent instances of the same problem, rather than the planner having to reapply the correction every single time. In other words, the single correction that the planner applied in order to fix something on one occasion gets to be used to fix that same thing on future occasions, rather than the planner having to reapply the correction each time.
This is how Libera's Planning module was designed to work with the human planner, where AI does the work, with the human planner in the loop to override a specific route or vehicle choice for a specific trip. The planner can lock in the changed route or vehicle choice for that one specific trip, and the rest of the planning for the rest of the network can continue to be automatically re-planned as required. This is how the same capacity and route planning engine that automatically re-plans for new arrivals, etc., at every cutoff time respects the human planner’s manual adjustments to a specific shipment and does not undo them on the subsequent automatic re-planning of the same plan.
What to actually ask when evaluating this in a TMS
That leaves the critical test of the TMS' use of AI for planning. Ask the question for each potential exception: Can that one be fixed, frozen, and left to run while the rest of the plan continues to get updated via the automated planning process? Or, in trying to correct that one exception, will the planner be engaged in a fruitless struggle with the system to correct that one occurrence; will they be forced to disable the AI for planning for a greater number of occurrences than necessary; or will that correction be silently reversed by the AI for planning when it re-runs the planning process for that same shipment again on a subsequent planning cycle?