What is decision intelligence in retail planning?

Decision intelligence is the practice of delivering a specific recommendation at the point where a decision is made, rather than delivering data for someone to interpret first. A report says sell-through on a class is 42% in week four. A decision-intelligence output says which styles to reorder, at what depth, and what it assumes. The distinguishing feature is not the sophistication of the model but whether the output is a conclusion someone can act on or accept, or a fact they still have to reason from.

How is that different from planning workflow automation?

Workflow automation removes mechanical work — consolidating channel data, refreshing a forecast with the latest actuals, recalculating open-to-buy after a receipt change, distributing a weekly pack. It makes the same decisions happen faster and more consistently. Decision intelligence changes what is being decided and on what basis. They are complementary and routinely sold as one thing, but automation has a clear prerequisite relationship: automating a broken process makes it break faster.

Which should come first?

Automation, in almost every case. It is lower risk, its failures are visible, and it produces the reliable, timely data that any recommendation depends on. A recommendation engine reading a dataset that is assembled by hand every Monday inherits every inconsistency in that assembly, and inherits it invisibly — the output looks equally confident whether the input was right or not.

Why do planning teams have extensive reporting and still plan in spreadsheets?

Because a report answers what happened and a plan requires deciding what to do next, and the second is not derivable from the first without additional judgement, constraints and context the report does not carry. The spreadsheet survives because it is where that judgement gets applied — it holds the assumptions, the overrides and the reasoning. Replacing the report does not touch that; replacing the spreadsheet requires the system to accept judgement, not just display data.

What has to be true before a recommendation can be trusted?

Three things, and they are all upstream of the model. The data has to be consistent enough that the same question asked twice returns the same answer. The recommendation has to state its assumptions, so it can be disagreed with specifically rather than accepted or ignored wholesale. And there has to be a record of what was recommended versus what was done and how each turned out — without that, nobody learns whether to trust it, and trust decays to zero by default.

Does this require AI?

No. A large share of the value in both areas comes from rules, thresholds and consistent execution rather than from learned models. An exception report that reliably surfaces the twenty styles crossing a threshold this week is decision support, and it needs no machine learning. Statistical and learned methods earn their place where the pattern is genuinely too complex to express as a rule — but reaching for them first usually means automating a judgement nobody has articulated yet.

From Reporting to Decisions: What Sits Between a Dashboard and a Buy

Most planning teams have more reporting than they can act on and still make decisions from a spreadsheet. This guide separates the two things usually sold as one — automating the mechanical work, and putting a recommendation where the decision happens — and sets out which to do first and what has to be true before either works.

Two things sold as one

Ask a planning team what they need and the answer is usually some version of "better visibility". Ask what they actually do on a Monday and it is downloading three exports, pasting them into a workbook, refreshing a set of formulas, and looking at the result to decide what to reorder.

Those two sentences describe two different problems, and they get sold as one.

Planning workflow automation removes the mechanical work: the consolidation, the refresh, the recalculation, the distribution. The decisions stay exactly where they were, made by the same people on the same basis. What changes is that the inputs arrive reliably, on time, in the same shape every week, without a person assembling them.

Decision intelligence changes the output. Instead of presenting the numbers a planner reasons from, it presents a recommendation the planner accepts, adjusts or rejects — which styles to reorder and at what depth, which options to cut, where a markdown should start.

The distinction is not model sophistication. It is whether the output is a fact or a conclusion. "Sell-through on knits is 42% in week four" is a fact. "These six styles are tracking to sell out before week nine; reorder depth of roughly two weeks' cover, assuming the current rate of sale holds" is a conclusion. The second can be acted on or argued with. The first still has to be reasoned from.

Why reporting investment so often changes nothing

A pattern worth naming, because it repeats: a brand invests in reporting, gets genuinely good dashboards, and the planning team keeps working in the same spreadsheet.

This is usually read as a change-management failure. It rarely is. The spreadsheet is not surviving because people are attached to it. It is surviving because it holds things the dashboard has nowhere to put.

What lives in the workbook, in practice:

Assumptions — the growth number this plan was built on, the return rate assumed, the date the delivery is now expected.
Overrides — the six styles the buyer knows are being featured in a campaign, which no historical pattern anticipates.
Constraints — the vendor minimum that makes a recommended quantity unbuyable.
Reasoning — a comment cell explaining why last season's approach was abandoned.

A report displays what happened. A plan is a set of decisions plus the reasoning behind them, and until a system can hold the reasoning, the reasoning stays where it already is. Replacing the report never touches that, which is why the spreadsheet outlives the dashboard.

Automation first, and why the order is not arbitrary

Both directions are worth pursuing, but the sequence is not a preference. It follows from a dependency.

A recommendation is only as good as the data underneath it, and the failure mode of bad data feeding a recommendation is silent. A dashboard built on a flawed export shows a number a planner can eyeball and mistrust. A recommendation built on the same export produces a specific, confident, wrong instruction, and nothing in its presentation distinguishes it from a right one.

So the order is:

Make the inputs reliable and repeatable. Same sources, same transformations, same schedule, no hand assembly.
Make the mechanical outputs automatic. Consolidation, variance calculation, forecast refresh, distribution.
Then add recommendation on top of a foundation that can be trusted.

There is a second reason for the order, which is that automation is where the immediately recoverable time is. The consolidation work is genuinely repetitive and genuinely large, and removing it returns hours to people who currently have none — which is also what creates the capacity to evaluate recommendations properly rather than rubber-stamping them.

Automating a process nobody has articulated is how a bad process becomes a fast bad process. If the current reforecast is "whatever the planner does when they have time", automation will encode one arbitrary version of that and run it every week with an authority it has not earned. Write the process down first, in enough detail that two people would execute it the same way. If that cannot be done, that is the finding.

What a recommendation has to carry

The recurring failure of recommendation systems in planning is not that the recommendations are wrong. It is that they are unarguable, and unarguable recommendations get ignored as a category.

A planner shown "reorder 400 units" with no visible basis has two options: accept it or dismiss it. Neither builds anything. Shown "reorder 400 units — six weeks of cover at the current four-week rate of sale, assuming no markdown before week ten and the current size curve holds", they have a third and far better option: disagree with one specific assumption. The size curve is about to change because a new door opened. The rate of sale is inflated by a campaign that ended.

That third path is the whole game. It is how a planner's context enters the system instead of staying in their head, and it is how the recommendation gets better over time rather than being routed around.

Three things make it possible:

Stated assumptions, at the granularity someone can object to.
A visible basis — which data, over what window.
An easy override that is recorded as an override, not silently absorbed. The overrides are the most valuable data the system will ever collect, because they are where human context lives.

Measuring whether any of it worked

Both of these are easy to declare successful and hard to actually evaluate, so the measurement has to be set up before the change, not after.

For automation, the honest measure is elapsed time and consistency, not headcount. How long from period close to a usable plan? How often does the weekly pack arrive late or wrong? Does the same question asked twice return the same answer? These are unambiguous and hard to argue with.

For decision intelligence, the only measure that means anything is a record of recommendation, action taken, and outcome — kept from the start. Without it, adoption becomes the proxy for value, which is circular: people used it, therefore it was good. With it, real questions become answerable. Where does the system beat the planner? Where does the planner beat the system? Which categories does it handle badly?

That log is also the only defence against the failure mode where a recommendation engine is quietly overridden every week and everyone continues to believe it is running the business. If the override rate on a category is near total, the system is not being used there — and that is worth knowing early rather than discovering during a renewal conversation.

Where the judgement has to stay

Some of this work should not be automated, and being explicit about which parts is what keeps the rest credible.

The decisions that stay human are the ones where the objective is contested rather than the calculation being hard. Whether to protect margin or chase volume this season. Whether a category exists to earn its own return or to make the range make sense. Whether to take a markdown now for cash or hold for full price and risk the season. These are not analytical problems with an answer waiting to be computed — they are choices between goals, and a system that appears to resolve them has usually just buried an assumption about which goal matters.

The decisions that automate well are the ones where the objective is agreed and the work is mechanical: applying an agreed size curve, flagging every style crossing a threshold, recalculating open-to-buy after a receipt change, phasing a total across weeks using an agreed shape.

Most of the value is in the second category, which is less exciting than the first and considerably more reliable. A team that automates the mechanical layer well and keeps its judgement where judgement belongs will out-plan one that has bought something clever and still assembles its data by hand every Monday.