Inventory planning automation: what to automate first

Most inventory planning automation projects are aimed at the wrong half of the job. The brief says the system should tell us what to reorder, so the work goes into replenishment logic, reorder points and safety stock formulas, and the pilot stalls with a planner still exporting from the 3PL portal on a Monday morning to check whether the system is right.

The planning cycle has two halves. One is assembly: gathering the position, mapping products, converting units, working out what is in transit and what sold. The other is the decision: what to buy, how much risk to carry, which supplier to push. The first half is mechanical, repeated every week, and worth automating immediately. The second is judgement, and automating it before the first half is solid is why these projects lose credibility.

The assembly half, and what it costs

A weekly cycle at a brand with three warehouses, two retail accounts and a direct channel involves roughly this sequence, done by hand.

1. Export on-hand and committed from each 3PL or warehouse system, in whatever unit that system reports.
2. Pull open purchase orders and in-transit quantities from the ERP, then work out which ones will land inside the horizon.
3. Download retailer inventory and sell-through reports, each on their own item numbers and their own week.
4. Pull direct channel sales and on-hand from the ecommerce platform at daily grain.
5. Map every identifier to your own SKU, convert cases to units, and reconcile the totals that disagree.
6. Calculate coverage, flag what is short, and circulate a file that is out of date by the time the meeting starts.

Steps one to five are the whole opportunity, and none of them require a decision. They take a planner most of a day each week, they are the reason the meeting opens with an argument about whether the numbers are right, and they break when the one person who knows the mapping (there is always one) takes a week off.

Why inventory planning automation stalls at the product key

The structural reason these projects stop is that automation needs an unambiguous product, and a consumer brand has as many product identities as it has partners. The 3PL knows a pallet SKU, the retailer knows their own item number, the marketplace knows an ASIN, the co-packer knows a finished goods code, and your ERP knows the one you consider real. A script that joins on name similarity works for a quarter and then merges a 12-count with a 12-pack, which is worse than the spreadsheet because nobody is checking it.

The calendar does the same thing to time. On-hand is a snapshot at the moment the file was cut, retailer sell-through covers a week ending Saturday, and in-transit is a promise about a date. Coverage in weeks is a division that needs those three to agree on what a week is, and when they do not the answer moves depending on who ran it.

Both problems are definitional rather than technical. Any competent engineer can write the join once the rule exists; the reason it does not exist is that writing it down means someone has to decide, and the decision has consequences for a report the finance team already publishes.

What automating the assembly looks like

This is the job we built Permute for. We connect the warehouse and 3PL feeds, NetSuite or whichever ERP holds the open orders, the retailer portals, Shopify and Amazon Seller Central, and the rest of the systems we connect. Each product resolves to one record across every partner identifier, with pack conversions and their effective dates attached, which is the Data Foundation layer doing the unglamorous half of this work. On-hand, committed, in transit and available to sell are defined once and applied wherever they appear, so the coverage figure in the Monday file, the dashboard and the answer to a question typed in plain language are the same figure. A planner asks which SKUs drop under four weeks of cover before the next container lands, and the answer arrives with the rows behind it: this location, this open order, this feed, received at this time. When a 3PL file is late, the workspace says so rather than presenting a total that is missing a warehouse.

What we do not do is decide. We are not a forecasting engine and we do not raise purchase orders: we read from the systems we connect, and the buy is still made by the person accountable for it, in the system that owns it. Where a brand runs a planning tool for replenishment logic, we sit underneath it and feed it one defined position rather than four exports.

A sequence that works

Automate in the order that removes argument, not in the order that looks most advanced.

1. One defined product key across every partner, with pack conversions dated. Nothing downstream is reliable until this exists.
2. One calendar and one definition each of on-hand, committed, in transit and available to sell.
3. Automated collection of every feed, with the arrival time recorded and lateness visible.
4. The coverage report generated rather than assembled, on a schedule, with the source rows reachable.
5. Exception flags for the cases a planner should look at: cover under a threshold, a feed that did not arrive, a total that moved after a restatement.
6. Only then, replenishment logic in a planning tool, working from inputs nobody disputes.

Brands that follow that order tend to find the fifth step removes most of the meeting and the sixth is a smaller purchase than expected. Brands that start at the sixth step spend a year proving the inputs.

For the adjacent pieces, AI inventory planning: what works and what breaks covers what a general model can and cannot do with these same exports, and CPG demand planning starts with the sales history covers the history behind the demand half of coverage. Consumer brands comparing this against another hire will want what it costs in the same conversation.

Questions ops teams ask about automating planning