Markdown Optimization Software: Why a Uniform Cadence Burns Margin Every Season

Why the markdown calendar costs more than any other pricing decision

Week 6 of the season. The pricing team runs the standard cadence: 25 percent off anything below plan, then 40 at week 10, then 60 at week 14, then out the door to the clearance channel. The spreadsheet that drives this has one line per class and a date column. It does not know that the navy coat is selling through fine in the north and dead in the south, that the dress is only broken sizes now so the remaining units will not sell at any price a customer will pay, or that the chino is on a repeat order from a supplier who will discount cost if you hold price.

Two things go wrong at once and they cost in opposite directions. Stock that would have cleared at full price gets cut, and every point of margin given away there is pure loss. Stock that was never going to clear gets cut too late, ages into a channel that pays cents, and occupies store space and stockroom labour in the meantime. Both errors are invisible in the aggregate because they partly cancel in the reported margin number, which is exactly why they persist year after year.

Markdown is not really a pricing decision, it is an inventory exit decision with a price lever. The four facts it needs, meaning store level residual, demand decay for that product type, a hard exit date and what stores can actually execute, sit in four systems that get joined by hand once a season, too late.

Problem 1: elasticity is not a category constant

The standard cadence exists because somebody once measured that a 30 percent cut roughly doubles unit velocity in that class. That average is true and useless. Within the class, a basic replenished item responds very differently from a fashion item on its second season, a colour that never worked responds differently from one that sold out in three sizes, and a store with heavy tourist traffic responds differently from a neighbourhood store with the same demographic on paper.

Revionics, Blue Yonder and Oracle Retail Offer Optimization all estimate elasticity properly and are competent at it. That is not where they fail you. Where they fail is fit: they are enterprise suites with long onboarding, they expect a fairly clean and complete demand history in a structure that matches their model, and their recommendations arrive as numbers your merchants did not derive and will not trust. Impact Analytics is faster to stand up and more accessible on price, and it still hands you an engine whose logic you cannot inspect line by line. The predictable result is override. We have seen deployments where merchants overrode the majority of recommendations within two seasons, at which point you are paying enterprise licensing for a spreadsheet with better graphics.

What a custom build does differently is not better maths, it is inspectable maths. Estimate demand decay from your own history at the level that actually varies, usually item and store cluster, and expose the reasoning: this item, this store group, sell through at current price projects to 40 percent of remaining units by exit, a 30 percent cut projects 78 percent, and here is the sell through curve that estimate came from. A merchant who can see the curve will accept the recommendation. A merchant handed a number will not.

Problem 2: store level residual is invisible until it is too late

The chain view says 4,200 units remain against an exit date in five weeks. That number hides everything that matters. Sixty percent of it sits in eleven stores where the item never sold. Twelve stores have three units each in the wrong sizes. The four stores that could sell it at full price have none left because nobody transferred.

This is where uniform markdown does its worst damage. You cut price in the four stores that were still selling at full price, in order to clear stock sitting 300 miles away. The chain markdown budget goes up and the stock does not move, because the stock is not where the demand is.

What a custom build does: treat markdown and transfer as one decision. Before recommending a price cut, evaluate whether consolidating stock into the stores with proven rate of sale clears more units at a higher average price, net of transfer cost and the labour to pick and receive. Then support store group pricing, so the eleven dead stores go to 40 percent while the four live stores hold. Whether you can execute that depends on your price zone structure and your labelling, which is the next problem.

Problem 3: the optimiser assumes an execution capability the stores do not have

A recommendation to cut price on 340 items in 90 stores on a Wednesday means someone 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 reported a margin improvement. The shelf never got the message.

None of the optimisation vendors own this and none of them can, because it depends on your labelling technology, your store labour model and your legal position on advertised pricing. What you may claim as a was price, and how long the item must have been offered at it, varies by jurisdiction and is your counsel's call rather than your vendor's.

What a custom build does: model execution as a constraint rather than an afterthought. Cap the number of price changes per store per week. Batch changes to your existing re-ticketing day. Carry the was price and its effective dates as first class data so the ticket and the advertised claim are generated from the same record the pricing decision used. If you run electronic shelf labels in some stores and paper in others, the constraint differs by store and the optimiser should know that. This is unglamorous plumbing and it is the difference between a recommendation and a price change that actually happens.

Problem 4: broken sizes and colours make the remaining units unsellable at any price

In fashion and footwear the last 20 percent of units are mostly the ends of the curve. What is left is 2XL and XS, or size 5 and size 12. A model that treats remaining units as interchangeable will keep recommending deeper cuts on stock that has no buyer at any price, and the merchant will keep overriding it, correctly.

What a custom build does: model the size curve as part of residual. Compute a sellable proportion of remaining units from which sizes remain against the size profile that actually sells in that store, and mark the rest for exit rather than markdown. The cut then applies only to units that can move, and the broken remainder goes to the jobber on the first pass instead of after three failed markdowns.

Problem 5: grocery markdown is a shelf life problem wearing a pricing costume

If you are a grocer, none of the above is your main event. Your markdown decision is date code driven and it happens daily, in store, on chilled and bakery and produce, by a colleague with a label gun and a rule of thumb. The decision variables are hours remaining, units on hand, historical clearance rate at that store at that hour, and the waste cost if it does not sell.

Off the shelf markdown optimisation is built for seasonal apparel exit curves and does not fit this shape. The custom build here is a small daily app: scan the tray, get a recommended discount and a printed label, with the recommendation learning from what actually cleared at that store at that hour. Scope it separately and at the lower end of the range, because it is one workflow rather than a planning system.

What this costs and how long it takes

A focused first release, meaning demand decay estimation from your own history, item and store level residual with exit dates, store group markdown recommendations with inspectable reasoning, and a merchant review and approval screen, runs $80,000 to $170,000 and ships in 14 to 18 weeks. A full platform adding transfer versus markdown evaluation, size curve modelling, execution constraints and price change batching, was price and effective date handling, and post season measurement runs $200,000 to $500,000 phased over 8 to 14 months.

What pushes the number up specifically in markdown work: the number of price zones and whether store group pricing is even possible in your POS (Point of Sale), because if your POS only supports chain and zone pricing then store group recommendations are academic until that changes; multi channel, since online and store markdown interact and customers compare; and history quality, because if your sales history does not carry the price the item was actually sold at, elasticity cannot be estimated and reconstructing price history from transaction data is real work. What keeps it down: one division, one season, and the categories with the largest markdown spend rather than the most items.

Build versus buy, and when buying is the right call

Buy if you are already deep in an Oracle Retail or Blue Yonder stack, because the offer optimisation module is sitting next to your planning and pricing data and the integration cost of anything else is real. Buy if your markdown exposure is small relative to turnover, or if you clear through a fixed rate jobber arrangement where timing barely changes the recovery. Impact Analytics is worth a look before you commission anything if you want an engine quickly and your data is reasonably clean.

Build when two or more of these are true. Your merchants override most recommendations from your current engine, which means the engine has lost the argument and no upgrade fixes that. Store level residual varies enough that chain wide cuts are obviously wrong. Your assortment includes broken size curves and your current tool treats units as fungible. Your execution constraints, meaning re-ticketing labour and label technology, are the real limit on how often you can change price and no vendor model accounts for them. Or you are a grocer whose markdown is date code driven and daily, in which case off the shelf seasonal optimisation is simply the wrong product category.

The honest tipping point is trust. Markdown optimisation only creates value if the recommendations get executed, and they only get executed if merchants believe them. If your team does not trust the numbers today, buying a better engine changes nothing. Building one whose reasoning is visible changes everything.

How to choose a developer for markdown optimization software

Ask them what they will do about price history before they talk about models. If your sales records do not carry the actual selling price per transaction, elasticity estimation is impossible and reconstructing it is a project in itself. A developer who does not ask about this in the first meeting has not built one of these.

Ask how a merchant will see why a recommendation was made. If the answer is a confidence score, keep looking. You need the sell through curve, the comparable items used, and the projected outcome at each candidate price, on screen, in the review workflow.

Ask how they will model execution limits and was price handling. Advertised price and reference price rules are jurisdiction specific and your counsel owns the interpretation, but the system has to carry effective dates and prior prices so that whatever your counsel decides can actually be complied with and evidenced later.

Ask who owns the code, the trained models and the historical feature data, and put it in the contract before kickoff. At Digital Heroes the client owns all of it from the first commit. In markdown work the models are trained on your own selling history, which makes them yours in every sense that matters, and no agency should be holding them on their infrastructure.