Global Fashion Retailer Recovers $18M in Lost Margin Through Dynamic Pricing.

A global specialty fashion retailer with 1,400 stores across thirty countries was leaving roughly three percentage points of gross margin on the table. Not because it lacked pricing sophistication — its pricing team ran weekly reviews, managed a detailed markdown calendar, and used a respected demand-forecasting tool. The problem was that these decisions operated at category level, while margin was being won and lost at the SKU level.

The challenge

The retailer's existing pricing process ran on a weekly cadence. The pricing team reviewed sell-through against plan for each category, adjusted prices in bulk, and scheduled markdowns on a seasonal calendar. It was a disciplined process — and for two decades, it had been good enough.

What had changed was the competitive environment. E-commerce competitors were repricing hourly. Smaller fast-fashion brands were testing micro-promotions continuously. Customer price sensitivity was increasingly visible at the SKU level — a specific shirt in a specific color in a specific size was overpriced or underpriced relative to demand, and the retailer was absorbing the gap as either lost margin or unsold inventory.

A 2024 internal analysis estimated the retailer was giving up somewhere between 2.5 and 4 points of gross margin annually to this mismatch. On the retailer's revenue base, that translated to $14–22M per year. The pricing director had spent two years trying to get a SKU-level dynamic-pricing capability approved. Each vendor proposal came back either too expensive, too dependent on replacing the Oracle Retail stack, or too opaque for the CFO's risk appetite.

What was different about our approach

We proposed to leave Oracle Retail as the system of record. No replacement. No migration. Prices continued to flow out of Oracle Retail into the POS and e-commerce systems exactly as before. What we added was an intelligence layer upstream of Oracle's pricing tables — a model that generated SKU-level price recommendations, routed them through the existing pricing-team workflow for review, and pushed approved prices into Oracle Retail through the same API the pricing team already used for their weekly updates.

Three things made this workable:

• The pricing team stayed in control. The AI proposed; humans disposed. Every recommendation came with its reasoning, and any price change had to be approved by a pricing analyst before it took effect. This addressed the CFO's concern about "the algorithm running the business."
• We used the existing data, not a parallel copy. Sales, inventory, customer, competitor, and promotional data all came from the existing data warehouse. We did not ask IT to build new pipelines.
• Rollout was store-cluster by store-cluster. We started with a single geographic cluster, ran it in parallel with existing pricing for eight weeks, measured the results, then expanded. No big bang.

What we built

Four model families, working together:

1. Price-elasticity models at SKU × store × customer-segment granularity. Trained on three years of transaction history. Used to estimate how demand for each specific item would respond to a price change in each specific context.
2. Competitive-reference models that ingested competitor pricing from a third-party data provider and identified where the retailer was out of line on comparable items.
3. Markdown-optimization models for end-of-season clearance — predicting the optimal price path to clear residual inventory without sacrificing margin unnecessarily early.
4. Bundle and cross-sell models to identify which promotional combinations drove the highest basket-level margin.

All four fed into a single recommendations engine that produced a ranked list of price actions each morning. The pricing team reviewed, approved, or overrode. Approved recommendations flowed into Oracle Retail by 11am local time. The whole loop ran daily instead of weekly.

Results

The margin lift was driven by a combination of factors, not a single big swing. The biggest contributor was smaller, more frequent markdowns on slow-moving items instead of large mid-season cuts — models picked up weakness earlier than the weekly review cycle did, and corrected more gently. The second biggest was the elimination of competitive-mismatch underpricing — items that customers were willing to pay more for, but that had been priced conservatively against internal cost-plus targets.

What the pricing team thinks

The system changed my team's week. Instead of running around on markdown decisions every Monday, we spend forty minutes reviewing the daily recommendations and then focus on the strategic pricing calls the model can't make — positioning on new launches, cross-category bundles, market-entry pricing. That's the work we're paid for. — VP Pricing, client retailer

Generalizable lessons

Three observations from this engagement that we see replicated across retail clients:

1. Weekly pricing is a legacy constraint, not a requirement. Most retailers run weekly pricing because their ERPs were designed when weekly was fast. Nothing about the underlying business requires it. Moving to daily — with human approval in the loop — produces measurable results almost immediately.
2. "Human in the loop" is not a compromise. The acceptance rate of 96% tells us the pricing team is mostly approving what the model recommends. The value of keeping them in the loop is in the 4% they reject or adjust — and in the institutional confidence that comes from knowing they can.
3. Margin is hiding in SKU-level granularity, not in category averages. Every retailer we've worked with has underestimated how much of their margin variance is explained by SKU-level mispricing. The signal is in the data; the tooling has finally caught up enough to extract it reliably.