Case Study 01Platform & Systems · Pricing Automation

Automated SKU Pricing & Mapping System

How I identified a $500K+ pricing exposure risk buried in 500+ product SKUs — and drove an end-to-end automated solution from zero.

Company

Sierra Living Concepts

Timeline

Nov 2025 – Feb 2026

My Role

Product Manager

Teams

IT · Pricing · Finance · Ops

How the cascade works

Child SKU price changes

Automated cascade engine

500+ parent set SKUs update instantly

₹35–40L

Monthly revenue protected

28→7 min

SKU mapping time reduced

500+

SKUs fully automated

The Background

Sierra Living Concepts sells premium furniture to the U.S. market — with an average order value of $3,500–$4,000. A significant portion of the catalog consists of bundled set SKUs — bedroom sets, dining sets, living room combinations — where a single parent SKU contains multiple child SKUs like a bed, two nightstands, and a dresser.

During my early weeks as a Management Trainee, while working closely with the pricing and finance teams on product launches, I noticed something that didn't add up. Set product prices on the website weren't reflecting recent changes made to individual component prices.

"The bedroom set on the website was priced at what it cost 6 months ago — but every component inside it had been repriced since then. Nobody noticed."

Discovering the Real Problem

I started digging. What I found was a four-layered problem that had been silently compounding for months:

Problem 1 — Pricing Drift: Parent set SKUs were priced manually and never updated when child SKU prices changed. Mismatches had accumulated to $600–$1,000+ per SKU.

Problem 2 — Manual Operations: Every time a set order came in, the operations team had to manually identify which child SKUs belonged to that set. Wrong variant = wrong fulfillment.

Problem 3 — No Variant Intelligence: Furniture has complex variants — fabric vs leather, queen vs king, walnut vs oak — with no way to map child variant to parent variant.

Problem 4 — Scaling Risk: With 500+ set SKUs across multiple categories, manual maintenance was not scalable. Every price update was a potential error.

Requirements Definition

I translated the four problem areas into functional requirements, prioritized by business impact and technical dependency:

Requirement	Description	Priority
Dynamic Price Cascade	Child SKU price changes auto-update all parent set SKUs immediately	High
Variant-Level Mapping	Map child SKU variants to corresponding parent set variants	High
New Set Auto-Pricing	New set SKUs auto-calculate price from child component prices	High
Mapping Interface + Validation	Internal tool with error checks preventing incorrect mappings	Medium
Last Mapping Reuse	Pre-populate new variant with last mapping data to reduce effort	Medium
Order Fulfillment Auto-ID	Set orders auto-identify correct child SKUs for ops team	Medium
Bundle Discount Logic	Support dynamic sale pricing and bundle discounts on cascade price	Low

Sprint Planning & Execution

We ran the project in four two-week sprints, coordinating between IT, pricing, and catalog teams with regular check-ins and mid-build adjustments.

🏁 Sprint 1 — Discovery & ArchitectureCompleted

Sprint Goal: Fully scope the problem, align all stakeholders on solution approach, and define the data model for parent-child SKU relationships.

As a pricing manager, I want to see which set SKUs have pricing mismatches so I can understand the full exposure

As a developer, I need a clear data model showing how parent and child SKUs relate at variant level

As a PM, I want all team leads aligned on requirements before any build begins

⚙️ Sprint 2 — Core Pricing Cascade BuildCompleted

Sprint Goal: Build and test the backend pricing cascade — when a child SKU price changes, parent set SKU prices update automatically in real time.

As a pricing team member, when I update a child SKU price, all parent sets should reflect the new price within seconds

As a catalog manager, when I create a new set SKU, the price should auto-calculate from component prices

As a finance lead, I want to validate that cascade pricing matches our manual calculation methodology

🗂️ Sprint 3 — Variant Mapping & InterfaceCompleted

Sprint Goal: Build variant-level mapping interface, add validation checks, and implement last-mapping-reuse optimization that cut mapping time from 28 to 7 min.

As a catalog manager, I want to map child SKU variants to parent set variants through a simple interface without errors

As a catalog manager, when creating a new variant, I want the system to suggest the last mapping

As a PM, I want validation checks that prevent wrong variant-to-set mappings

✅ Sprint 4 — QA, Rollout & Ops IntegrationCompleted

Sprint Goal: Full QA across all 500+ SKUs, ops fulfillment auto-identification testing, staging → production deployment, and catalog team training.

As an ops team member, when a set order arrives, I want to automatically see which child SKUs to pick

As a catalog manager, I want to complete mapping for all 500+ existing set SKUs using the new interface

As a PM, I want to verify zero pricing errors across a sample of 50 set SKUs post-deployment

The Key Mid-Build Decision

During Sprint 3, when the catalog team started using the mapping interface, I noticed it was taking 25–30 minutes per set SKU to complete variant mapping. With 500+ SKUs to map, this was going to take weeks and create a bottleneck.

The insight: Most new variant mappings were nearly identical to the last one. A walnut king bedroom set mapped almost exactly like a walnut queen bedroom set — same child SKUs, different size variant. But the tool was making the mapper start from scratch every time.

My recommendation: Build a "reuse last mapping" feature — when a catalog manager starts mapping a new variant, pre-populate it with the last mapping for that set. The IT team implemented this in 2 days. Mapping time dropped from ~28 minutes to ~7 minutes per SKU — a 75% reduction.

Per-SKU mapping time

Before — manual mapping28 min

After — last-mapping reuse7 min

75% reduction in mapping effort

Results

₹35–40L

Monthly pricing exposure protected across all set categories

↑ From ₹0 protected previously

28→7 min

Per-SKU mapping time via last-mapping reuse optimization

75% reduction in mapping effort

500+

Set SKUs fully mapped and automated across all categories

100% catalog coverage

Manual pricing updates required for existing or new set SKUs

Fully automated pricing cascade live

What I Learned

Silent problems are the most expensive.

Nobody had flagged this because the mispricing was gradual — no single change caused a visible error. Regular cross-functional reviews and pricing audits would have caught this earlier.

Mid-build observations matter as much as upfront requirements.

The last-mapping-reuse recommendation saved more time than most of the upfront requirements. Staying close to the product during build — not just at handoff — creates real value.

Automation compounds.

This system doesn't just fix today's pricing — it prevents every future pricing error across every new SKU and every price change. The ROI grows with the catalog.

Next Case Study

02 — Checkout Funnel Optimization