Retail Forecasting · Coming soon
Store-SKU planning without treating every store the same.
Openfluid Retail Forecasting is being designed for demand, replenishment and transfer decisions at the store-SKU level. The product is not yet live; we are working with design partners to define where forecasting must meet retail allocation, promotion and inventory rules.
Store-SKU demandReplenishment and transfer logicPromotion-aware evaluation
Retail planning conceptStore × SKU × Day
Conceptual illustration, not a live retail forecast.
Product boundary
What transfers from restaurants, and what does not.
Time-series structure, backtesting and governed decisions
Both products need entity-aware histories, future covariates, uncertainty, approval rules and a record of overrides.
Assortment, allocation, promotions and lost sales
Retail requires size or colour variants, store ranging, supplier constraints, substitution, returns, markdowns and censored demand caused by stockouts.
Planned capabilities
The first product scope.
▦
Store-SKU demand
Forecast units by store, SKU and planning horizon while preserving hierarchy across category and region.
↻
Replenishment
Convert demand into reorder quantities using current stock, inbound supply, case packs and service-level rules.
⇄
Inventory transfers
Compare store shortages and excess before placing a new order, with transfer cost and timing made explicit.
%
Promotion-aware planning
Represent promotion type, discount depth, display, media and cannibalisation rather than treating every uplift as repeatable.
Open product decisions
Questions the design-partner programme needs to answer.
Lost sales
How should demand be reconstructed when a store stocked out and recorded zero sales for the remaining period?
New products
Which attributes, comparable products and launch rules are available for SKUs with no history?
Store range
How are active assortment, planned delisting and store-specific range dates represented?
Decision ownership
Which recommendations can be automated, which require a buyer, and which belong to store operations?
Fit
Who should join as a design partner.
Useful starting conditions
- At least 12 months of store-SKU sales history
- Reliable on-hand and inbound inventory
- Promotion calendar and price history
- A recurring replenishment or transfer decision
- A team willing to compare recommendations with its current process
Not required on day one
- A perfect enterprise data warehouse
- Real-time feeds for every source
- Automatic order creation
- A commitment to replace existing planning systems
- A promise of improvement before a backtest is complete
FAQ
Retail questions.
Is Retail Forecasting available now?
No. It is explicitly marked coming soon. The current live product focus is Restaurant Forecasting.
Will it be the same product with different labels?
No. The platform components can be shared, but retail demand and supply constraints require their own data model, evaluation and workflow.
Can a retailer start with CSV exports?
Likely yes for discovery and backtesting, provided store, SKU, date, sales and inventory identifiers are stable. Production integration depends on the pilot scope.
What does a design partner receive?
A scoped data assessment, agreed decision use case, backtest and workflow prototype. Commercial and confidentiality terms need to be agreed separately.
Help define the first retail workflow.
Share the store-SKU decision that causes the most repeated manual work or avoidable inventory imbalance.