The sales engineer at the dispatch AI company had a beautiful slide. It showed a comparable carrier, anonymized, that had reduced deadhead from 21 percent to 14 percent in 90 days. The fleet manager at a 75-truck refrigerated carrier looked at the slide, looked at the contract, and asked a question that stopped the room: "Can you show me that result on my Chicago-to-Memphis lane, with my actual drivers and my actual HOS constraints, over the next 30 days, before I sign?" The sales engineer said that was not how their onboarding process worked. The fleet manager said he understood, thanked them for their time, and showed them out. He had been through two previous AI pilots that produced great demo metrics and zero operational improvement. He had learned what a PoC (proof of concept) should be: a defined test on the fleet's actual freight, with success criteria agreed before the tool is deployed, measuring outcomes the fleet actually cares about. This lesson is that process, built for a fleet strategist who needs to know what the AI can do on their specific routes before a multi-year contract puts the decision behind them.

What a PoC Is and Is Not

A PoC (proof of concept) in fleet AI is a structured, time-bounded test on a defined subset of the fleet's real operations, designed to answer one specific question: does this tool produce a measurable improvement on our freight, with our constraints, in the time frame the vendor claims? This is different from a free trial, a vendor-provided demo, or a retrospective analysis that the vendor runs on your historical data after the fact.

A free trial is a trial period on the vendor's terms: you get access to the tool, the vendor counts activations, and the conversion to a contract is based on whether you like the product. A free trial does not define success criteria before the trial begins, does not specify what metric constitutes a pass, and does not require the vendor to put any skin in the game. Many carriers sign contracts after a free trial because they liked the interface, not because they measured an operational outcome.

A vendor-run retrospective analysis applies the vendor's algorithm to your historical load and driver data to simulate what would have happened if you had used the tool. The result is almost always impressive because the vendor controls the analysis and because retrospective optimization, where the algorithm knows the outcomes in advance, is inherently easier than real-time optimization. A carrier who signs a contract based on a vendor's retrospective analysis is signing based on a best-case simulation, not a live performance test.

A genuine PoC applies the tool to live freight, with live constraints, in real time, and measures the outcome against a baseline you agree on before the test begins. It is the only evaluation that answers the question: what does this tool actually do when the dispatcher's phone is ringing, the driver has 2.4 hours of HOS remaining, and the backhaul window closes at 6 PM?

Defining the PoC Scope

The most common PoC failure is scope that is too broad. A carrier who runs a PoC on "all dispatch operations" for "90 days" with "overall efficiency improvement" as the success criterion has not designed a PoC. They have designed a long free trial with a vague goal that both parties will interpret differently when the time is up.

A properly scoped PoC has four elements defined before the vendor's first API call reaches the TMS (transportation management system).

Element one: the specific lanes. Choose two to four high-volume lanes where deadhead is currently measurable and where the AI's proposed intervention (load matching, backhaul identification, or route optimization) is most likely to apply. Do not choose the carrier's hardest lanes for a PoC: if the first test is on a specialized lane with unusual equipment, seasonal freight, and a limited driver pool, a failure may reflect lane difficulty rather than tool capability. Choose lanes that are representative of the fleet's core business and that have enough volume to produce statistically meaningful results in the PoC window. For a 75-truck refrigerated carrier running the Chicago-to-Memphis corridor at 20 loads per week, a 30-day PoC on that corridor will produce enough events to evaluate the tool's backhaul suggestion quality.

Element two: the specific problem. What is the tool supposed to fix? Name one primary metric. For a dispatch AI PoC, the most defensible primary metric is deadhead percentage on the PoC lanes during the PoC window. For a predictive maintenance PoC, the most defensible primary metric is the number of fault-code-flagged trucks that are routed to maintenance within 48 hours without the shop manager manually queuing them. Do not set multiple primary metrics: when the PoC ends and the vendor says metric A improved while metric B declined, you need a primary metric to make the pass-or-fail decision unambiguous.

Element three: the success threshold. What numeric improvement constitutes a pass? The threshold must be agreed before the PoC begins, in writing, in the PoC agreement. A vendor who will only agree to a vague "material improvement" as the success criterion is not willing to be held to a specific standard. For a deadhead PoC on a corridor running at 18 percent deadhead, a reasonable threshold might be: deadhead on the PoC lanes falls below 15 percent during the PoC window, sustained for at least three of the four PoC weeks. This is specific, measurable, and agreed in advance, so there is no argument about interpretation when the data comes in.

Element four: the comparison baseline. What is the current performance on the PoC lanes, measured the same way the PoC will measure performance? Pull four weeks of pre-PoC dispatch data from the TMS on the same lanes and calculate the baseline metrics before the vendor's tool is turned on. This is the number the PoC must beat. Without a documented baseline, a vendor can argue that their tool produced a 15 percent deadhead rate when the pre-PoC rate was also 15 percent, and the "improvement" narrative has nothing to stand against it.

The Backhaul Test: Proving a Recovered Mile, Not a Slide

The most important PoC for a carrier seeking deadhead reduction is the backhaul test: can the tool find and match a paying load for the return leg of a driver's trip, on the actual lanes the driver runs, with the actual HOS (hours of service) constraints the driver has, and get a suggestion to the dispatcher before the load is gone? This test cuts through marketing because it requires the tool to perform in real time against a real constraint that a slide deck cannot simulate.

The backhaul test is designed as follows. Select the PoC lanes and identify all inbound legs where the driver will arrive at a point away from the domicile with remaining HOS. These are the backhaul candidates. Before the PoC, document how many of those return legs currently run empty (deadhead), and what the average deadhead miles are. During the PoC, the tool proposes backhaul matches for those return legs. The dispatcher evaluates and accepts or rejects each proposal. After the PoC, compare three numbers: the deadhead percentage before the PoC, the deadhead percentage during the PoC, and the percentage of accepted proposals that resulted in paid loads.

The third number is as important as the second. A tool that proposes twenty backhaul matches per week and the dispatcher accepts eighteen of them but only ten result in confirmed paid loads is a tool that is generating false positives at a 44 percent rate. False positives waste dispatcher time and teach dispatchers not to trust the tool. A tool that proposes ten backhaul matches per week and eight result in confirmed paid loads has a false positive rate of 20 percent and is likely worth using in production. The PoC should measure all three metrics, not just the deadhead percentage.

One real recovered backhaul is worth more than a hundred slides showing a projected improvement. A carrier who comes out of a PoC with documented evidence that the tool found and matched three paid backhauls on the Chicago-to-Memphis return lane that would have been empty miles has evidence that the tool works on their freight. That evidence is the basis for a contract. That evidence is also the basis for the first chapter of a ROI story the owner or board can read without a data science background: three empty legs converted to paying loads, at an average of 380 miles per leg, at a rate of $2.10 per mile, is $2,394 in recovered revenue per three-leg event. If the PoC window contained forty such events and the tool found paying matches for twelve of them, the monthly revenue recovery is $9,576, and the annual projection is $114,912. These are numbers a fleet manager can defend in an owner's meeting. They come from real freight, not from a vendor's marketing department.

The HOS Compliance Gate

Every PoC for a dispatch AI must include an HOS compliance gate: a check that the tool's proposals are legally runnable by the driver at the time of the proposal. This is not optional, and it is not a second-pass check the dispatcher performs after accepting a proposal. It is a first-pass filter that the tool must perform before it surfaces a backhaul match or a route suggestion.

The HOS compliance gate in a PoC is tested by deliberately creating test scenarios where a driver does not have enough hours to complete the proposed match. These scenarios arise naturally in any real PoC because HOS constraints are a daily reality on live freight. Document what the tool does in each case: does it refuse to propose the match? Does it propose it with an HOS warning? Does it propose it with no warning at all? A tool that proposes an impossible match with no warning is not safe for production use, regardless of how impressive its backhaul identification rate is. The PoC agreement should specify that any proposal for a route that exceeds the driver's current HOS is a PoC failure event, and that three failure events disqualify the tool from advancing to a production contract.

The HOS compliance gate also reveals whether the tool is reading live ELD (electronic logging device) data or a static estimate. If the tool consistently overproposes in the last two hours of a driver's shift, it is likely using an estimate of hours rather than the driver's actual current log. This is a data integration problem that the PoC will surface and that must be resolved before production deployment.

The PoC Agreement and Governance

A PoC agreement is not a contract for the full AI deployment. It is a short, precise document that creates mutual accountability for the PoC period. It should contain: the PoC lanes and volume, the PoC duration (typically 30 to 60 days for dispatch optimization, 60 to 90 days for predictive maintenance), the primary success metric and threshold, the comparison baseline, the data access provisions (what data the vendor receives during the PoC and what happens to it after the PoC ends), the HOS failure event definition, and the decision rule at the end: what specific outcome produces a recommendation to contract, what outcome produces a recommendation to decline, and what outcome produces a recommendation to extend the PoC.

The data access provisions in the PoC agreement are more important than they look. During a PoC, the vendor receives real-time access to the carrier's TMS load data, driver availability, and lane history. This is more granular data than a demo requires. The PoC agreement should specify that the data provided during the PoC is subject to the same ownership and training-use restrictions as the data provisions in the full contract. A vendor who says they cannot sign PoC data restrictions before the full contract is negotiated is signaling that they intend to retain or use the PoC data on their own terms if the contract is not signed. That is not an acceptable PoC arrangement.

The PoC should be run with a dedicated governance contact at the carrier, not delegated to the dispatcher who is also running live freight. This does not mean a full-time PoC manager; it means someone who reviews the PoC metrics weekly, communicates with the vendor about anomalies, documents override events and their reasons, and prepares the PoC conclusion report. For a fleet manager running a 30-day PoC, this is approximately two hours per week of structured attention on top of normal operations.

At the end of the PoC, the conclusion report should contain: the primary metric performance versus the threshold, the HOS failure event log, the backhaul acceptance and conversion rates, a qualitative assessment of dispatcher experience (did the tool help or add friction?), and a recommendation: proceed to contract, decline, or extend. The recommendation should come from the fleet manager, not from the vendor's account team, whose financial interest in a contract makes their assessment of the PoC outcome a conflict of interest.

When a PoC Fails

A PoC that does not meet its success threshold is not a failure of the fleet's AI program: it is the program working as designed. The alternative, signing a contract without a PoC, would have meant committing to a multi-year subscription for a tool that did not perform on the actual freight. A PoC failure is a cheap lesson. A contract signed without a PoC that underperforms is an expensive one.

When a PoC does not meet its threshold, the first question is whether the gap is caused by tool capability or by data quality. A tool that performs poorly because the carrier's TMS has incomplete freight data, missing shipper addresses, or inaccurate driver availability records is not necessarily a poor tool: it is a tool that exposed a data quality problem the carrier needs to fix regardless of which AI system they use. Addressing the data quality issue and running a second PoC is a legitimate path forward. A tool that performs poorly despite clean data is a tool the carrier should not contract with.

The second question is whether the failure is on the primary metric or only on secondary metrics. A tool that misses the deadhead threshold by one percentage point but demonstrates strong HOS compliance and a high backhaul conversion rate may warrant a contract with modified expectations rather than an outright decline. The PoC agreement's decision rules should address this: "if the primary metric misses the threshold by less than two percentage points and HOS failure events are zero, the fleet manager may recommend contract with a six-month performance clause."

The third question after a PoC failure is whether the problem is the tool or the deployment. A PoC that ran with incomplete data integration, a dispatcher who did not engage with the tool because of change management concerns, or a lane selection that was unrepresentative of the carrier's core freight may have failed for reasons unrelated to the tool's capability. The PoC conclusion report should diagnose the failure mode honestly, and the recommendation should reflect whether a re-run under better conditions is justified or whether the vendor was simply unable to perform on the carrier's freight.

Key Takeaways

• A PoC is a structured, time-bounded test on real lanes with a pre-agreed success metric and a documented baseline. It is categorically different from a free trial, a vendor demo, or a retrospective simulation on historical data.
• A PoC scope must define four elements before the vendor's tool touches the TMS: specific lanes, specific problem, numeric success threshold, and pre-PoC baseline calculated from the carrier's own data.
• The backhaul test is the definitive PoC for dispatch AI: measure whether the tool finds paying return loads on the actual lanes, with actual HOS constraints, before the window closes, and whether the dispatcher's acceptance rate translates to confirmed paid loads at an acceptable false-positive rate.
• One recovered backhaul is worth more than a hundred slides. Three documented recovered legs with dollar values attached is the business case the owner can read without a data science background.
• Every dispatch AI PoC must include an HOS compliance gate: a defined test for whether the tool filters out legally unrunnable proposals. Any proposal for a route exceeding driver HOS with no warning is a PoC failure event.
• The PoC agreement must specify data ownership and training-use restrictions for the PoC period itself, not just for the production contract. A vendor who cannot agree to PoC data restrictions before the full contract is negotiated should not be granted PoC data access.
• A PoC that does not meet its threshold is the AI program working correctly. It is a cheap lesson that prevents a multi-year subscription to a tool that did not perform on the carrier's actual freight.
• The PoC conclusion report comes from the fleet manager, not the vendor's account team. The vendor has a financial conflict of interest in assessing PoC outcomes. The fleet manager owns the decision.