See it running

Four working systems. No demo call required.

One reads the signals the market is sending. One produces the number. One is where sales and planning argue about it and land on a plan. One decides what to buy with it and where it goes. Same synchronized data underneath all four. These are the real interfaces, running on synthetic data with vendor names genericized — not mockups drawn for a website.

Nothing here is a product you buy a licence to. Every screen is built to the business it serves — your ERP, your data, your segmentation, your cadence, your definitions. What carries over is the method, not the software.

Nine linked workbenches over one forecast archive and a live ERP feed.

Click to start · runs on a loop Open in a new tab ↗

What you're looking at

Four layers of the same problem.

The first two are a pair. The Suite is where the number gets debated and agreed; the Engine is what produces the number it starts from. Most companies have some version of the first and nothing underneath it — which is why the debate never ends.

Three of these run in production against forecasts generated by a licensed platform. That's an architecture choice, not a limitation: if you've already bought Relex or Blue Yonder, I build on top of it rather than around it. The Forecasting Engine is the other case. Plenty of mid-market companies plan on spreadsheets, have no forecast engine at all, and can't justify seven figures to get one. It's a reference build — the one system on this page I haven't yet run for a client — and it's what I'd put in front of them.

01 — Demand Planning SuiteIn production

Where the number gets agreed

Nine linked workbenches over one forecast archive and a live ERP feed. Sales and planning review the same numbers at account and SKU level. Forecast error is measured where it actually happens — item by warehouse, so misses never net out into a company average that hides everything. An AI layer reads the whole archive and tells planners which handful of items to look at today.

  • Forecast waterfall & revision tracking
  • Demand consensus, account-level
  • Pre-SIOP accuracy at lowest detail
  • MTD sales & open bookings by risk tier
  • Inventory reporting & in-stock rate
02 — Forecasting EngineReference build

Where the number comes from

The engine underneath the suite above. Every series gets profiled on how intermittent and how variable its demand actually is, then routed to the model built for that behavior — quantile LightGBM for smooth and erratic items, Tweedie for intermittent and lumpy ones — and forecast as a P10–P90 range instead of a single number. It's backtested against seasonal naive on every run, calibration is reported separately from accuracy, and each item carries a written rationale for the grain and the model it was given. I built it so that when a company with no forecast engine asks what I'd put underneath their plan, there's something to show them rather than a description.

  • Seven-stage pipeline you watch reason
  • ADI / CV² diagnostic routing
  • Rolling-origin backtest vs. naive
  • Interval coverage, checked per segment
  • Routing and grain rationale per item
03 — Planning Workbench & AgentIn production

What to buy, and where it goes

Inventory health across every SKU-location, vendor windows and MOQ fit across the buying horizon, and cross-warehouse transfers that avoid the buy entirely. Then an AI agent works a queue of vendors, approving, adjusting or rejecting each suggested PO line with its reasoning on the record — so a buyer has something to disagree with rather than a black box to distrust.

  • Buyer workbench, exception-driven
  • Transfer-before-buy across the network
  • Supply planning agent with audit trail
  • Natural-language query panel
04 — Sales IntelligenceIn production

What the market is telling you first

Two years of weekly sales run against weather, fuel, housing and survey data. Correlation matrices, lead-lag scans that find which series moves first and by how many weeks, anomaly detection at three sigma, k-means account segmentation and cohort retention — then a natural-language layer over the whole dataset. This is where outside signals stop being interesting and start being early warning.

  • STL decomposition, trend vs. season
  • Lead-lag scan across candidate series
  • Three-sigma anomaly detection
  • Account segmentation & cohort retention

Fair questions about a demo

Four things worth saying up front.

01

The data is synthetic

Every number, customer and vendor name in these walkthroughs is fabricated. The interfaces, logic and screen flows are real and in production use elsewhere. I won't show you another company's data, which is also the answer to what happens to yours.

02

You wouldn't get this exact thing

These were built to one company's ERP, segmentation and cadence. Yours would look different, because the segmentation thresholds, exception rules and service targets have to come out of your data. What carries over is the method and the speed of building it.

03

The tooling isn't the engagement

Software is the second half. The first half is the cadence, the definitions and the decision rights — and a workbench installed on top of an unresolved process just automates the argument. If you only want the build, I'd tell you to hire a developer.