How to Choose a Demand Forecasting Tool for Quick Commerce Dark-Store Replenishment (2026)
Choose a quick commerce demand forecasting tool by checking three things: that it forecasts at the level platforms actually order from you, that it respects the constraints deciding what you can ship, and that it beats a simple baseline in a blind backtest on your own history. For most brands the platform replenishes its dark stores from its own warehouses, so the forecast that drives your decisions is SKU × platform × city or platform warehouse, informed by whatever store-level sell-through the platform shares. The tool must turn that into stock positions and supplier POs that respect shelf life, case and crate MOQs and inward lead times.
Shortlist with the ten-point checklist, compare vendors on the scoring table, and run the backtest method in this guide before signing. Vendors who will not backtest on your data, or who quote accuracy figures from other customers, belong lower on the list. We publish no accuracy benchmarks here, because results depend on your data, categories and platform mix.
Key Takeaways
- Your forecast unit is usually SKU × platform × city or platform warehouse. Dark-store forecasts need dark-store data you may not receive.
- PO history is censored by your own cuts and stockouts. A tool that learns from shipped quantity will under-forecast exactly where you were short.
- Shelf life, crate MOQ, lead times and stock in transit belong inside the recommendation, not in a planner’s head.
- Judge accuracy only through a blind, rolling backtest on your data, against a naive baseline, using WAPE and bias by segment.
- A forecast is only useful when it becomes a supplier PO or transfer without an export.
How we evaluated
This guide comes from planning replenishment for FMCG brands that supply quick commerce platforms, where the inputs are platform POs, GRNs and shared sales reports rather than point-of-sale data. It scores capabilities and evidence, not vendor names, and deliberately contains no accuracy benchmarks: any number we printed would describe someone else's data. Platform data-sharing, receiving norms and commercial models vary by platform, category and contract, so treat platform-specific points as questions to confirm. For a vendor landscape, see our top 10 AI replenishment and demand planning solutions.
Disclosure: FilFlo publishes this guide and sells software in this category; it appears in one labelled section.
What "Dark-Store Replenishment" Means for a Brand
There are two replenishment loops, and only one of them is yours. In the common inventory-led model, the platform runs the inner loop: it moves stock from its warehouses to dark stores using its own algorithms. You run the outer loop: you anticipate the POs the platform will raise on your brand, position stock in your warehouses or 3PL nodes near each platform warehouse, and buy from suppliers or co-packers early enough to fill those POs.
That means your forecast has two signals to reconcile. Sell-through tells you what shoppers bought, at whatever granularity the platform shares. PO history tells you how the platform buys, including its own stocking policy, and is distorted by every line you cut. A tool that uses only one of the two will be systematically wrong in a predictable direction.
| Forecast level | What it answers | Watch out for |
|---|---|---|
| SKU × national | Production and procurement volume | Too coarse for platform POs; hides city-level stockouts |
| SKU × platform | Channel plans, promotions, trade terms | Still blind to where in the country stock is needed |
| SKU × platform × city or platform warehouse | Which POs to expect, where to position stock | The usual decision level for brands supplying platforms |
| SKU × dark store | Assortment and availability by neighbourhood | Needs store-level data the platform may not share |
| SKU × your warehouse or 3PL node | Supplier POs and inter-warehouse transfers | Must be rolled up from the platform-level forecast |
The Constraints a Forecast Must Respect
Shelf life. Platforms typically set a minimum remaining shelf life for stock they accept, and the exact norm depends on your agreement and category. For short-life products, that caps how far ahead you can build, and a forecast that recommends three weeks of cover on a product the platform will only accept fresh is unusable.
Case size and crate MOQ. Platforms receive in cases or crates, and suppliers sell in MOQs. Recommendations have to land on those steps, and the rounding decision (up or down) should depend on shelf life and cover, not a fixed rule.
PO cut patterns. Every time you approve less than the platform ordered, your history records supply, not demand. Recording cut reasons (short stock, shelf life, price, MOQ) is what lets a forecast separate the two.
Lead times. Supplier inward time, transit to the platform warehouse and the wait for an appointment slot all sit between a decision and stock on the platform's shelf. Count stock already in transit, or every alert triggers a second order.
Events. Platform sale days, festivals, regional occasions, weather, price changes and new listings all shift demand, often city by city. Our guide to seasonal demand planning covers how to turn festival peaks into run-rate and lead-time adjustments.
The Decision Checklist: 10 Criteria
- Granularity that matches your decisions. At least SKU × platform × city or platform warehouse, rolled up to your own nodes for supplier POs. Dark-store level only where you get the data.
- Data it will actually ingest. Platform POs, GRNs, sell-through and inventory reports, your stock and in-transit, price and promotion calendars. Ask for a data-mapping sheet per platform: fields, format, frequency, who loads it.
- Censored demand handling. Trains on ordered quantity, not fulfilled; flags periods when you cut POs or were out of stock on the platform.
- Shelf life and expiry. Recommendations respect minimum remaining shelf life at receiving (norms vary by platform and category) and expected sell-through before expiry, especially for short-life SKUs.
- Case size and crate MOQ. Rounds to whole cases and crates, and to supplier MOQs, so every recommendation is shippable.
- Lead times and stock in transit. Uses supplier inward lead time, transit to the platform warehouse and appointment waiting time, and counts stock already on a truck so it does not double-buy.
- Events and promotions. Accepts a calendar of platform sale days, festivals, regional events, price changes and launches, and models the dip after an event as well as the spike.
- New SKUs and new cities. A stated method for items and locations with no history, such as borrowing the curve of a similar SKU or city, with planner review.
- Explainability and overrides. Planners can see why a number is what it is, override it with a reason, and later see whether the override helped.
- From forecast to action. Output becomes recommended stock per node and draft supplier POs or transfers in the system where you run them, not a dashboard to export.
Scoring Table You Can Copy
Score 1 to 5 per row, multiply by the weight, total and divide by 5 for a score out of 100. Score the backtest row only from a backtest run on your data; if a vendor declines, that row is a 1.
| Criterion | Weight | What a 5 looks like | What a 1 looks like | Score (1-5) |
|---|---|---|---|---|
| Granularity | 10 | SKU × platform × city, rolled up to your nodes | National or monthly only | |
| Data ingestion | 15 | Mapping sheet per platform; automated or scheduled loads | Analyst pastes data weekly | |
| Censored demand | 10 | Uses ordered quantity, flags cuts and stockouts | Treats shipped quantity as demand | |
| Shelf life and expiry | 10 | Caps recommendations by receivable shelf life | Ignores expiry | |
| Case size and MOQ | 5 | Rounds to cases, crates and supplier MOQ | Fractional units | |
| Lead times and in-transit | 10 | Lead-time aware, counts in-transit | Static reorder points | |
| Events and promotions | 10 | Calendar input with spike and post-event dip | One seasonality toggle | |
| Backtest result on your data | 15 | Beats your naive baseline on WAPE and bias in your key segments | No backtest offered | |
| Explainability and overrides | 5 | Drivers visible, overrides tracked | Black box | |
| Forecast to action | 10 | Draft POs and transfers in your workflow | CSV export only |
Weights total 100. Weighted score = sum of (weight × score) ÷ 5.
How to Backtest Without Trusting Anyone's Accuracy Number
- Pick a holdout window of recent weeks that includes at least one event, so you see how the tool behaves around spikes and the dip after.
- Share history only up to the cut-off. No promotion results, no actuals from inside the window. Leakage is the most common way backtests flatter a tool.
- Forecast on a rolling origin: each week, forecast the next lead-time window using only data available that week, at your decision granularity.
- State what counts as actual: ordered quantity, sell-through or both, and use the same definition for every vendor.
- Compare against naive baselines such as a trailing moving average, computed by you on the same weeks.
- Report by segment: top SKUs, long tail, new SKUs, event weeks and each platform. An average across everything hides where the tool fails.
| Metric | How to compute | What it tells you |
|---|---|---|
| WAPE | Sum of |actual - forecast| ÷ sum of actual | Overall error, weighted toward the SKUs that sell most |
| Bias | Sum of (forecast - actual) ÷ sum of actual | Whether the tool habitually over- or under-forecasts |
| Error vs naive baseline | Tool WAPE compared with a trailing-average WAPE on the same weeks | Whether the tool adds anything over simple maths |
| Simulated stockout and excess | Replay the recommended stock against actual demand | What the forecast would have done to availability and inventory |
Red Flags to Watch for in Demos
- Accuracy percentages from other customers, or "up to X% accuracy" with no definition of the metric, granularity or period.
- A backtest on hand-picked SKUs, monthly totals or national level, when your decisions are weekly by city.
- The model trains on shipped or invoiced quantity and has no idea when you cut POs or ran out.
- "Dark-store-level forecasts" from a vendor who cannot list the store-level fields it will receive from each platform.
- No way to enter events or promotions beyond a generic seasonality setting.
- Recommendations in fractional units, or that ignore crate MOQ and shelf life.
- Acting on the forecast means exporting to Excel and building the PO by hand.
- Planners cannot see drivers or record overrides with a reason.
Questions to Ask Every Vendor
- At what granularity will you forecast for each platform, and which data fields do you need at that grain?
- Which reports from each platform can you ingest, in what format and how often, and who loads them?
- How do you treat weeks when we cut POs or were out of stock?
- How do shelf life and minimum remaining shelf life at receiving enter the recommendation?
- How do you round to case size, crate MOQ and supplier MOQ?
- What event and promotion inputs do you need from us, and how far ahead?
- How do you forecast a new SKU or a new city with no history?
- Will you run a blind, rolling backtest on our data before we sign, against a naive baseline, reported by segment?
- What does a planner see when they disagree with a number, and are overrides tracked?
- How does the forecast become a supplier PO or transfer, and in which system?
- What is the pricing basis: SKUs, locations, users or modules?
Want the Forecast to Become the PO?
See replenishment recommendations built from your shipment history and stock position, rounded to case size and turned into supplier POs in the same system.
Where FilFlo Fits
FilFlo is the order-to-cash operations layer for FMCG brands selling through quick commerce, with forecasting and replenishment as secondary capabilities built on that order data. It is not a dedicated statistical forecasting platform. What it ships, as described in the seasonal planning guide linked above: an LTMA baseline (the last-three-month average of primary shipments per distribution point) in a Retail Forecast workbench that sets shipments against imported secondary sales and opening stock; consumption-based Procurement Alerts that show days of cover and a suggested quantity rounded to case size; and a lead-time safety floor that counts stock in transit.
Its advantage on this checklist is the data underneath. Because platform POs are approved in FilFlo with SKU-level cuts and reasons, and GRNs are captured against the same order, the history separates what was ordered from what was approved, shipped and received. Fill-rate scorecards track each line from ordered to GRN with a named loss reason. That is the uncensored demand record most forecasting tools ask you to supply.
Not the right fit if: you need probabilistic, store-level forecasting across thousands of dark stores. FilFlo works with the purchase orders platforms raise on your brand and has no visibility into consumer orders or dark-store demand inside the platforms. A specialist planning tool fits that job better, and can sit on top of FilFlo's order data. Pricing is quote-based.
Frequently Asked Questions
What granularity should a quick commerce demand forecast use?
At least SKU × platform × city or platform warehouse, because that is the level at which platforms raise purchase orders on brands. Go finer, to the dark store, only where the platform actually shares store-level sell-through with you and you can act on it. Then roll the forecast up to SKU × your own warehouse to drive supplier POs and transfers.
Can a brand forecast demand at the dark-store level?
Only with dark-store data. In the common inventory-led model, the platform replenishes its dark stores from its own warehouses, and what the brand sees is the platform’s PO plus whatever sales or inventory reports the platform shares. Platforms differ in what they share, at what granularity and how often. Before you pay for dark-store forecasting, list the fields you receive at store level for each platform.
How do I compare forecast accuracy fairly across vendors?
Run the same blind, rolling backtest for every vendor on your own history: give them data up to a cut-off date, ask for forecasts at your decision granularity for the following weeks, and compare WAPE and bias against a naive baseline such as a trailing moving average. Break results down by segment (top SKUs, long tail, new SKUs, event weeks). Ignore accuracy figures quoted from other customers.
Why does our PO history understate real demand?
Because it is censored. When you cut a PO for lack of stock, or a SKU was unavailable on the platform, the recorded quantity reflects what you could supply, not what shoppers wanted. A good tool trains on ordered quantity and flags cut and stockout periods, which requires that your cuts were recorded with reasons in the first place.
How should shelf life and crate MOQ change a replenishment recommendation?
Shelf life caps how much you can send: stock has to meet the platform’s minimum remaining shelf life at receiving and still sell before it expires. Crate and case MOQs set the step size: recommendations must round to whole crates or cases. A tool that ignores either produces numbers your warehouse cannot ship or the platform will reject.
Do we need an AI forecasting tool, or will a spreadsheet do?
Start with a transparent baseline: a trailing average per SKU and location, days of cover, lead-time safety stock and MOQ rounding. Buy a dedicated tool when the number of SKU and city combinations outgrows the spreadsheet, or when a vendor beats your baseline in a blind backtest on your own data. Better maths on bad data loses to simple maths on clean data.
Start From Clean Demand History
Bring a month of platform POs and GRNs, and we will show you ordered vs approved vs received by SKU and delivery location, the input every forecast depends on.