All posts
Fundamentals2026-06-02

Prescriptive analytics in retail: what it is, where it stops

Prescriptive analytics is the top rung of the analytics ladder: it recommends an action. In retail it stops one step short of executing the decision.

Kevin Didelot10 min read

Ask ten retail data leaders to define prescriptive analytics and you will get ten versions of the same textbook sentence: the analytics that tells you what to do. It is the top rung of the analytics maturity ladder, the one above prediction, the one every maturity slide points at as the destination. It is also the rung where the definition quietly oversells what the software does on a real shop floor.

This article does two things. It defines prescriptive analytics cleanly against the rungs below it — descriptive, diagnostic, predictive — so the term stops being a marketing fog. Then it draws the line most vendors blur: the gap between recommending an action and executing it. That gap is small in a slide and enormous in production, and it is exactly where most "prescriptive" retail projects stall.

The analytics maturity ladder: descriptive, diagnostic, predictive, prescriptive

Analytics maturity is usually drawn as a four-rung ladder, each rung answering a harder question and carrying more value — and more difficulty — than the one below.

RungQuestion it answersRetail exampleOutput
DescriptiveWhat happened?Sell-through by category last weekA dashboard
DiagnosticWhy did it happen?Why store cluster B missed planAn explanation
PredictiveWhat will happen?Demand for this SKU over the next 8 weeksA forecast
PrescriptiveWhat should we do?Mark this line down 15% in these 40 storesA recommendation

The first two rungs are the territory of business intelligence — they make the past legible. The third, predictive, is where machine learning enters: it turns history into a forward estimate. Most retailers have climbed this far. They have dashboards, they have a demand forecast, and the forecast is often good.

Prescriptive analytics is the fourth rung. It takes the forecast and layers two things on top: an objective (maximise margin, hold service level, clear seasonal stock) and a set of constraints (budget, supplier minimums, markdown calendar). From those, it computes the action that best serves the objective. Not what will happenwhat to do about it. On paper, that is the summit — in practice, one rung short of the floor.

What prescriptive analytics actually does in retail

Strip away the abstraction and prescriptive analytics in retail is an optimisation engine sitting on top of a forecast. It is genuinely useful, and the examples are concrete.

  • Markdown optimisation — given predicted price elasticity and remaining stock, recommend the discount depth and timing that clears the season at the least margin sacrifice.
  • Replenishment — given the demand forecast and safety-stock policy, recommend the order quantity per SKU per location.
  • Allocation — given a national buy and store-level demand signals, recommend how to split the units across the network.
  • Assortment — given category roles and forecast, recommend which references to keep, cut or add next season.

In each case the engine reasons over tens of thousands of SKU/store pairs at once, applies the constraints, and surfaces a ranked recommendation a human could never compute by hand. That is real leverage, and it is why prescriptive analytics earns its place at the top of the ladder. The discipline that produces these forward signals is covered in from forecasting to decision: why ML isn't enough.

So far, nothing to argue with. The problem is not what prescriptive analytics does. It is what it is quietly assumed to do next.

Where prescriptive analytics stops (and why it matters)

Here is the line the maturity ladder hides. A recommendation is not a decision, and a decision is not an executed action. Prescriptive analytics delivers the first. The other two are assumed to follow — and in most retail deployments, they don't follow on their own.

The recommendation lands on a screen. A planner reads it and agrees with some of it. They override part of it for a reason the model never saw — a supplier promise, a store refit, a buying-committee commitment. Then they re-key the survivors into the ERP, the pricing tool or the WMS by hand. By the time it reaches the floor, the elegant optimisation has passed through a manual filter that drops, by repeated field observation, well over half of it.

This is not a flaw in the math — it is the boundary of the category. Prescriptive analytics was built to compute the best action, full stop. Whether that action is committed, executed and measured is somebody else's problem — usually a human with a spreadsheet. That off-screen handoff is the same one that makes BI tools feel productive while changing nothing. The summit of the analytics ladder turns out to be a viewing platform, not a bridge.

The cost of that gap is invisible in a POC and brutal at scale. A recommendation nobody executes produces zero margin. A recommendation executed three days late, after the manual re-key and the Monday meeting, produces a fraction of its modelled value. The engine can be perfectly accurate and the outcome still mediocre. The value was never in the recommendation — it was in the executed decision, and that is precisely the rung the ladder doesn't draw.

Prescriptive analytics vs a decision layer

The category that does carry the action across that gap is a decision layer — what we elsewhere call operational AI. The cleanest way to see the difference is to extend the ladder by two rungs prescriptive analytics omits.

Prescriptive analyticsDecision layer
Top outputA recommended actionA committed, executed action
ConstraintsApplied in the optimisationEmbedded in the engine, enforced at execution
Human roleReads and arbitrates every recommendationSets guardrails, validates the sensitive cases
Where it endsAt the screenIn the ERP / WMS / pricing engine
FeedbackRe-run the model next cycleThe executed outcome sharpens the next decision
Success metricRecommendation qualityDecisions executed × their measured impact

Read the bottom two rows. A decision layer commits to the action — transfer 40 units from store A to store C by Thursday — and writes it back into the system that performs it. The result feeds back so the next decision is better.

Prescriptive analytics stops at the top row and hands the rest to a human. That is not a smaller version of the same thing; it is two additional rungs, and they are the rungs where the margin actually moves. You can see those rungs working in the markdown and transfer agents use case.

How to tell which one a vendor is selling

Both get pitched with the same word. The distinction surfaces in one question and a couple of follow-ups you can ask in any demo.

  • "After the recommendation, what happens?" If the answer is "a planner reviews and applies it", you are buying prescriptive analytics. If it is "the platform commits the action and writes it into the execution system, with a human override path", you are buying a decision layer.
  • "What does the output land as?" A chart, a ranked list, an export — versus a transfer order, a price change, a replenishment quantity, posted into the system that acts on it.
  • "What percentage of recommendations is executed unchanged today, at a live customer?" A prescriptive-analytics vendor rarely measures this, because executed-rate was never their deliverable. A decision-layer vendor should answer immediately.
  • "Where do the constraints live?" Applied once inside the optimisation, or embedded in the engine and re-enforced at the moment of execution so a stale recommendation can't ship?

None of this makes prescriptive analytics a poor purchase. If your bottleneck is genuinely computing the best action, it is the right tool. The trap is buying it believing the executed decision comes in the box — and discovering, two seasons in, that the recommendation rung was the only one you actually got.

Where this leaves you

Prescriptive analytics is a real and valuable rung — the point where analytics stops describing the world and starts proposing how to act on it. The honest framing is just to see it for what it is: the top of the analytics ladder, not the top of the decision ladder. The two extra rungs — commit and execute — sit above it, and they are the ones that touch the P&L.

That is the layer Solya is built to be. The intelligence layer holds the forecast, the objective and the business rules together. The orchestration layer commits the resulting action and writes it back into the systems that run the floor, then closes the loop on the outcome. Prescriptive analytics computes the recommendation. The decision layer is what turns it into a replenishment, a transfer or a markdown that actually happens.

The question to sit with is not "do we have prescriptive analytics?" — many retailers do. It is "of the actions our models recommend, how many are executed, unchanged, on time?" If that number is low, the missing piece isn't a better recommendation. It's the two rungs above it.


How far up the ladder does your stack actually reach?

At Solya, we offer retail data and operations leaders a 30-minute diagnostic. We map, on your own context, where your analytics stops recommending and whether anything carries the action through to execution.

You'll walk away with:

  • A read on which rung your current stack reaches — predictive, prescriptive, or executed-decision
  • An estimate of the recommendation-to-execution drop-off across your key loops
  • The first decisions worth closing the loop on, from markdown to transfer to replenishment
Kevin DidelotCo-founder & CTO, Solya

Co-founder & CTO of Solya.

Related articles