Markdown Optimization Software Problems: The 5 That Burn Margin Every Season, and How to Avoid Them

Why do markdown engines get overridden into uselessness?

Every markdown project starts with the model and ends with the argument. The model is the easy half. Estimating demand decay from sales history is well understood work, and Revionics, Blue Yonder and Oracle Retail Offer Optimization all do it competently. The argument is whether a merchant with fifteen years in the category accepts a number produced by something they cannot inspect, on an item they know better than the system does.

They will not, and they are often right not to. The engine does not know that the navy coat is selling through in the north and dead in the south, that the dress is down to broken sizes, or that the chino is on a repeat order from a supplier who will move on cost if you hold price. So the merchant overrides, then overrides again, and within two seasons the override rate is high enough that the recommendation is decoration.

The fix is not a better model, it is a visible one. The review screen has to show the sell through curve the estimate came from, the comparable items used, and the projected outcome at each candidate price, on the same page as the recommendation. This item, this store group, at current price projects to 40 percent of remaining units by exit date, at a 30 percent cut projects 78 percent, and here is the history behind both numbers. A merchant who can see the curve will argue with the curve, which is a productive argument. A merchant handed a number will simply ignore it.

What goes wrong with your price and sales history?

This is the question that decides whether the project is possible at all, and it should be asked before anyone scopes a model. Elasticity is estimated from what happened when prices changed, which means your sales history has to carry the price each unit actually sold at, not the current list price on the item master.

A surprising number of retailers cannot produce that cleanly. Transaction records hold a net amount after promotions applied at the basket level. Historic price changes were made in the point of sale (POS) and never written to a durable price history table. Promotional prices, clearance prices and permanent markdowns are indistinguishable in the record. Reconstructing selling price per unit per store per day from receipts is a project of its own, and it belongs on the plan as a workstream rather than as a discovery in week six.

The threshold to hold yourself to is roughly two clean seasons, or about 18 months of usable history with real price variation in it. Below that there is nothing to estimate against, and a model commissioned anyway will produce confident numbers with no basis. If your history is thin, the honest sequence is to fix the price history capture first, run a season, and build the optimiser afterwards. That is an unpopular answer and it is cheaper than the alternative.

Why do point of sale and price zone integrations break after launch?

Because the recommendation and the price change are two different systems, and the second one has constraints nobody checked. The most common discovery is late and expensive: the optimiser produces store group recommendations and the point of sale supports only chain and zone prices. Everything the model does at store granularity is academic until that changes, and changing it is a point of sale project rather than a pricing one.

The second break is the online channel. Store and ecommerce markdowns interact because customers compare, and if the two are priced by different systems on different cadences you will publish a clearance price online while the same item sits at full price in a shop twenty minutes away. Somebody has to own the rule for whether those two prices are allowed to diverge and by how much, and the answer belongs in the software rather than in a policy document.

Third, price change files fail quietly. A batch of 340 item and store changes goes out, 12 are rejected because the item is inactive at that location, and nobody sees the rejections. Insist that every price change batch produces a confirmation with counts sent, counts applied and counts rejected with reasons, visible on a screen a pricing analyst checks the morning after. Without that, the reported margin improvement is measured against price changes that never reached the shelf.

What happens when execution limits and was pricing are not covered?

A recommendation to cut price on 340 items across 90 stores on a Wednesday means somebody in every store re-tickets 340 items. If your stores use printed tags, that is hours of labour per store, and it will be done partly, late, or not at all. The optimiser will report a margin improvement it did not produce.

Model execution as a constraint rather than an afterthought. Cap price changes per store per week. Batch changes onto your existing re-ticketing day. Where you run electronic shelf labels in some stores and paper in others, the constraint differs by store and the optimiser has to know that, because a store with electronic labels can absorb a granular recommendation and a store with a label gun cannot.

The second half of this is reference pricing. What you may claim as a was price, how long the item must have been offered at it, and what appears on the ticket vary by jurisdiction, and the interpretation is your counsel's call rather than your developer's. What the software owes you is the ability to comply with whatever they decide and to evidence it afterwards: prior prices carried with effective dates as first class data, so the ticket, the advertised claim and the pricing decision all derive from the same record. Retailers who store the was price as a text field on a sign template find that out during a challenge, at which point the record does not exist.

Should you build custom or configure what you already own?

Several readers should not build. If your markdown exposure is small relative to turnover, or you clear through a jobber at a fixed rate where timing barely changes recovery, optimisation is solving a problem you do not have. If you are already deep in an Oracle Retail or Blue Yonder stack, the offer optimisation module sits next to your planning and pricing data and the integration cost of anything else is real. Impact Analytics is worth evaluating before you commission anything if your data is reasonably clean and you want an engine standing up quickly.

Build when two or more of these hold. Your merchants already override most recommendations from an existing engine, which means the engine has lost the argument and a better engine does not win it back. Store level residual varies enough that chain wide cuts are visibly wrong. Your assortment carries broken size curves and your current tool treats remaining units as interchangeable. Your re-ticketing labour and label technology are the real limit on how often price can change and no vendor model accounts for them.

Grocers are a separate case entirely. Date code driven daily markdown on chilled, bakery and produce is not seasonal exit curve optimisation wearing different clothes, it is a different product: a scanning app that recommends a discount and prints a label, learning from what actually cleared at that store at that hour. Scope it separately and at the lower end of the range.

How do hidden costs get into the quote?

Four places, in rough order of how often they surprise people.

• Price history reconstruction. If your sales records do not carry actual selling price, rebuilding it from transaction data is a workstream. A developer who does not raise this in the first meeting has not built one of these.
• Price zone and point of sale limits. Discovering in user acceptance testing that store group pricing cannot be executed turns a delivered feature into a stranded one. Confirm what your point of sale supports before scoping, not after.
• Multi channel. Adding ecommerce is not a second interface, it is a second pricing authority with its own cadence and its own rules about divergence from store price.
• Size curve modelling. Computing a sellable proportion of residual from which sizes remain against the profile that actually sells in that store is genuinely useful and genuinely more work than treating units as fungible.

In Digital Heroes delivery experience a focused first release in this category runs $80,000 to $170,000 over 14 to 18 weeks, and a full platform runs $200,000 to $500,000 phased over 8 to 14 months. What keeps a project at the lower end is scoping one division, one season, and the categories carrying the largest markdown spend rather than the largest item count.

What separates a build that works from one that fails here?

The teams that deliver working markdown software behave differently in four visible ways.

They ask about price history before they talk about models. That single question tells you whether they have done this work, because it is the constraint that decides whether the rest is possible.

They design the merchant review screen as the product rather than as a wrapper. If the answer to how a merchant sees the reasoning is a confidence score, the recommendations will be overridden and the investment will produce nothing. The sell through curve, the comparables and the projection at each price belong in the workflow, not in a documentation page.

They treat transfer and markdown as one decision. Before recommending a cut, evaluate whether consolidating stock into the stores with proven rate of sale clears more units at a higher average price net of transfer and handling cost. Cutting price chain wide to shift stock sitting 300 miles from the demand is the most expensive routine mistake in the category, and no amount of elasticity accuracy fixes it.

And they settle ownership of the code, the feature data and the trained models in writing before kickoff. Markdown models are trained entirely on your own selling history, so they encode your customers' behaviour rather than any vendor's intellectual property. An agency holding them on their own infrastructure has built a renewal lever, not delivered an asset.