Enterprise Intelligence Group
Retail demand planning software: requirements to test before selection
Evaluate retail demand planning software with requirements for forecast testing, replenishment, promotions, data, exceptions and operational acceptance.
Retail demand planning software needs to support a decision people can use, not only produce a forecast. A buying process should examine how demand evidence becomes a plan, how constraints affect action and how teams learn from execution.
Use this guide when documenting requirements, preparing demonstrations or checking whether an existing implementation supports the intended workflow. It is a working evaluation method, not a ranking of software vendors.
Define what you are buying
Forecasting estimates future demand. Demand planning combines that view with assumptions, commercial events and decisions. Replenishment translates requirements into inventory actions under operational rules and constraints. Establish which parts are in scope and where responsibility passes to another system or team.
Agree the decision level and horizon: product and store, customer and item, distribution centre, category or another relevant level. A result that looks useful in aggregate may not answer the decision a planner makes each day.
Demand evidence
Forecast
Planning decision
Replenishment action
Execution feedback
Test the handoffs as well as the forecast.
This is an illustrative evaluation sequence, not a claim every system uses this architecture.
Write requirements around a difficult operating day
Consider an illustrative promotion affected by a late supplier delivery and limited stock at some stores. Ask the vendor to show how the plan changes, which assumptions remain visible and who approves an exception. Follow the revised decision through to the ordering or allocation process.
Keep the scenario consistent across demonstrations. A scripted exception is more useful than asking each vendor to choose the situation that presents its product best.
Ask for a forecasting test, not only a convincing historical fit
Hyndman and Athanasopoulos distinguish fitting a model from evaluating genuine forecasts on observations not used in fitting it. A strong fit to known history is not sufficient evidence of future forecasting performance. Forecasting: Principles and Practice, evaluating point forecast accuracy.
For your evaluation, record the forecast date, horizon, item/location scope and information available at the time. Compare alternatives under the same conditions and retain the baseline. Separate missing evidence from a successful result.
Then follow the forecast into action. Ordering rules, pack sizes, lead times and human overrides may explain an operational problem that a different forecasting model would not resolve.
EIG’s planning review connects those tests to the workflow, responsible teams and a prioritized improvement backlog. It does not equate a better accuracy score with a guaranteed inventory or margin result.
Explore the planning performance review.
Ask for results by relevant segments as well as totals: steady sellers, intermittent demand, promoted items and new products may expose different limitations. Record where history is insufficient and where the model depends on assumptions.
Check the meaning of the inputs
Sales, orders and shipments are not interchangeable. Availability, returns, promotions, units of measure, calendars and product changes affect interpretation. Ask which records the system requires, how missing or changed inputs are handled and who approves the definitions.
For CPG teams, orders versus demand requires a separate review. For an installed retail workflow, start with these five forecasting checks.
Evaluate the planner’s workflow
Inspect how exceptions are presented, prioritized and resolved. Can the planner understand the issue, trace its inputs and record a reason for an override? What happens when two teams have different objectives or a decision falls outside approved authority?
The requirement should name the user and the expected action. “AI-powered exception management” is not an acceptance test.
Demand planning requirements worksheet
Record: requirement owner, mandatory or optional status, permitted evidence, demonstration result, gap and next action. The examples below are prompts to tailor, not universal acceptance thresholds.
| Area | Evidence to request |
|---|---|
| Decision scope | Required level, horizon, calendar and downstream planning use |
| Forecast evaluation | Out-of-sample comparison, relevant benchmark and treatment of unavailable inputs |
| Events and promotions | Assumption ownership, timing, revisions and separation of effects |
| New or changing products | Introduction, replacement, discontinuation and limited-history handling |
| Availability and history | Stockout interpretation, missing data, returns and corrections |
| Constraints | Supplier lead times, pack sizes, capacity and service requirements |
| Exceptions and overrides | Explanation, priority, accountable owner and retained decision reason |
| Integration | Input validation, output acknowledgement, failure handling and reconciliation |
| Adoption | Roles, training, operational handover and support responsibilities |
| Value realization | Baseline, review period and measures beyond forecast error alone |
Keep unresolved mandatory requirements visible even when other areas perform well. Record whether evidence came from a claim, a demonstration or an agreed operational test.
Need to structure the wider document? Use the retail and CPG business requirements example.
Separate forecast quality from delivery value
A forecast measure does not by itself establish inventory improvement or commercial return. Availability, ordering rules, supply execution and adoption can affect the outcome. Agree which operating measures will be reviewed and how the team will interpret changes alongside forecast performance.
Before rollout, define acceptance responsibilities and a post-live review. A useful handover includes the assumptions and remaining gaps, not only a successful interface test.
Turn the evaluation into an implementable decision
EIG helps document requirements, develop demonstration scenarios and connect the selection decision to data readiness, implementation and adoption. A scoped engagement can produce a requirements register, evaluation record and prioritized delivery dependencies.
Discuss vendor and technology selection
Already live but not getting the expected results? Explore forecasting and replenishment support. For programme leadership and acceptance coordination, explore implementation support.
Use the planning-data readiness checklist
Discuss a planning performance review
The EIG Library · Insights · AI Maturity Assessment · Contact