Demand forecasting

Reorder sizes that move with demand, not against it.

Every morning I look at the last 12 weeks of shipments for each SKU. Weighted toward recent weeks, fit with a simple linear trend, projected over your supplier's lead time plus a 50% buffer. The next drafted PO is sized right.

PCB-100 demand
12 weeks · weekly
↑ trend up
Demand has been climbing 3 units/week for a month. Drafting the next PCB-100 PO at 320 instead of the flat 240 the reorder point would have asked for.

How it works

Math that doesn't pretend

Weighted moving average: each of the last 12 weeks gets a weight, recent weeks weighted heavier. Add a simple linear trend so a steadily-rising SKU gets bigger orders and a fading SKU gets smaller ones. Project the result over the supplier's lead-time-in-days plus a 50% safety margin.

No black-box neural nets, no probability bands. Honest math you can verify by hand. Cold-start (no shipment history) falls back to the flat reorder-point × 1.5 default, so new shops don't get garbage forecasts.

Wired into the morning reorder alerts

The reorder-alert cron already drafts a PO every time on-hand drops below the reorder point. With the forecast in place, the drafted quantity is whatever you'll actually need across the supplier's lead time, not a flat number that ignores the last three months of customer demand.

You still review and Issue. I just stop asking you to do that math in your head.

Why this is the new age of MRP

Legacy MRPs separate forecasting from procurement: one screen produces the forecast, a different screen consumes it (or doesn't).

TuringDock makes the forecast invisible. it's baked into the reorder alert you already trust. You see the right number on the draft PO, ask "why this much," and I explain.

Build what's next. Leave the MRPing to our AI.

Build what's next.

Leave the MRPing to our AI. Sign up free, set your shop up in an afternoon.

Get started for free

Last updated 2026-05-24