Last year a 3PL in Ontario called me in as a consultant. They wanted AI demand forecasting, the vendor demo looked slick, and the contract was practically signed. I spent two days on site and told the owner the first thing when I got back: spend this money now and it's gone. Not because the algorithm was bad — but because out of their 20,000-plus SKUs, more than 4,000 didn't even have barcodes on them. Pickers identified product from memory. No algorithm on earth can forecast the part of your inventory that lives in someone's head.
That's the most common way AI dies in a warehouse: it dies on data, not on technology. I've watched a dozen AI pilots over the years, and seven or eight out of ten failures trace back to data prep that never happened. Vendors won't volunteer this — they make money selling licenses, so they'd love you to sign early. Here's my own checklist: before AI goes live, three categories of warehouse data have to be cleaned up first. If one category fails the bar, don't launch the use case that depends on it. You'll save more than you think.
Master data: SKUs, locations, lots — "close enough" isn't
Master data is the foundation every AI model stands on. Missing SKU attributes, messy location codes, lot info patched in by hand — in traditional operations you can paper over all of this with veteran tribal knowledge. The moment AI enters the picture, every gap becomes a landmine.
I hold clients to three hard bars. First, SKU master completeness above 95%: dimensions, weight, pack specs, ABC class. Miss these and the AI's slotting and wave planning is garbage in, garbage out. Don't believe "the algorithm auto-fills gaps" — dimensions off by 10% means every carton recommendation is wrong.
Second, 100% of locations must be scannable. AI dispatching AMRs and optimizing travel paths assumes every system location maps to a physical one. I've seen a building with 12,000 locations in the system where a floor audit turned up 300-plus ghost locations — labels fallen off, racking removed, still sitting in the database. Feed that to an AI and every route it plans is fiction.
Third, lot and expiry data has to close the loop. For food and pharma warehouses running expiry-warning AI, no lot-level inbound/outbound records means no training samples at all. This is the slowest data to rebuild, because the history usually doesn't exist — you start collecting today and wait a full quarter.
How to fix it? Don't launch a cleanup campaign. My method: sample 200 SKUs, compute the master-data error rate. Above 15%, you need a systematic rebuild — budget two to three months. Below 5%, you can launch AI and backfill in parallel. Do this math up front, not after the algorithm goes live.

Event data: timestamps must be continuous, or the history is worthless
AI learns how your warehouse actually runs, and its textbook is every scan, every putaway, every wave timestamp. The biggest problem here isn't missing data — it's broken data.
Plenty of warehouses scan receiving, putaway, and picking religiously, then run pack and ship on paper. The timestamps stop halfway. An AI trying to learn true order cycle time hits a dead end mid-lesson. Others let night shifts skip scans to hit rate, leaving whole stretches of the record blank — a model trained on that data will systematically underestimate night-shift capacity.
My acceptance bar: scan coverage above 90% at every key step, continuous for three months. Not there yet? Two fixes. The cheap one is scan-compliance management: put scan rate into the shift KPI, and coverage climbs within two months at almost zero cost. The expensive one is hardware, like auto weigh-scan units at pack stations. I usually recommend the cheap fix first — fix the habit, get continuity, then talk AI.
One more thing: keep at least six months of history covering a full slow-and-peak cycle. A model trained only on peak data will cry wolf all through the slow season, and vice versa. When a vendor says "three months of data is plenty," that's the sound of someone who wants to get paid sooner.
Outcome data: without a report card, AI never graduates
The first two categories are inputs. This one is outputs: cycle-count variance logs, pick-error records, on-time rates, return-reason classifications. Models need outcome data to know whether they're right. Without it, after go-live you can't even tell whether the model is improving or hallucinating.
This gets ignored most because outcome data lives everywhere: variances in a spreadsheet, complaints in email, return reasons in someone's head. Last year I assessed a client for AI vision cycle counting and found two years of variance records stored only as totals — no SKU detail. The model couldn't even learn where the errors were. Its accuracy ceiling was obvious before we started.
The fix is one master outcome log: date, SKU, process step, issue type, dollar impact. Log it by hand for two months to build the habit, then systematize. It has a side benefit too: plenty of management problems surface from this log alone. You get a management upgrade before AI even arrives.
Budget reality: data prep eats 60–70% of the project. Don't be shocked.
Honestly: in an AI pilot, data prep typically consumes 60 to 70 percent of the time and effort; algorithm selection and deployment take the rest. Vendor project plans rarely say this — they'll list data prep as "two weeks of client cooperation." Believe it, and your project slips three months minimum.
My advice: run a data health check before kickoff, scoring each of the three categories out of ten. Below 18 total, don't talk AI yet — run data prep as its own three-to-six-month project, then come back. Above 24, go straight to POC. I've run this check for five or six clients, and every time it's killed one or two doomed projects. The savings are real money.
The blunt truth: data prep has zero glamour. It's all grunt work, which is why nobody volunteers — vendors skip it, and nobody inside owns it. But in the AI era, data is the new racking. Messy racking means lost product; messy data means your AI is decoration. Pour the foundation first, and the algorithm part gets easy.







