The attempt usually looks the same. You download on-hand from the 3PL portal, open the inventory report the retailer sends, pull last month of shipments out of NetSuite, paste all three into Claude and ask what needs reordering before the end of the month.
For one product with one location, that works, and the answer is often better reasoned than the spreadsheet it replaces. AI inventory planning starts failing at the point where the position stops fitting in the window: four locations, two pack configurations, 900 SKUs, and a retailer file that names the same product differently from your own system. What follows is where the line sits, from both directions.
Where AI inventory planning works today
Give a model one file and a clear question and it holds up well. It will read an export with no header documentation and tell you which column is on-hand and which is committed, which saves the twenty minutes you would have spent asking the 3PL. It will write the coverage math, explain why a safety stock formula produced that number, and show the arithmetic when you challenge it.
It is also good at the reasoning around the number. Ask why a SKU with eight weeks of cover is still stocking out at one account and a model will work through the plausible causes: a promotion pulling volume forward, stock sitting at a location that account does not draw from, a lead time that no longer matches what the supplier quotes. Those are the questions a planner would ask, and having them listed in ten seconds is worth having.
Where the whole picture fits in one place, this is enough. A brand selling one line through Shopify and one 3PL can run a planning cycle out of a chat window and a spreadsheet, and should, until the third channel arrives.
Where it breaks: the position lives in four places
Right answers are hard to pull out of large datasets, and inventory is a large dataset wearing the disguise of a small one. The number you want, units of a product available to sell against demand you can see, is assembled from sources that each hold a fraction of it and disagree about what a product is.
| Source | What it knows | What it cannot tell you |
|---|---|---|
| 3PL or warehouse portal | On-hand and committed by location, in cases | What is already sold through at retail |
| Retailer inventory report | Store and DC stock for their doors, by their item number | Anything about your other accounts |
| Your ERP | Shipments, open orders, standard cost | Whether the shipment sold or is sitting in a back room |
| DTC platform | Units sold and on-hand for the channel you control | The wholesale half of demand |
Paste all four into a chat and three problems arrive together. The files exceed what the window holds, so rows get dropped without an error, and a total that is missing a location looks exactly like a total that is not. The product mapping you explained last week is gone this week, so the model matches on name similarity and quietly merges a 12-count with a 12-pack. And because none of it is written down anywhere, the same question asked twice in a fortnight returns two different numbers, with no way to see which inputs changed.
- Rows dropped without an error
- Mapping re-explained every week
- Two answers in a fortnight
- Every location in the total
- One product key, written once
- Same answer, or a logged change
What has to be true underneath
The fix is not a better prompt. It is that the four sources arrive in one place, keyed the same way, before anything is asked of them.
This is the part we built Permute for. We connect the 3PL feed, the retailer reports, NetSuite, Shopify and the rest of the systems we connect, then resolve them into one record per product across every location it sits in, which is the job of the Data Foundation layer: a case of twelve and a twelve-count carton become the same item with a stated conversion rather than two rows that happen to look alike. On-hand, committed, in transit and sold-through are defined once in that record and applied everywhere they are used, which is what makes the coverage number reproducible rather than a fresh calculation each week. A planner then asks in plain language which SKUs fall under four weeks of cover at current run rate, and the answer arrives with the source rows behind it: this location, this feed, received at this time. When a 3PL file lands late, the number moves and the workspace says which location moved it, rather than presenting a stale figure as current. That is what a context layer actually does, and it sits underneath Claude or ChatGPT rather than replacing either.
See your stock position in one place
Connect a 3PL feed, your ERP and your DTC channel, then ask what needs reordering.
What stays human
Three things do not move into either the model or the layer underneath it, and pretending otherwise is how automation projects lose the room.
- The buy itself. Cash, minimum order quantities and what you are willing to be wrong about are a judgement call, and the person who owns the outcome should make it.
- The forecast. We are not a forecasting engine: we supply the clean history a forecast is built on, and the projection belongs in a planning tool or a model you trust.
- The write-back. We read from the systems we connect and do not write into them, so the purchase order is still raised in your ERP by someone who meant to raise it.
What changes is the input to those decisions. A planner arguing about whether to expedite a container should not also be arguing about whether the on-hand figure includes the Reno location.
A test worth running this week
Take one SKU that stocked out in the last quarter (the one everybody still brings up) and reconstruct the week before it happened. Write down the on-hand you would have seen in each source, the lead time you would have used, and the demand signal available at the time. Then ask what it would have taken to see it coming.
Across the consumer brands we work with, the answer is rarely a smarter model. It is that two of the four numbers were three days old, one was in cases while the report was in units, and nobody had joined the retailer sell-through to your own shipments. Our How to automate POS data analysis covers that join in detail, and CPG demand planning starts with the sales history covers the history a forecast needs. Both are the same underlying job: define the record once so the interesting question is the only one left.
Bring your own exports to the call
We will walk through where the position fragments across your warehouses, retailers and 3PLs, and what it takes to close the gap.
Questions ops teams ask about AI and inventory
Can ChatGPT do inventory planning on its own?
For a single product line in a single location, yes, and the reasoning it shows is often better than the spreadsheet it replaces. The limit is not intelligence but state: it has no durable record of your product mapping, your locations or your lead times, so every session starts from whatever you paste into it.
Once the position spans several sources, the work shifts from asking the question to assembling the inputs, and that part needs to live somewhere the model can read from.
How much history does this need before it is useful?
Twelve to eighteen months of shipment and sell-through history covers a seasonal cycle and gives you something to check a coverage assumption against. Less than that is still workable for the current position, which only needs the last few weeks.
The constraint is coverage rather than depth: six months from every channel beats three years from one.
Does this replace our planning tool?
No. Planning tools own the projection and the replenishment logic, and a good one is worth keeping. We sit underneath it, supplying one defined version of on-hand, shipments and sell-through so the tool is not modelling on top of four disagreeing exports.
Where a brand has no planning tool at all, the honest first step is usually the clean history rather than the software.
How are cases and units handled?
As a stated conversion on the product record rather than a formula in a spreadsheet. The 3PL reports cases, the retailer reports units, and the conversion between them is a fact about the product that should be written once and applied everywhere.
When a pack configuration changes, the conversion changes with a date attached, so last year numbers stay correct instead of being retroactively rewritten.