The gap between the demo and the dock
Every freight conference now has a stage full of AI pitches, and most of them look good for the same reason: a demo runs on a clean lane, a cooperative carrier, and a rate that doesn't have to survive a spot-market swing an hour later. None of that is dishonest, exactly. It's just not your operation. Your operation has exception loads, carriers who don't answer the first call, customers who change a delivery window after the truck is already rolling, and a rate history that lives across three systems and one dispatcher's memory.
The distance between what gets demoed at a conference and what a system can actually hold up under in a working brokerage is wider in freight than in almost any other industry we work with. Part of that is structural — margins are too thin to absorb a system that gets a quote or a carrier assignment wrong at scale, so the tolerance for a confident-sounding mistake is close to zero. Part of it is that freight moves through relationships and market judgment that a vendor's training data never fully captures. A strategy engagement exists to find that gap before you're the one who discovers it live, on a load that already picked up.
What the engagement produces
The output isn't a slide deck of AI trends. It's three things you can act on immediately. First, a ranked list of where your team's hours and your margin are actually leaking, scored against how much judgment the work requires and how forgiving it is if a system gets it wrong early on. Second, a plain call on each candidate: build it custom, let your transportation management system handle it once a feature you're already paying for catches up, or leave it as manual work because the volume doesn't justify automating it yet. Third, a sequence — what gets built first, second, and third — chosen to teach your team the most about running AI in production while the stakes are still low.
None of that is a sales pitch dressed up as strategy. Some engagements end with a recommendation to fix your data before anyone writes a line of code, or to wait a year until your volume on a given lane justifies the build cost. That's a legitimate outcome, and it's cheaper to hear in a working session than after a build budget is spent. This sits alongside the broader AI strategy work we run for operators outside freight, adapted here to a business where the cost of a confident wrong answer is unusually high.
Where the flashy pitches get genuinely hard
Two ideas dominate the AI-for-freight pitch deck: automated pricing that quotes a lane without a human touching it, and autonomous carrier selection that books capacity on its own. Both are worth wanting, and both are genuinely harder than the demo makes them look — not because the technology is fake, but because the inputs a model would need are only partly in your data.
A rate isn't just a lane and an equipment type. It's what the spot market did this morning, what a specific carrier's capacity looks like this week, and what a broker who's worked that lane for years knows about a shipper's real flexibility on the pickup window. Most of that lives in judgment and relationships, not in the TMS. Carrier selection has the same problem from a different angle — a good dispatcher isn't just matching a truck to a lane, they're weighing a carrier's reliability history, whether that carrier will actually answer the phone during an exception, and relationship considerations that never got written down anywhere a model could learn them. A system built on incomplete inputs doesn't fail loudly. It fails by quoting confidently at the wrong number or booking a carrier that's technically available and practically wrong, and neither mistake shows up until the load is already a problem.
None of this means automated pricing or carrier-sourcing assistance is off the table — plenty of what we build does exactly this, inside limits a person sets. It means the honest version of that build keeps a person in the loop on anything the data can't fully support, and the strategy engagement is where that line gets drawn before it gets discovered the expensive way.
Where the reliable returns actually sit
The less exciting half of the pitch deck is where freight AI earns its cost most reliably, and it's worth naming plainly: quote turnaround on standard lanes, check calls and status updates, document handling, and exception detection. None of it makes for a great conference demo. All of it is high-volume, repetitive, and — critically — measurable, because you already know roughly how long it takes today and roughly what a missed one costs.
An RFQ that sits in an inbox for two hours on a lane you price routinely isn't a judgment problem, it's a throughput problem, and throughput is what these systems are actually good at. A check call on a load that's tracking fine doesn't need a dispatcher's market instincts, it needs someone — or something — to make the call, log the answer, and flag the one load that isn't tracking fine. A bill of lading that has to be matched to the right load number and checked for a mismatched weight is exactly the kind of task a system does consistently and a tired coordinator does inconsistently at 4pm. This is the unglamorous end of the roadmap, and it's usually where the first build goes, precisely because the returns are countable rather than promised.
Walkthrough: sizing where the hours and the margin actually leak
A regional brokerage came to us convinced their biggest problem was quote speed. The sizing session started differently — timing, lane by lane, how long a quote actually took from RFQ to reply, and where the time went. Quoting turned out to be fine on the brokerage's top twenty lanes, where pricing was close to automatic already. The real leak was in exception handling: a coordinator spending close to a third of the day chasing carriers who'd gone quiet mid-load, with no consistent way to tell an actual problem from a driver who just hadn't checked in yet.
That's not the project the brokerage walked in wanting to build, and it's the one the sizing work actually supported — a system to run routine check calls and flag the loads that needed a human, rather than a pricing engine for lanes that weren't costing them anything. Sizing the hours honestly, before scoping anything, is what kept the budget pointed at the real leak instead of the assumed one.
Walkthrough: the vendor pitch and the question that reshaped it
A 3PL had shortlisted a vendor promising autonomous carrier sourcing — a system that would work its carrier list and book coverage without a person in the loop. The demo was clean: a lane, a handful of carrier responses, a booking confirmed in minutes. Before signing anything, the strategy session asked the vendor a narrower question: what happens when two carriers respond with a similar rate and one of them has a service history the 3PL's dispatchers know about but never logged anywhere a system could read.
The honest answer was that the system would book on rate and response time, because that's what the data available to it could support. That answer didn't kill the project — it rescoped it. What got built instead surfaces ranked carrier options with the booking decision ready to confirm, rather than confirming it on its own, and the 3PL's dispatchers keep the final call on any lane where relationship history matters more than the rate on the screen. That's the question worth asking any vendor pitching autonomy in this space: not whether the demo works, but what the system does with the judgment it can't see.
Walkthrough: the rate history that lived in someone's inbox
Every data-readiness conversation with a freight brokerage runs into the same wall eventually: a meaningful share of the operation's actual pricing and carrier history doesn't live in the TMS at all. It lives in a coordinator's sent-mail folder, in a spreadsheet someone built three years ago and never shared, in a senior broker's memory of which carriers to avoid on a specific lane. That's not a data-hygiene footnote — for a brokerage, it's often the real constraint on what can be built at all.
One engagement found that roughly half of a target lane's pricing history existed only as email threads between a broker and a handful of regular shippers, never entered into the system of record. Before any pricing assistance could be scoped honestly, that history had to be identified, exported, and structured — not perfected, just made usable. The roadmap that came out of the session put a short data-consolidation step ahead of the pricing build itself, because a system trained on the quarter of the history that happened to be in the TMS would have learned a distorted picture of how that lane actually prices.
What your TMS already does, or will soon
Before we scope anything custom, we check what your transportation management system already does, or has announced it will do soon. Most platforms are shipping more AI-flavored features every year — status summaries, basic rate suggestions, document capture. Building a custom version of a feature you're already paying for, or about to receive in an update, is the fastest way to waste a build budget in this industry.
What's left after that filter is usually narrower and more specific to your operation than the vendor roadmap covers: the exception logic tuned to your actual customers, the carrier-sourcing workflow that reflects relationships your TMS has no way to represent, the document handling that spans systems your TMS was never built to touch. That's the list worth building custom. The rest is worth waiting for.
Sequencing: the unglamorous project goes first
Ranked opportunities don't get built in order of ambition. The first project should be small enough to see running in weeks, low-stakes enough that a mistake is cheap and visible instead of buried in a customer complaint, and close enough to daily work that a coordinator notices it helping. That's almost never the pricing engine or the autonomous booking system. It's usually check calls, document matching, or routing routine RFQs — the reliable-return work described above.
That first build also tells you things the planning session can't: whether your data is as usable as everyone assumed, whether coordinators actually trust the output enough to rely on it, whether the exception-handling logic holds up against a real bad week and not just a clean pilot month. Everything after it gets sequenced with that evidence in hand, which is also why the more ambitious idea that started the conversation usually belongs later on the list, not first.
What to ask a vendor to separate a demo from a system
A short list of questions does more to separate a real system from a good demo than any spec sheet a vendor hands you:
- What happens when two options are close and the deciding factor is relationship or service history that isn't logged anywhere structured?
- Has this been tested against a bad week — carriers going quiet, a customer changing terms mid-load — or only against clean, cooperative data?
- What does the system do when it isn't confident, and does a person see that moment or does the system guess anyway?
- What data does it actually need from us on day one, and what happens to accuracy if that data is incomplete?
- Who is accountable, and how, when it gets a quote or a carrier assignment wrong?
A vendor who answers these plainly, including with an honest "we don't handle that case," is worth taking seriously. One who insists the system handles everything the demo showed, every time, in every condition, is a pitch that hasn't met a real operation yet.
What this becomes: the build that follows the strategy
For most brokerages and 3PLs we work with, the roadmap leads directly into a build. The unglamorous, reliable-return work — check calls, document handling, exception flagging — usually becomes a custom AI agent scoped narrowly around the judgment it's actually allowed to make. Work that follows a fixed set of steps without much judgment involved, like routing a document to the right load file or notifying a customer at a status milestone, is often better served by simpler workflow automation than by a decision-making agent at all — and separating those two is part of what the strategy session is for.
Whatever gets built inherits the sizing, the build-vs-buy calls, the data-readiness fixes, and the sequencing the strategy session already established, with clear pricing agreed before any of it starts. Some operations take that roadmap and build it with their own team. The strategy work holds up either way, and the wider view of how AI fits a freight operation day to day is on our logistics industry page, for anyone weighing this against other priorities on the operations side.