Your demand-sensing model is built. Promo forecasts are validated. And your pilot launch date is three weeks away. Then a question from the supply-chain team: Where's the lead-time data for store #847?
You realise the lead times live in three systems — one per region — and none of them speak to your ERP. The POS data is clean for your newer stores but noisy for the older locations. The promo calendar is one spreadsheet per banner, updated manually, with last year's promos keyed in three different ways. The model is ready. The data is not.
This is the moment that separates retailers who ship demand sensing in months from those who stall in integration hell for a year.
The Shelf-Ready Data Problem
Demand sensing sounds simple: POS data in, forecast out. But POS is rarely one thing. It is one feed for corporate stores, a different protocol for franchisees, one format from one POS vendor in the East and a flat file from another in the West. Promo calendars are scattered — marketing has one, supply chain has another, and the POS system knows about promotions only if someone remembered to key them in. Lead times are a patchwork: direct-to-store for some SKUs, cross-dock for others, and rules of thumb for fast-moving items.
The problem is not data quality — the POS is accurate, the promo calendar is current, the lead times are real. The problem is coherence. These fragments do not share a unified date, do not map to the store-SKU-day grain that demand sensing needs, and do not know about each other.
A model trained on fragmentary data works in notebooks but breaks in production. The batch that feeds it tomorrow has a different promo calendar than the one it trained on. Or lead-time data for a new region has never been ingested. Or a recent acquisition uses a different SKU numbering scheme. Data-readiness audits happen before Transform precisely to surface this coherence gap while it is still cheap to fix — on a whiteboard and in an integration plan, rather than in a stalled pilot with a launch date already missed.
Three Pillars of Shelf-Ready Data
Demand sensing rests on three data pillars. Get all three aligned before the model touches production, and the pilot stays on schedule. Miss one, and integration becomes the bottleneck.
Pillar One: POS by Store-SKU-Day
Demand sensing needs historical POS at the store-SKU-day grain: units sold, revenue, and (critically) a flag for whether the SKU was in stock. Without the out-of-stock flag, the model cannot distinguish between "demand was low" and "we had a stockout" — and the forecast will be biased low forever.
Most retailers have this data, but coherence is the issue. Corporate stores feed one POS vendor, franchisees push data in weekly batches, acquired chains have never been merged into the main warehouse, and SKU taxonomies differ between corporate and franchises.
The audit reveals: which stores have POS history and how far back; whether data is store-SKU-day or aggregated; whether SKU codes across corporate, franchise and acquisitions map to a unified master; and whether the POS system logs out-of-stock events or requires inference from zero-unit days.
The deliverable is a POS ingestion map showing which systems feed which stores, what transformations are needed, and which stores cannot ship in the pilot because their POS data is too sparse. That last column matters most — a clear list of out-of-scope stores lets the team commit to a launch date for the ones that are in.
Pillar Two: Promo Calendars Mapped to Unified Dates
Promotions are the largest driver of demand variance. A model trained on POS without promo context will forecast low during high-spend weeks and overstock after promos end. But promo calendars are notoriously fragmented: marketing plans by banner and quarter; supply chain knows after approval; stores see them when signage arrives; and the POS key-in often records only a start date.
Different teams use different date conventions — "the big game week," "Q2 promotional period," "Feb 15–28," or ranges that change every quarter. Joining these to a daily POS feed without guesswork requires mapping.
The audit maps where promo calendars are maintained, whether they unify to calendar dates or business periods, what share of POS volume falls during flagged promos (low coverage signals missing promos), and the lag between when a promo is known and when it hits stores.
The outcome: a unified promo calendar mapped to POS dates, covering enough history to train on, and updated at the cadence marketing already works to. Without it, every promo week in the training data becomes noise the model has to explain away.
Pillar Three: Lead-Time Data, Store by Store
Lead times feed into safety stock and reorder points. If the model thinks a store's lead time is one week but it is actually three weeks, the forecast will recommend too little inventory and you will stockout. Lead times are rarely centralized: replenishment teams know their region's, logistics knows under pressure, and acquisition integrations often leave lead times in regional systems.
The audit inventories lead-time sources (master file vs. regional vs. per-store), coverage (every store-product or just high-volume SKUs), and how quickly changes propagate when distribution networks shift.
The outcome: a unified lead-time file keyed by store and product, with a documented owner and change-management process so the model does not run on stale data.
The Integration Stack: Why ERP/POS Native Matters
Once you have audited POS, promos and lead times, the next question is: where does the forecast go?
If demand-sensing predictions land in a dashboard that buyers check once a week, the model is a forecasting tool. If they are wired into the ERP and POS replenishment systems — updating safety stock, reorder points, and suggested purchase orders — the model becomes the demand signal that runs the floor. One is a proof of concept; the other is a production system.
Many retail deployments land at the "dashboard" stage because integration is hard. The model predicts, a buyer reviews, and the buyer keys it into the ERP. The loop stays open, value leaks: buyers add a subjective buffer because they do not fully trust the model yet; safety stock stays high because the old rule-based reorder point still runs in parallel; and the project becomes "a forecasting tool that buyers sometimes use" instead of "the demand signal that runs replenishment." The native ERP/POS write-back is what makes the signal sticky — and worth trusting.
The readiness audit asks: Does your ERP accept external reorder-point and safety-stock updates, or must you key them manually? Can it accept daily signals or only weekly/monthly? Can you trace a purchase order back to the forecast that triggered it?
The outcome: a hardened integration plan showing which systems will connect, in what order, and whether any ETL or middleware is needed.
Silent Failures: Drift Modes That Kill Forecasts
A demand-sensing model built on today's data becomes wrong in three silent ways.
New-product cold starts: you launch a new SKU with no POS history. The model cannot forecast. Buyers guess, safety stock is set manually, and when the SKU sells out, the project gets blamed instead of the baked-in cold-start problem.
Post-promo demand cliffs: a deep markdown ends and demand drops hard. If the model was not trained on cliffs (because promo data is incomplete), it will forecast too high, causing overstock.
Store-cluster drift: an acquisition or new store opening shifts the cluster's mix. What worked for the original cluster misforecasts for the expanded one because assortments changed.
These are not data-quality problems — they are drift modes, predictable ways the model will fail as conditions change. A readiness audit that inventories them prevents postmortem blame and stalled projects.
The audit asks: How often does your assortment turn and is there a launch calendar? Have you had deep markdowns or clears in training data? In the coming year, are you adding, closing, or remodeling stores, and does the baseline account for that?
Mitigation is baked into Assess: if new-product launches are a blind spot, the plan includes a cold-start strategy (category forecasts plus expert overrides). If promo data does not cover cliffs, the plan includes manual adjustments or a secondary model.
- 18%
- Stockout reduction with demand sensing
- 4–6 weeks
- Typical Assess duration
- ~4.2 months
- RealAI median time-to-value
Data readiness is not about having perfect data. It is about knowing where your data lives, what it means, and what work is needed to unify it before the model can ship.
Where to Start
A 4–6 week Assess phase maps the data foundation for demand sensing. The output is not a forecast — it is a data-integration roadmap.
Week 1–2: Inventory and grid. Map every data source: POS (by vendor, by store cluster), promo calendars (by owner, by format), lead-time files (by region, by system). Build a grid: which systems have which data, how current is it, and what gaps exist? Dark stores, missing lead times, incomplete promo histories will jump out immediately.
Week 2–3: Audit data quality and lineage. For each source, trace one month of data end to end: a POS unit in a store on a given day — can you join it to the promo calendar for that day? Can you join it to the lead time for that store-product? Where do joins fail? What data transformations are needed? Which stores are too sparse to forecast on?
Week 3–4: Integration planning. Map where the forecast output goes: into a dashboard only, or wired into ERP/POS replenishment? If replenishment, what changes are needed in the ERP or POS system to accept external safety-stock or reorder-point updates?
Week 4–6: Prioritization and roadmap. Rank the data-work items by effort and impact. Some items are blockers (you cannot start without clean POS). Others are accelerators (a unified promo calendar removes whole categories of noise before Transform begins). Sequence them. The output is a data-readiness score (green/yellow/red) for each category in your assortment, and a list of integration work to do before the model ships.
At the end of Assess, your team knows: which stores can be in the pilot (green: complete POS, promo, lead-time data); which stores are yellow (one or two data gaps fixable in weeks); which stores are red (missing data or integration work that would stall the pilot); and what integration work is needed to wire the forecast back into replenishment.
That clarity is what keeps the pilot on schedule. You ship demand sensing to green stores on time, start integration work on yellow stores in parallel, and defer red stores to phase two. Without it, you spend months on data wrangling and miss your launch date. The audit does not make the data work disappear — it makes it visible, sequenced, and owned, which is the whole difference between a pilot that ships and one that stalls.
“The difference between a demand-sensing deployment that ships on time and one that stalls is not the model — it's whether your POS, promo calendars and lead-time data are ready to feed it.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production — sovereign models, governed data, and agents you can audit. Start with a value-first assessment.