Dynamic Price Optimization

Dynamic price optimization recommends a sell price for each item (or item–channel combination) so pricing managers can balance demand response, competitive position, margin, and inventory cover without rebuilding a spreadsheet for every change. The model proposes a price. It does not publish it. A pricing manager (or an approved pricing workflow) still reviews the recommendation and releases it to the commerce stack.

The job is item-level, not category-level averaging. Two SKUs in the same class can need different moves when elasticity, stock cover, or competitive gaps differ. Channel constraints matter as well: a price that is legal and sensible on the website may violate MAP, franchise rules, or marketplace fee floors on another channel.

Recommendations only run when the core inputs are present and usable. If demand elasticity, stock cover, or margin inputs are missing, incomplete, or stale beyond the policy window, the use case returns empty output for that item rather than guessing.

Demand elasticity comes from historical price–volume response for the item or a carefully chosen peer set. Without a credible elasticity signal, the model cannot say whether a cut will lift units enough to protect or grow contribution, or whether a raise will shed volume that inventory or plan cannot absorb.

Stock cover (days or weeks of supply at expected demand) tells the model whether the item is overstocked, balanced, or scarce. Overstock with soft demand usually pulls recommendations down within margin floors. Tight cover with firm demand supports holding or raising price, subject to competitive and brand rules.

Margin targets include cost (or landed cost), target contribution or gross margin, and hard floors or ceilings from finance or brand policy. Without cost and margin bounds, a “revenue-maximizing” suggestion can violate profitability rules the business will not accept.

Other inputs sharpen the recommendation but do not replace the three above: competitive price position (own price versus monitored peers), channel rules (MAP, list–promo relationships, marketplace constraints), assortment role (traffic driver, margin maker, clearance candidate), and planned promotions that temporarily override base price logic.

Related reading: Price Elasticity Estimator for how elasticity is estimated, and Competitor Price Monitor for competitive position inputs.

For each eligible item, the system scores candidate prices inside the allowed band. The band is set by margin floors and ceilings, channel and brand constraints, and any temporary holds (legal, vendor, or campaign locks). Inside that band, candidates are evaluated against expected units and contribution under the elasticity curve, adjusted for stock cover and competitive gap.

A typical objective blends contribution (or margin dollars) with inventory health. When cover is high and sell-through is behind plan, the optimizer weights clearance pressure more heavily, still respecting floors. When cover is low and demand is elastic, it avoids deep cuts that would stock out early and leave margin on the table. Competitive position enters as a soft or hard constraint: some categories require staying within a set index of key competitors; others allow wider gaps if brand or exclusivity supports them.

Output for a successful run is a recommended price, the prior price, expected direction of volume and margin under stated assumptions, and the binding constraints (for example, margin floor, MAP, or max daily change). Confidence or data-quality flags help the manager decide how much review is needed. The recommendation is advice for publication, not an automatic write to the price book.

Markdown and end-of-life timing are adjacent but separate. Base-price optimization keeps regular selling prices healthy day to day. Timed promotional or clearance markdowns are handled by related logic such as Markdown Timing Optimizer, which can take the same elasticity and cover signals under a different objective and calendar.

Empty output is intentional. Pricing managers should treat a blank recommendation as “do not change from this model,” not as “hold last model price forever.” Common empty cases:

• Elasticity missing, unreliable, or not refreshed for the item (and no approved fallback peer curve).
• Stock cover missing or inventory position unknown for the selling location or channel the price applies to.
• Margin inputs missing: no cost, no target, or no enforceable floor/ceiling.
• Hard locks: legal, vendor, or campaign freezes that remove all free movement in the band.
• Channel rule conflicts that leave no feasible price (for example, MAP above a margin ceiling).

When output is empty, the operating rule is to keep the current published price (or follow the explicit hold policy) until inputs are repaired. Do not backfill with a heuristic cut or a competitor match inside this use case; those moves belong to other controlled processes if the business wants them.

Soft guardrails that still allow a recommendation include max percentage or currency change per cycle, minimum days between changes, and “do not cross” promo or list relationships. Those shrink the candidate set; they should not silently invent elasticity, cover, or margin when those fields are absent.

Human-in-the-loop is part of the control design. The model recommends; pricing still publishes. Review queues usually prioritize large recommended moves, low-confidence items, strategic or regulated categories, and items near margin floors. Routine small moves on well-instrumented SKUs can use lighter review under a written policy, still with an audit trail of who approved what and when.

Publication should write to the systems of record that own each channel’s price, with effective dates and rollback identifiers. After go-live, compare actual units, revenue, and contribution to the forecast implied by the elasticity used in the recommendation. Persistent misses often mean the elasticity estimate, competitive set, or stock signal needs refresh, not that the publisher should chase the model without fixing inputs.

Governance stays with the pricing team: approval thresholds, exception handling when empty output clusters (data pipeline issues), and clear ownership of cost and margin master data. Dynamic price optimization only stays useful while those inputs remain complete, timely, and trusted.