A dashboard can show the symptom. It rarely shows who owns the exception, what happened last time, or whether the route-guide correction reached the TMS.
Disclosure: I’m helping Steadi with market outreach. The analysis and opinions here are my own.
The report is not the resolution
Most transportation teams can already tell you which lanes are off plan. The reporting layer in a large shipper is usually good. Tender acceptance, cost per mile, variance to budget, all of it sits in a dashboard somebody built and somebody maintains.
Then the number turns red, and the useful part of the reporting ends.
What the dashboard does not hold is the work after the exception appears. You can usually drill into the metric. What you will rarely find in the same place is the exception coded at the load or lane level, the person working it, the detective work behind it, how that lane compares to the market, and whether the route guide was actually corrected. In many operations that evidence is spread across the TMS, a reporting tool, a few spreadsheets, email and someone’s head.
Detection is the easy part. Resolution is not. More precisely, resolution with context is not. The signal arrives without the ownership, the history or the record that would turn it into a decision. The gap between the two is where the money goes, and it is not a reporting problem. It is a workflow problem.
Where the route guide process actually breaks
The investigation that follows can end with a commercial decision: change the carrier, adjust the rate or revise the tender sequence. But that decision is only one stage in the same operating workflow. The work is not finished until the approved correction is live in the TMS.
Here is the part that is hard to see from outside the job.
A carrier hands back a lane. Your team investigates the cause, works the problem and agrees on a new rate. The commercial decision is made. But the corrected rate is not live yet, because in too many transportation operations, route-guide changes still move through flat files and system queues before they reach the TMS.
While the change sits in that queue, the lane keeps tendering under the old assumptions. It keeps getting rejected. It falls to higher-cost backup carriers or the spot market.
This is worth separating clearly from a bad decision. Nobody was asleep. The negotiation happened, the right answer was reached, and the cost was incurred anyway because the correction could not travel as fast as the freight.
Why the delay creates repeated cost exposure
A single unresolved exception is an annoyance. It becomes a budget problem when the same lane fails the same way more than once before anyone connects the events.
By the time the variance surfaces in a weekly or monthly review, the team is looking backwards at freight that already moved. They investigate, and the investigation itself is expensive: pulling loads, reconstructing what happened, chasing down who approved what. Often the honest conclusion is that nobody can fully reconstruct it, because the reasoning lived in a phone call and an email thread.
Then the lane comes up for renegotiation, or an auditor asks who changed a rate and why, and the same reconstruction happens again from scratch.
The question is why freight went to spot
Spot freight is inevitable, and sometimes it is the right commercial decision. Volume can run beyond committed capacity. Lead times can collapse. Weather, a major event or a temporary disruption can change the network faster than a contract can.
The operating question is not simply whether spot happened. It is why it happened and what should happen next. Is this a one-off or a trend? Is the cause volume, lead time, carrier performance or market conditions? Are you buying appropriately against the market in real time? What is the exception doing to budget? Will the market normalize, or does the route guide need intervention?
Without that context, spot is only a symptom in a report. With it, the team can distinguish intentional sourcing from a process failure and decide whether to clear the exception, monitor it or act.
The closed operating loop
What the operation actually needs between detection and correction is fairly specific. Market, cost and trend context, so the team can tell a one-off from a pattern and judge whether the market may self-correct. A named owner, so there is a real answer to who is working on it. A documented reason, so the decision survives the person who made it. An approval record. And confirmation that the corrected route guide reached the system that executes it.
What a dashboard does
A lane turns redClosed Loop for Route Guide Compliance
- Exception detected at the load or lane level
- Market, cost and trend context attached
- Task routed to a named owner
- Human approves the decision and the reason is captured
- Approved route-guide change written into the TMS in real time
The difference is not a better alert. It is that the exception stays actionable long enough to be resolved, and the resolution is written down.
I have been spending time with Steadi because they are building for that middle layer specifically, rather than adding another view on top of data the team already has.
Scroll the panel sideways to follow a full row.
Where AI belongs in this workflow
This is the part I care about most, and it is where I think a lot of transportation software is about to go wrong.
The version of AI that gets pitched is an agent that resolves the exception for you. In transportation procurement, that is a bad fit. These are commercial decisions with carrier relationships attached, and the person holding the budget is accountable for them.
The version that earns its place is narrower and much more useful: it compresses the investigative and documentation work around the decision, so the person can spend attention on the decision itself. That can mean surfacing market context, ranking plausible reason codes with an explanation and preparing a record the operator can accept, edit or reject.
Documentation is the quiet win here. A reason code and a note attached to the change is not paperwork for its own sake. It is what lets the same lane, six months later, tell you what happened to it and who decided.
What does it cost from identification to correction?
The clock does not start when somebody opens the TMS. It starts when the exception becomes visible, and it stops when the approved correction is live.
Between those points sit the detective work to understand the cause, the judgment about whether the issue is a one-off or a trend, the approvals and handoffs, the system change itself, and any rework if an upload fails. That is the workflow time worth measuring.
I am not going to hand you a savings percentage. Anyone who quotes one before looking at your data is guessing. What you can do, using numbers you already have, is size the exposure that exists today.
Sizing your own exposure
- Time to correction
- investigation time + approval and handoff time + execution and rework time
- Freight exposure while open
- affected loads moved before correction × actual cost over plan per load
- Administrative cost
- investigation, approval, update and audit hours × fully loaded hourly cost
- Total addressable exposure
- freight exposure while open + administrative cost + unrecoverable adjustments
Run it on a handful of lanes that actually broke this year, not on your whole network. You will get a real number quickly, and it will be your number.
Then apply the honest test. Any tool, including this one, should be measured against the portion of that exposure its workflow can actually remove. Not the whole figure. Faster correction does not recover freight that already moved, and no software removes the underlying market. If a vendor cannot tell you which part of your exposure they address and which part they do not, that is the answer.
Some operations will run this and find the number is small. That is a genuinely useful result, and it should end the conversation.