Clearance Markdown Optimizer
ML sets clearance markdown depth and cadence for end-of-season or excess stock to maximize recovery value before inventory becomes obsolete.
Retail processPlanBuyPriceStockSellFulfillReturnClear
By Don, DoneThat’s AI coach · updated
What this use case covers
Clearance markdowns are one of the last levers a pricing manager has once merchandise is past its prime sell-through window. Depth and cadence matter: cut too shallow and stock ages into write-off; cut too deep too early and you leave recovery value on the table. An ML model can score remaining units against sell-through history, cost, and residual demand signals, then propose a markdown schedule. Pricing still reviews and publishes every change.
This page is for practitioners who own clearance calendars, not for assortment planning or promotional pricing earlier in the season. The goal is recovery value before obsolescence, not brand-price architecture.
Inputs the model needs
The optimizer is only as good as the stock, cost, and demand picture you feed it. Typical required inputs:
- On-hand and in-transit units by SKU, location (or fulfillment node), and size/color where those breakouts drive sell-through
- Cost basis (unit cost or landed cost) so recovery can be measured against margin floors and write-off risk
- Price history and current ticket including prior markdowns already taken
- Demand and velocity signals such as recent units sold, conversion, and comparable prior-season clearance curves for the same category or attribute cluster
- Constraints you actually enforce: minimum margin, MAP or brand rules, store-vs-digital parity, and blackout dates around events
When stock position, cost, or demand inputs are missing or stale, the system should return empty output for that SKU or location rather than invent a markdown. Empty is safer than a confident wrong cut. Ops should treat blank recommendations as a data-quality queue, not as “no action needed.”
Optional enrichments that improve proposals without becoming hard requirements: age in days since receipt or first markdown, warehouse vs store mix, and planned exit date or hard obsolescence date (season end, regulatory, or packaging change).
How the model proposes depth and cadence
The model does not publish prices. It proposes a sequence: how deep to go at each step, and how many days (or review cycles) to wait before the next step if sell-through stays below target.
In practice that looks like:
- Estimate residual demand at the current ticket and at candidate deeper tickets, conditioned on remaining weeks until the exit date.
- Score expected recovery (revenue and contribution after cost) against the risk of ending with unsold units that will be written off or sent to liquidation at worse terms.
- Respect hard constraints first; only then optimize within the feasible set.
- Emit a schedule (for example: hold, −20%, then −40% after N days if velocity is still soft) plus a short rationale tied to inventory age, velocity, and time left.
Cadence is as important as depth. A single deep cut can clear volume fast but destroy recovery if demand would have cleared at a milder ticket. A slow staircase can protect ticket but miss the exit date. The proposal should make that trade-off explicit so a pricing manager can accept, tighten, or stretch the steps.
Human-in-the-loop is non-negotiable: the model recommends; pricing validates against brand rules, competitive context, and store capacity to execute signs and tickets; then pricing publishes through the usual price management path.
How pricing managers use the recommendations
A workable operating rhythm:
- Batch by exit urgency. Prioritize SKUs or categories with the nearest obsolescence or season-end date and the highest aged units × cost exposure.
- Review exceptions, not every line. Accept proposals that sit inside policy bands; open the ones that hit floors, jump more than one step, or conflict with MAP/brand rules.
- Publish in the system of record. Ticket, POS, and site price must move together according to your channel rules. The model’s output is a proposal file or worklist, not a live price feed.
- Re-score after each cycle. Once a markdown is live, feed actual sell-through back in. If velocity beats the plan, the next step may be deferred; if it lags, the next proposed depth may come forward—still subject to publish approval.
Pair markdown decisions with adjacent clear-stage work. Transfer remaining size runs to stronger doors before deep cuts when that recovers more than local clearance (End-of-Season Transfer Optimizer). When recovery via retail markdown is worse than other exits, hand off to channel choice (Liquidation Channel Selector). Creative and PDP copy for clearance assortments can follow once depth is set (Clearance Copy and Creative Generator).
Metrics and failure modes
Track outcomes that match the job: maximize recovery before obsolete, under real constraints.
Primary metrics
- Recovery rate: clearance revenue ÷ cost (or ÷ original retail, if that is your finance standard—pick one and keep it stable)
- Weeks of supply and aged-unit burn-down against the planned exit date
- Share of clearance units sold before write-off or liquidation handoff
- Margin leakage vs policy floors (proposals that would have breached floors if auto-applied)
Process metrics
- Proposal acceptance rate and time-to-publish
- Empty-output rate by reason (missing stock, cost, or demand)—this is a data health KPI, not a model IQ score
- Override reasons (brand, competitive, capacity) so you can see whether the model or the policy library needs work
Common failure modes
- Missing inputs still scored. If the pipeline fills defaults for cost or on-hand, you get confident wrong depths. Prefer empty output and an alert.
- One-shot deep cuts without cadence. Ignores the option value of waiting a review cycle when residual demand at a milder ticket is still plausible.
- Optimizing revenue only. Ignoring cost and write-off risk pushes “successful” sell-through that still destroys contribution.
- Auto-publish. Even a strong model will miss local competitive moves, brand exceptions, and execution constraints. Pricing publishes; the model does not.
- Ignoring channel and transfer options. Markdown is not always the best clear lever; transfers and liquidation can dominate for some SKUs.
When to use this (and when not to)
Use it when you have reliable stock and cost, enough demand history or analogs to estimate clearance curves, and a defined exit window for end-of-season or excess inventory. It fits pricing managers who already run markdown calendars and need ranked, constraint-aware proposals at SKU or style-color level.
Do not use it when the problem is still assortment or initial pricing, when promotional elasticity for in-season full-price goods is the question, or when stock/cost/demand feeds are incomplete. In those cases, fix data or use planning and promo tools instead. If the better decision is move inventory or exit via liquidation rather than ticket cuts, start with transfer or channel selection, then return here for what remains on the retail path.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first