Pricing · 7 min read

Retail Price Optimization Software: What It Actually Decides

Four different products sell under one name. Base price, promotion, markdown and competitive response are separate problems with separate math, and buying the wrong one is the most common mistake in this category.

Brian Chiou Co-founder, Ward

Sep 27, 2026

See how Ward detects margin leaking through prices nobody reviewed

Get a demo → Take the 3-minute assessment

Contents

Four products, one category name
What the software is actually doing
The data question that kills projects in week one
What it is reasonable to expect
How to run the evaluation
Who has to own it

Four products, one category name

Search for retail price optimization software and you get vendors solving four different problems. They demo similarly. They cost similarly. They are not interchangeable.

Buying the wrong one of the four is the most common mistake in this category, and it usually surfaces four months in, when the merchandising team says the recommendations are not answering the question they asked.

What it decides	Horizon	The question it answers
Base price	Ongoing	What should the everyday shelf price be?
Promotion	Per event	What mechanic, at what price, with what forecast lift?
Markdown	Per season	When and how deep, to clear by a date?
Competitive response	Continuous	What do we do when they move?

Base price optimization balances margin against volume on an ongoing basis. Markdown optimization is a sell-through problem with a deadline attached. Promotion is a lift and cannibalization problem with vendor funding in it. Competitive response is a monitoring and rules problem that is only partly about elasticity.

Write down which of the four is costing you money right now before you take a single demo.

What the software is actually doing

Under every product in this category sits the same three steps.

Estimate demand response. How many units move at each price point, per item, per location group. This is the part that needs history and the part that fails quietly when the history is bad.

Apply constraints. Price ladders, family relationships, competitor commitments, vendor agreements, legal floors, round-number conventions. In practice constraints do more to shape the output than the optimization does.

Optimize against an objective. Margin, revenue, units, or some weighted blend. This is a strategy decision dressed as a configuration field, and it is usually made by whoever is in the room during implementation week.

That third step deserves more attention than it gets. "Maximize margin" with loose constraints produces prices your merchants will override within a week, and an engine that gets overridden constantly stops being used.

See how Ward detects margin leaking through prices nobody reviewed

Get a demo →

The data question that kills projects in week one

Elasticity estimation needs the price actually charged, per transaction, historically. Not the ticket price. Not the current price. The price that was rung.

A surprising number of POS extracts do not carry it recoverably. Promotional discounts get applied at basket level, or the price field holds list rather than realized, or the discount reason code was never populated. When that is true, elasticity cannot be estimated and no vendor can fix it for you.

Check this in week one. It takes an afternoon and it determines whether the project is possible.

Beyond that, the minimum list is short:

18 to 24 months of transaction-level sales with realized price
The promotional calendar for the same period, so promoted weeks can be separated from base demand
Cost by item and by date, not just current cost
Inventory positions, if markdown is in scope
Competitive prices, only if competitive response is in scope

What it is reasonable to expect

Vendor cases in this category usually claim 1 to 3 percent of margin. Treat that as a ceiling on a well-run deployment, not a forecast.

Your realistic upside depends almost entirely on where you start. Run one query before you evaluate anything: how many of your active SKUs have had a price change in the last twelve months?

If the answer is most of them, you are already pricing actively and the software is buying you precision. If the answer is a third of them, you have a large stale catalog and the first pass will find real money. That number predicts your return better than any published benchmark.

How to run the evaluation

Backtest, do not demo. Pick a category and a period you already know the outcome of. Give each vendor history ending before that period and ask what prices they would have recommended. Compare against what you actually charged and what actually sold.

Then ask three questions that separate vendors who understand retail from vendors who understand optimization.

How do you handle a new item with no history? Every catalog has them constantly. The answer should involve attribute-based analogues, and the vendor should be able to show you how the analogue is chosen.

How do you separate a stockout from low demand? If the system reads zero sales on an out-of-stock item as evidence of low demand, it will recommend a price cut on your best seller.

What does a merchant see when they disagree? The override workflow is where adoption is won or lost. A recommendation with no visible reasoning gets overridden, and a system that is always overridden gets switched off.

Who has to own it

You do not need a data science team to operate modern price optimization software. The vendors ship the demand models.

You do need two people. Someone who owns pricing strategy and can say what the system is optimizing for and what the constraints are. And a merchant who will actually review the recommendations weekly and tell you when they are wrong.

Projects in this category fail on the second one more often than the first. An engine producing good recommendations that nobody reviews is an expensive way to keep the prices you already had.

See how Ward detects margin leaking through prices nobody reviewed

Ward monitors your stores 24/7 and delivers insight cards, not dashboards. First cards in 48 hours.

Get a demo → More articles

pricing price optimization markdown margin vendor evaluation

Not sure where AI fits in your operation? Ten questions, about three minutes. Your score out of 100 appears on screen when you finish, with no email required.

Take the 3-minute assessment

Frequently asked

Questions about margin leaking through prices nobody reviewed.

It is software that recommends a price for an item at a location using demand response rather than a cost-plus rule. Underneath, it estimates how many units you sell at each price point, applies your rules and constraints, and returns the price that maximizes whatever you told it to maximize. The important word is recommends. Almost every deployment runs with a human approval step, because the constraints that matter most, like a competitor commitment or a vendor funding agreement, are rarely all encoded.

They optimize different things over different horizons. Base price optimization sets the everyday shelf price to balance margin and volume on an ongoing basis. Markdown optimization decides when and how deeply to discount inventory you have committed to clearing by a date, which is a sell-through problem with a deadline. A promotion engine is a third thing again: temporary price changes with forecast lift, cannibalization and vendor funding attached. Many vendors sell all three, and it is worth knowing which one your actual problem is before you shortlist.

Published vendor cases usually claim 1 to 3 percent of margin, and the honest answer is that it depends almost entirely on where you start. A retailer already running disciplined zone pricing with regular reviews has less to recover than one where 40 percent of the catalog has not been repriced in two years. Before you evaluate anything, measure how many of your active SKUs have had a price change in the last twelve months. That number predicts your upside better than any vendor benchmark.

At minimum: 18 to 24 months of transaction-level sales with the price actually charged, the promotional calendar for that period so promoted weeks can be separated from base demand, cost by item and date, and inventory positions. Competitive prices are needed only if competitive response is part of the strategy. The single most common blocker is that the historical price actually charged is not recoverable from the POS extract, which makes elasticity unestimable and is worth checking in week one.

To operate it, no. Modern platforms ship the demand models. What you do need is someone who owns pricing strategy and can say what the system is optimizing for, because "maximize margin" with no constraints produces prices your merchants will override within a week. The roles that decide whether this works are a pricing owner and a merchant who will review the recommendations, not a modeling team.

Go deeper on Ward