Skip to main content
DoneThat

AI Adoption GuideRetailPrice

Markdown Timing Optimizer

ML chooses markdown timing and depth for seasonal, slow-moving, or perishable inventory to maximize sell-through while protecting margin.

Retail processPlanBuyPriceStockSellFulfillReturnClear

By Don, DoneThat’s AI coach · updated

What this use case does

A markdown timing optimizer recommends when to cut price and how deep to cut for SKUs that will not clear at full price before their commercial or physical life ends. It is aimed at pricing managers who own seasonal fashion, slow-moving replenishment, and perishable or short-dated assortments, where waiting too long forces steeper clearance and cutting too early erodes margin that still had demand left in it.

The model scores remaining sell-through against stock cover, demand trajectory, and margin at risk. It outputs a proposed calendar of markdown steps (date or week, depth, and optional sequence) for human review. Pricing still owns execution: approvals, competitor exceptions, vendor constraints, and the actual price file. When stock cover or sell-through history is missing for a SKU or location, the system returns empty output for that item rather than inventing a schedule.

When to use it

Use this when the commercial problem is timing and depth of planned markdowns, not continuous reprice of healthy full-price demand. Typical triggers:

  • Seasonal packs with a fixed exit date (end of season, collection drop, event window)
  • Slow movers whose weeks of cover exceed the planned selling window
  • Perishables or short-dated goods where residual life, not fashion calendar, defines the deadline
  • Clearance and packaway decisions where early shallow cuts outperform late deep dumps

It complements, rather than replaces, Competitor Price Monitor for reactive matching, Dynamic Price Optimization for ongoing full-price or promo ladders, and Price Elasticity Estimator when you need response curves as an input. If the main question is “match a competitor today,” start with monitoring. If the main question is “how soon and how far should we mark this down to clear before the window closes,” this use case is the right frame.

Inputs and signals

Reliable recommendations need a minimum evidence base per SKU (and usually per store or fulfillment node):

  • Stock cover: on-hand (and inbound if policy includes it) relative to recent demand, so the model knows how many selling days or weeks remain at current velocity
  • Sell-through history: units and revenue over the selling window so far, plus comparable prior seasons or cohorts when available
  • Commercial constraints: exit date or residual life, floor or MAP rules, allowed markdown ladder (e.g. 20% then 40%), and whether further cuts require a second approval
  • Cost and margin: unit cost or contribution so depth recommendations can trade sell-through against margin, not only volume
  • Demand context: seasonality, promotions already planned, and channel mix if online and store clear at different rates

Without stock cover or sell-through history, do not force a guess. Empty output is the correct behavior: the pricing manager sees that the SKU is unscored and can fix data or apply a manual rule. Fabricating a calendar from incomplete history creates false confidence and trains teams to ignore the tool.

Optional enrichments improve ranking but should not replace the core signals: residual shelf life for perishables, weather or event calendars for seasonal categories, and competitor price position if you already run a monitor and want to avoid cutting below a peer without cause.

How the recommendation works

In practice the optimizer runs on a defined cadance (nightly or weekly) for a markdown-eligible universe. For each eligible SKU-location (or SKU-channel) it:

  1. Estimates remaining demand at current and candidate prices over the time left to exit
  2. Simulates one or more markdown paths (timing of first cut, step sizes, optional second and third cuts)
  3. Scores paths on sell-through by exit, expected margin or contribution, and inventory left at the end of the window
  4. Surfaces a preferred path plus alternatives when policies allow pricing to choose a more conservative or more aggressive option

Human-in-the-loop is non-negotiable. The model proposes timing and depth; the pricing manager (or an approved workflow) executes the price change. That separation keeps accountability on commercial judgment: brand positioning, key-item exceptions, vendor agreements, and one-off events the model cannot see. Batches should be reviewable as a worklist: proposed first markdown date, percent or absolute depth, expected cover after the cut, and a short rationale (e.g. cover exceeds window; velocity declining; residual life under threshold).

Empty and “hold” outcomes should be first-class. Hold means the model recommends no markdown yet because cover and sell-through still support full price. Empty means insufficient input. Conflating the two hides data quality problems.

Operating the loop as a pricing manager

Treat the optimizer as a decision support layer on the markdown calendar, not as an autopilot:

  • Eligibility: define which classes enter the model (season, slow-mover flags, near-expiry) and which stay manual (hero SKUs, regulated prices, contractual floors)
  • Review: weekly or biweekly worklists sorted by margin at risk or weeks-of-cover overage so scarce analyst time goes to the biggest exposures
  • Execution: push approved recommendations into the price management system with an audit trail of who accepted, edited, or rejected the proposal
  • Feedback: after the selling window, compare actual sell-through and margin to what the proposed path implied, then tune eligibility and ladder policies

Rejecting a recommendation should be cheap and visible. If managers routinely overwrite depths because floors or brand rules are missing from the model, fix the constraints rather than disabling the tool. If they overwrite because sell-through history is thin for newness, keep empty output for those SKUs until enough weeks exist, or use a conservative cohort default that is labeled as such and still requires human confirmation.

For perishables, shorten the cycle: same-day or next-day proposals tied to residual life and store-level cover matter more than a seasonal fashion ladder. For seasonal apparel, multi-step calendars aligned to open-to-buy and exit weeks matter more than hourly reaction.

Limits and failure modes

This use case fails when teams expect magic from thin data or when execution is disconnected from proposals.

  • Missing cover or sell-through: empty output by design; do not backfill with guesses in production scoring
  • Wrong grain: national averages that ignore store or channel cover can recommend cuts that clear online while stores still overstock, or the reverse
  • Constraint blindness: recommendations that ignore MAP, brand floors, or pack structures get rejected and erode trust
  • Confusion with continuous pricing: using markdown timing for healthy full-price SKUs trains the assortment into unnecessary discounting
  • Autopilot temptation: wiring proposals straight to live price without review shifts liability onto a model that cannot see every commercial exception

Measure success on sell-through by exit, residual inventory (units and cost), and realized margin versus a clear baseline (prior season ladder or a holdout set of similar SKUs). Avoid vanity metrics such as “number of markdowns applied.” The point is not more cuts; it is clearer timing and depth so clearance happens with less panic discounting at the end of the window.

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