In the spring of 2024, an operations manager at a 3PL outside Dallas signed a contract for a drone-based AI inventory system. The demo had been spectacular: a drone gliding over the racks, variance reports generating themselves. He signed on an annual subscription. Then reality arrived. The warehouse ran on a decade-old WMS, and the custom data interface IT needed was already queued two quarters out. The "recognition accuracy" in the contract had been measured on the vendor's own test set — nobody had tested it in a mixed zone of pallets and loose cartons. A full year of subscription fees went out the door before the system ever connected to a single data source.
The technology was fine. The ownership was wrong.
I have watched this movie from the other side too. An IT-led project, a vision AI system for receiving inspection at a mid-sized warehouse. The IT director did everything by the book: lined up three vendors, compared spec sheets on accuracy, latency, and API protocols, picked the one with the best lab numbers. What he never did was walk the receiving dock with the crew. In a real warehouse, rack lighting glares, labels get slapped on crooked, and shrink wrap catches the light. None of that appears in a spec sheet. In the first week, false positives doubled the crew's verification time. The receiving lead told me flat out that the scanner gun was faster. Within a couple of months, the night shift had stopped turning the system on.
Here is the uncomfortable truth about warehouse AI: the hard part was never the model. It is three questions — where does the data come from, who defines what counts as "correct," and who is accountable for the result. IT cannot answer all three alone. Operations cannot answer all three alone. A RAND report published in 2024, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed," found that more than 80 percent of AI projects fail to deliver their expected value, and the roots usually trace back to organization and data, not algorithms.
Even Amazon, which can outspend everyone, refuses to let the algorithm close the loop by itself. In June 2024 the company announced Project P.I. — "private investigator" — a system combining generative AI and computer vision in imaging tunnels across several North American fulfillment centers to catch damaged products and wrong colors or sizes before dispatch. The detail that matters: items the system flags are reviewed by Amazon associates, who decide whether the product gets discounted, donated, or kept moving. Humans make the final call. If Amazon will not let the machine run the warehouse on its own, a 50-person 3PL certainly should not try.
The IT-Led Trap and the Ops-Led Trap Are the Same Trap
The two failure modes look like opposites, but they fail for the same reason: one side of the building owns a decision that requires both sides.
When IT owns it alone, you get a technology toy. The demo gets applause; the floor routes around it. IT evaluates what it can measure — accuracy on clean data, uptime, integration effort — and underweights the things that decide adoption: glare on the third level of a rack, a process the crew will actually follow at 2 a.m., who retrains the model when the product mix changes in Q4.
When operations owns it alone, you get a purchase order in search of a project. Operations can describe the pain perfectly and cannot evaluate the delivery path. The vendor's salesperson is paid to get the signature, not to get the system working — and the ops-led buyer is the easiest person in the building to dazzle with a demo that will never survive contact with a legacy WMS.
The fix I now recommend to every client is a dual-lead model: one business lead and one technology lead, peers, sharing the outcome. It sounds like a platitude until you write it down. The business lead owns three things: defining the problem (slow cycle counts or high variance — pick one), committing the people and hours for data work, and signing off on effectiveness. The technology lead owns three different things: vendor and architecture selection, WMS and hardware integration, and data security. The overlap in the middle — translation — belongs to a business analyst role that you cannot skip.
That BA is not a documentation clerk. It is someone who speaks both languages: they can spend half a day with the cycle-count crew, come back, and explain to the vendor in technical terms that the third level of one rack reflects light; they can hear the vendor say the model needs thousands of labeled images and translate that into "the count team gives up three days." Promote a senior supervisor into it or hire an outside advisor — but do not run the project without one. Without a translator, IT and operations meetings are two monologues. Either IT caves to an unreasonable business demand, or operations gets forced onto a tool nobody likes.
How to Run the Pilot Without Burning a Year
Staff the pilot lean but fixed: one BA, full-time on the project; one IT counterpart, part-time is fine, but it must be the same person every week; two floor operators, fixed for the duration, no rotation — the fastest way to corrupt a pilot is to keep changing who is being measured; and one vendor implementation specialist. Cadence: a thirty-minute standup every week covering only three things — what the data showed, what is blocked, what gets tested next — and a one-hour monthly review on the trend. My rule of thumb: a pilot must reach a verdict in six to eight weeks. Go/no-go. Pilots that drift past three months almost always die quietly, with the money and the goodwill gone.
Acceptance is where I get strict. One page, two signature lines. The business lead signs for effectiveness: two consecutive weeks in the real environment, on real shifts, hitting the miss-rate and false-alarm numbers that were written down before the project started. The technology lead signs for the technical side: stable interfaces, data flowing back into the WMS, access controls in place. One signature missing means the project is not done. And the acceptance criteria must exist before kickoff — criteria written on acceptance day are criteria the vendor will always pass.
The One- or Two-Person Warehouse Can Still Do This
Smaller operators read all this and think: we barely have two managers, where do we get dual leads? The answer is that the smaller you are, the lighter — but also the more literal — the structure has to be.
Boil it down to one move: pin the translator role on a single named person. Pick the warehouse supervisor least hostile to systems, or the IT person who actually walks the floor. Give them a title for the duration of the pilot — business counterpart for this AI project — and one protected hour a day. That hour matters more than the software license, because nine times out of ten, AI projects die from "nobody on the floor cooperated," not from "the model was wrong."
On selection, resist the bundle. Start with exactly one pain point: count variance, putaway location search, or outbound verification. When the vendor asks whether you want the extra modules, say no. Three clauses go in the contract: payment tied to pilot results with an unconditional exit if the pilot misses; the data-interface work and its timeline attached in writing; training delivered to the floor operators, not just their supervisors. And three hard acceptance tests: two weeks in the live environment, the numbers agreed before kickoff actually hit, and — the one that matters most — the operators turn the system on voluntarily. The most accurate system in the world is worthless if the crew will not boot it up.
Here is the exercise I would do tomorrow. Take the AI project you are running or planning, and write one page: what problem it solves, what the acceptance criteria are, and the names of the business lead and the technology lead — with two blank signature lines at the bottom. If you cannot write that page, or if both lines can only hold the same name, you are looking at the same configuration as the dust-covered equipment in my opening story. Kill it early. It is far more dignified than burning the budget first.
