Here's my verdict up front: of all the warehouse AI forecasting projects I've watched die, not one died over model selection.
Lately more warehouse operators have asked me about "AI forecasting" — demand prediction, replenishment suggestions, labor planning estimates. The demos always look the same. The team cycles through models — gradient boosting, Prophet, whatever's fashionable — tuning hyperparameters down to the fourth decimal. Then I ask one question: what features are you feeding it? The spreadsheet that comes back usually has three columns: date, SKU, sales.
Those projects are dead on arrival. The model is the chef; features are the ingredients. Hand a chef a basket of rotten vegetables and the dish tastes the same no matter who's cooking. In forecasting, the real work sits outside the prompt — in the unglamorous grind nobody wants to do before data ever reaches the model: feature engineering.
Nine-Tenths of Warehouse Data Isn't Model-Ready
In 2023 I visited a 120,000-square-foot 3PL in Ontario, California. They'd paid good money for a sales forecasting model. Three months after go-live, it still couldn't beat their operations supervisor's gut feel — a veteran with over a decade on the floor. "This model doesn't even know what Black Friday is," he told me.
The diagnosis: the model trained on historical order volume only. Black Friday? No promo calendar in the system. Back-to-school season? Nothing. Port congestion delaying inbound by two weeks and blowing up every replenishment forecast? Definitely nothing.
That's the first trap. The most complete dataset in a warehouse — historical sales — is also the thinnest feature. It tells you what happened, never why. A model that only reads sales curves is just tracing yesterday's shape and guessing tomorrow's. The moment anything structural shifts — a promotion, a stockout, a new SKU launch — it falls apart.
So before touching any model, get the data house in order. Here's the checklist I hand clients:
Daily sales by SKU by facility — two years minimum, three is better. The promo calendar: who decided it, how deep, how many days, every event. Stockout records — days with demand but no inventory are not days with zero sales, though your system logs both as 0. Holidays and school breaks (Thanksgiving moves every year). Weather data — extreme weather moves the needle hard for local retail DCs. Port and linehaul congestion — for import operations, this decides when in-transit becomes on-hand. Returns by SKU — where return rates run high, gross and net sales are different stories.
More than half of that list doesn't live in your WMS. It lives in marketing's spreadsheets, in the ops manager's head, in the freight forwarder's emails. Before AI, you go collect it, structure it, and land it in one table. There's no shortcut, and no large language model will do it for you.
The Warehouse-Specific Ingredients
The generic tutorials will teach you lag features, rolling means, day-of-week flags. Do all of that. But warehouses have their own flavor, and a few features never show up in those tutorials.
In-transit quantity. "Inventory" in the system and "goods you can sell" are often two different things. For an import operation, a container spends 30 days on the water; during those 30 days system inventory reads zero, but sales planning can't treat it as zero. Feed "ordered but not yet received" in-transit volume as a feature so the model learns the difference between "low stock, no panic" and "low stock, real trouble." During the 2024 Red Sea diversions, one home-goods warehouse saw ocean transit stretch from 35 to 60 days — while its model kept advising "no replenishment needed." The goods were still on the ships.
Slotting velocity. The same SKU sells differently from a golden pick zone versus the top rack — pick efficiency drives fulfillment speed, speed drives repeat purchase. Few people think of this one: "average pick travel distance over the past 30 days," or simply "was it on a promo endcap." It absorbs a chunk of otherwise mysterious sales fluctuation.
Rolling return rate. Apparel and footwear DCs can see return rates in the twenties or thirties percent. A model trained on gross sales systematically overestimates real demand. Feed in "this SKU's return rate over the past 8 weeks" and let the model learn to discount accordingly.
The stockout flag. The most overlooked feature with the biggest impact. A zero-sales day — was it no demand, or no inventory? Your system records both as 0. Without a binary "was sellable inventory zero that day" flag, the model learns "nobody wants this SKU" from stockouts and recommends even less safety stock next time — the death spiral.
The Three Workhorses: Lags, Rolling Windows, and Alignment
Features chosen; now construction. Warehouse forecasting leans on three workhorses, and the devil is in how you tune each.
First, lag features: using the past N days of sales to predict the future. Seven days and the model only sees weekly rhythm; ninety days and the features get noisy. Start with 7, 14, and 28; check which bucket contributes most on the validation set, then fine-tune. Don't throw in a full 365 days on day one — too many features and the model starts memorizing instead of learning. That's the on-ramp to overfitting.
Second, rolling windows: trailing 4-week mean, trailing 8-week max, trailing 12-week standard deviation. Rolling windows capture trend. But 4, 8, and 12-week windows are highly correlated — saying the same thing three times. One or two is plenty.
Third — the most warehouse-flavored one — time alignment: lining up causes with effects. The promotion starts November 20, but the stocking decision was made in late October — the feature's timestamp should reflect the decision point, not the event point. These alignments differ for every warehouse; you map them by sitting down with ops and purchasing, one by one. The most valuable part of feature engineering, and the least copyable.
The Quietest Way to Die: Data Leakage
That's the "how." Now the "how projects die." Data leakage is the quietest killer in forecasting work, and it dies looking respectable — validation accuracy so high it makes everyone celebrate, then total collapse in production.
The classic leak: using "this month's actual promo depth" to predict "this month's sales." In training it works beautifully — deep promo, high sales. But at prediction time, next month's promo depth hasn't been decided yet. You're feeding the model data from the future. That's time travel, not forecasting. Fix it with the planned promo (known at decision time), or split the feature into known and unknown versions.
Another leak hides in rolling windows: predicting December with a "trailing 8-week mean" that quietly includes December's first week — data that doesn't exist yet at prediction time. The check is dumb but effective: for every training row, ask, "at prediction time, could I actually have had this number?" If not, delete it.
Then normalization leakage: computing scaling statistics over the full dataset, validation included. Sounds trivial, but on small-sample SKUs it inflates validation scores by several points. Compute statistics on training only; apply them to validation and test.
Is More Always Better? Let's Talk Trade-offs
Here's an unpopular verdict: more features is not better.
I once saw a 200-feature model beat its 30-feature sibling by two points on validation. The client was thrilled. Then I counted: sixty of those features depended on external feeds — weather APIs, congestion indices, social signals. One feed goes down, changes format, or paywalls, and you're reworking the pipeline. A 200-feature pipeline needs a dedicated data engineer; 30 features, the ops team handles alone.
Are two points of accuracy worth a full-time hire? At 400,000 orders a month, maybe. At 30,000, no. The goal isn't the most accurate model — it's the most accurate model the organization can afford to keep alive. Ship with 20 to 30 core features first; go live, validate, see business impact, then decide whether to add more. A 30-feature model running reliably for two years beats a 200-feature model nobody maintains after three months.
At acceptance time, don't stare at one accuracy number. I make clients check three things. First, beat the baseline — clearly outperform dumb alternatives like "same period last year" or "trailing 4-week average," or don't ship. Second, slice it — score bestsellers, long tail, and new SKUs separately; averages lie, and models often ace bestsellers while guessing on the tail. Third, prove the business value — five points of accuracy means how many fewer stockouts, how much less dead stock? A metric that can't reach a P&L is vanity.
Back to the opening line: the wrong model rarely kills you; wrong features always do. Next time someone pitches warehouse AI forecasting, don't ask which model they use — ask what their feature table looks like. If they can't answer, the project is still in the "beautiful demo" stage. The real craft has always lived beyond the prompt.
