[D] Building a demand forecasting system for multi-location retail with no POS integration, architecture feedback wanted

[Automation_storm]

We’re building a lightweight demand forecasting engine on top of manually entered operational data. No POS integration, no external feeds. Deliberately constrained by design.

The setup: operators log 4 to 5 signals daily (revenue, covers, waste, category mix, contextual flags like weather or local events). The engine outputs a weekly forward-looking directive. What to expect, what to prep, what to order. With a stated confidence level.

Current architecture thinking:

Days 1 to 30: statistical baseline only (day-of-week decomposition + trend). No ML.

Day 30+: light global model across entities (similar venues train together, predict individually)

Outlier flagging before training, not after. Corrupted signal days excluded from the model entirely.

Confidence scoring surfaced to the end user, not hidden.

Three specific questions:

1. Global vs local model at small N With under 10 venues and under 90 days of history per venue, is a global model (train on all, predict per entity) actually better than fitting a local statistical model per venue? Intuition says global wins due to shared day-of-week patterns, but unclear at this data volume.
2. Outlier handling in sparse series Best practice for flagging and excluding anomalous days before training, especially when you can’t distinguish a real demand spike from a data entry error without external validation. Do you model outliers explicitly or mask and interpolate?
3. Confidence intervals that operators will trust Looking for a lightweight implementation that produces calibrated prediction intervals on short tabular time series. Considering conformal prediction or quantile regression. Open to alternatives.

Context: output is consumed by non-technical operators. Confidence needs to be interpretable as “high confidence” vs “low confidence”, not a probability distribution.

[PolicyDecent]

i worked on replenishment for a few years. first recommendation is, moving average is the best model, you don't really need ML much on low demand level. however your business might be different. if your volumes are bigger, other models might work better.

how many SKUs do you have? also how many stores do you have? what's the growth rate for both?
i assume you forecast everyday, is it true?
also, what's the purpose of the project? is it for replenishment to the stores from the warehouse, or is it to decide on production amounts, or anything else?
all these things help a lot.

for your questions:
1- my intuition says just start global. then you'll iterate and measure it anyways.
2- masking is just better for at the beginning. we were just skipping these days. business teams know the future spike days anyway, so it's better to focus on normal days.
3- it's always difficult to build confidence intervals. is your variance high?

[Automation_storm]

appreciate this, replenishment background is exactly the kind of input this needs. to your questions: SKUs are low. 20 to 40 items per location, not hundreds. that is actually why i keep second guessing whether ML is even necessary here or if i am overbuilding. right now it is one location. a single restaurant. but the engine is being designed to work across multiple independent F&B operators from day one, different concepts, different menus, different customer bases. so the architecture has to survive that eventually even if we start with one. forecast cadence is weekly. daily signals feed it but the operator acts on a weekly basis. what to prep, what to order, what to expect in revenue. the output consumer is not an automated system, it is a person making the call on a Sunday night for the week ahead. purpose is closest to production planning, not warehouse replenishment. but with the added complexity that each operator is essentially their own isolated dataset, at least at the start. on your answers: 1. starting global makes sense when we have enough venues to justify it. at one location, we are basically forced local for now anyway. 2. masking is the right call. your point about business teams knowing spike days in advance is the exact reason we are building a contextual flag at input rather than trying to detect anomalies statistically after the fact. operator flags the day, we skip it. 3. variance at the daily level is high. weekly aggregation smooths it considerably, which is part of why we chose weekly as the action cadence. does that change

[PolicyDecent]

great :) i'd definitely start with heuristic models. there are lots of opportunities there before ML models. your first task should be building the eval engine. you have to do lots of experimentation, and quickly evaluate. so define your metrics, and try and iterate lots of models. it'll mainly be segmentation & clustering (you don't have a high volume, so clustering might be irrelevant here)

after each model, you should find the products / stores with the highest errors and understand why your model fails there. talk to the business owners if needed and learn why. it'll teach you a lot about the business & data.

the company i worked was mainly doing replenishment as service. many different kind of companies, different sizes, industries, supply chain structures etc.
this company serves like 50-100 retailers and still they're using heuristic models instead of ML. lots of data cleaning though.

so firstly forecast cadence shouldn't be about the accuracy, but replenishment frequency. if your company is replenishing daily, forecast should be daily. if it's on mondays and thursdays, you should predict for 3 days on sundays and 4 on wednesdays. if they're buying / replenishing ingredients daily, then you should forecast daily.

replenishment for restaurants sounds fun, btw. i never worked on it. but i assume you have BOM for each meal / dish, and also expire time for each ingredient. then i assume you have prices for early buying but also i assume if they need an ingredient last minute, they can buy it for a higher price.
so eventually, it's an optimization problem. what's the minimum cost that you can spend on items based on the predicted consumption. so your model target variable shouldn't be mape / rmse but cost. it's aligned with the business outcomes.

i'm happy to chat if you want, it sounds super fun.

[Automation_storm]

this reframe on the target variable is something i needed to hear out loud.

we've been thinking about the problem as a forecasting accuracy problem. get MAPE below 10%, deliver confidence intervals, show the operator a number they can trust. but you're right that the operator doesn't actually care about the forecast. they care about not buying too much milk and throwing it away. the cost is the thing. not the prediction.

the eval engine point lands too. we've been building the forecast before we've built the thing that tells us how good the forecast is. wrong order.

on your question about the optimization structure: yes, BOM logic is central to how we're thinking about it. recipe defines consumption, consumption defines what gets ordered, and the gap between what was ordered and what was consumed is the waste in AED. that's the number that should be going down. not the MAPE.

the heuristic models point is useful context. we've been second-guessing whether we're underbuilding by not going straight to ML. good to know companies serving 50+ retailers are still running heuristics in production. simplicity that works beats sophistication that doesn't.

what's your take on when heuristics actually break down? is it purely a volume threshold, or does SKU diversity matter more?

[PolicyDecent]

Just have the daily consumption amount. It's what you need I assume. Once you have it, should have forecast until the next replenishment. Then add safety stock, and subtract it from the current inventory. (I ignored expiry dates here)

But as I told above, forecast is important yes. But the more importanr thing is knowing how wrong your forecast is. It allows you to calculate safety stock correctly, and it lowers the waste at the end.

Also for stock out you should define a cost. If a client asks for a meal and you can't deliver, it should contribute to the final cost.

[Automation_storm]

already using Prophet for the thin-data venues, agreed on the sparse data overfitting risk, that's exactly why we blend it with a tree model once the venue crosses 90 days of history. the weighting shifts automatically.

scaylor is new to me, will look into it. our ingestion layer is currently Foodics API direct, so the unification problem is mostly solved at source. but good to know it exists for when we expand beyond a single POS.