AI Inventory Optimization Reorder points from real forecast error
Reorder points and purchase suggestions per product and store, recalculated weekly from the forecast and real supplier lead times.
- Installed for you · one-time$249
- Run for you$297/month
- Custom build · this process$5,000–8,000 one-time
- Starts whenSchedule Trigger (weekly, after the forecast run)
Bundled with demand forecasting at $497/month for both. Multi-echelon (DC → stores) allocation is a custom build. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
AI Inventory Optimization is an automation Agentmelt installs in Google Sheets. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $297/month, with setup and maintenance included. A custom build of this process is $5,000–8,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-17.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is inventory optimization?
AI inventory optimization is the step after forecasting: it turns each product's forecast and its error band, together with the supplier's real lead-time variability, into reorder points, safety stock and order quantities per SKU and location — recalculated every week instead of set once — and produces the purchase suggestions a buyer approves, with a plain explanation of what changed. The goal is fewer stockouts and less dead stock at the same time, which static min/max settings cannot deliver.
- Min/max levels were set two years ago and nobody has time to revisit 3,000 of them.
- We are out of the fast movers and drowning in the slow ones, in the same warehouse.
- Safety stock is a percentage everyone agreed on, not a number from lead-time data.
- Purchase orders are placed from a feeling about the season.
- The supplier's lead time changed, and the system still assumes 14 days.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Inventory optimization is the step after forecasting: turning a forecast and its error band into reorder points, safety stock and order quantities per SKU-location, then generating the purchase suggestions a buyer approves. The workflow recomputes the parameters weekly from actual forecast error and supplier lead-time performance instead of the static min/max most ERPs still use.
- Monday 6:00 The forecast, stock on hand, open orders and actual supplier lead times are read.
- 6:15 Safety stock and reorder points are recalculated; each product gets a service-level class.
- 6:30 Purchase suggestions land in the buyer's sheet with approve / adjust.
- On approval Draft purchase orders appear in the ERP; a reorder point that moved more than 20% carries a one-line reason.
Min/max levels were set once, by hand, and never revisited. Fast movers stock out while slow movers pile up. Buyers place orders from gut feel and a spreadsheet, and nobody can say what service level the stock is actually delivering.
Reorder points move with demand and supplier performance. Buyers receive a weekly purchase-suggestion list ranked by stockout risk, with the reasoning for each change. Working capital tied up in slow stock falls while service level on A items rises, and both numbers are on a dashboard every week.
Trigger, then 8 steps.
All eight steps run without anyone; a person sees only what the guardrails escalate.
Schedule Trigger (weekly, after the forecast run)
Read forecasts and error
p50 forecast and p90–p50 spread per SKU-location-week from the forecast table, plus measured forecast error by SKU segment.
Read inventory and open orders
On-hand, allocated, in-transit and open PO quantities from the ERP or WMS, and receipt history for lead-time measurement.
Measure supplier lead times
Mean and variance of actual lead time per supplier-SKU from PO created → received, replacing the ERP's static lead-time field.
Compute safety stock and reorder points
Safety stock from the service-level target, forecast error and lead-time variability; reorder point = lead-time demand + safety stock; order quantity from EOQ or supplier minimums and pack sizes.
Classify SKUs
ABC by revenue and XYZ by demand variability, so service-level targets differ by class (e.g. 98% for AX, 90% for CZ) instead of one number for everything.
Generate purchase suggestions
Every SKU-location whose projected position (on-hand + in-transit − forecast over lead time) falls below the reorder point becomes a suggestion, grouped by supplier into a draft PO.
Explain parameter changes
Where a reorder point moved more than 20%, the agent states why in one line: forecast up, lead time slipped, error widened. Buyers see the reasoning before they approve.
Publish to buyers and the ERP
Suggestions go to the buyer sheet with approve/adjust; approved lines are pushed to the ERP as draft POs via API.
No step waits for a person.
What the workflow hands to someone, by rule:
- Draft POs only — a buyer approves before anything is sent to a supplier.
Reorder points move with demand and supplier performance
Reorder points move with demand and supplier performance.
No decisions needed. Anything the guardrails flag is handed to a person; the rest ran alone.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
Data it touches
- Forecast table with quantiles (from the demand-forecasting workflow)
- ERP/WMS stock positions and open orders
- PO and receipt history (lead times)
- Supplier minimums, pack sizes and price breaks
- Service-level targets by ABC/XYZ class
Guardrails
- Draft POs only — a buyer approves before anything is sent to a supplier.
- Parameter changes above a threshold are explained and can be frozen per SKU.
- Service-level targets are set by finance and operations together, and the achieved level is reported weekly.
- Supplier lead times come from receipts, not from the master data, so the numbers reflect reality.
Why static min/max fails
A min/max level encodes an assumption about demand and lead time on the day it was set. Both change constantly: a product goes on promotion, a supplier's lead time drifts from 10 days to 18, a new channel doubles the volume. The ERP keeps the old numbers, and the buyer compensates from memory. The workflow replaces the assumption with a calculation that is redone every week from measured inputs — and, crucially, tells the buyer what changed.
The calculation, plainly
Reorder point = expected demand during the lead time + safety stock. Safety stock = z × σ, where z comes from the service-level target (about 1.65 for 95%, 2.05 for 98%) and σ combines forecast error over the lead time with lead-time variability. That is textbook; what the workflow adds is that σ is measured from your own forecast error and receipt history rather than guessed, and that it is recomputed weekly. Order quantity is the larger of the EOQ and the supplier's minimum, rounded to pack size, capped by shelf life where relevant.
ABC/XYZ classification is what makes the targets sensible. An AX item (high revenue, steady demand) can hold a 98% service level cheaply because its σ is small. A CZ item (low revenue, erratic) at 98% would tie up absurd stock; 85–90% is the right target and a stockout is acceptable. One service level for everything is how companies end up with both stockouts and overstock at once.
What to measure
Achieved service level (fill rate) by class against target. Inventory days on hand by class — the C items are where the cash is hiding. Expedite spend, which falls when reorder points are right. And the buyer override rate on suggestions: if buyers change most suggestions, the parameters or the targets are wrong, and the explanations will show which.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Scheduling, calculations, suggestion generation |
| ERP / WMS (NetSuite, SAP B1, Cin7, Fishbowl) | Stock, orders, receipts |
| Claude | Change explanations |
| Google Sheets | Buyer approval surface |
Want this running without building it?
$297/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$5,000–8,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Bundled with demand forecasting at $497/month for both. Multi-echelon (DC → stores) allocation is a custom build.
Also sold one-time, installed in your own accounts, as part of the e-commerce owners package and the supply chain managers package and the supply chain & procurement teams package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $297/month, setup and maintenance included. Three things move it to a custom build ($5,000–8,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
Multi-echelon allocation from distribution centres to stores.
Replenishment orders created in the ERP automatically under rules you sign off.
Several warehouses with transfer logic, or above 5,000 SKU-locations.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Does this need the demand-forecasting workflow first?
It needs a forecast with an error estimate. If you have a forecast from your planning tool, the workflow uses it; if not, the demand-forecasting blueprint provides one and the two are usually deployed together.
Can it place orders automatically?
It generates draft POs grouped by supplier. Buyers approve in a sheet or the ERP. Fully automatic ordering for a defined set of low-risk SKUs is possible as a custom option once the suggestions have proven reliable.
What about perishable or seasonal products?
Shelf life caps the order quantity, and seasonal profiles come through the forecast. Products with strict expiry need the custom build so the allocation logic respects dates.
Can an AI agent manage inventory on its own?
It can recompute the parameters and draft the orders every week; it should not place them. In this workflow the buyer approves the purchase suggestions — one screen, with the reason for each change — and the approval rate is tracked, so you can widen the automation where it is consistently right.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- Oracle — NetSuite documentation docs.oracle.com/en/cloud/saas/netsuite/index.html
- ASCM — supply chain standards and body of knowledge www.ascm.org/
- n8n docs — Wait node (approval steps) docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/