How to Identify Which SKUs Can Handle Price Increases Without Losing Sales

You identify which SKUs can handle a price increase by calculating price elasticity of demand for each one, then checking that number against four structural signals: substitute availability, margin cushion, purchase habit, and price salience. A SKU with elasticity near 0 and favorable signals on all four is a strong candidate. A SKU with elasticity above 1, or one that only looks safe because of a temporary confounding factor, is not.

Raising prices across the board is the blunt version of this problem. An across-the-board increase works fine on the SKUs that could absorb it and costs you volume on the ones that couldn't, and most teams can't tell the difference until the sales report shows up a quarter later. By then the damage is already in the numbers.

What Price Elasticity of Demand Actually Measures

Price elasticity of demand measures how much quantity sold changes when price changes. A SKU is inelastic, and generally a safer candidate for a price increase, when demand barely moves as price rises. An elastic SKU is the opposite: raise the price and customers walk, often toward a competitor's shelf or a private-label substitute sitting right next to it.

This is not a new idea. What's new is having the transaction volume and the tooling to calculate it SKU by SKU, across a full catalog, instead of guessing from category averages or a handful of spot checks.

The Formula, Plainly

Price elasticity = percentage change in quantity demanded ÷ percentage change in price.

• A value near 0 means demand barely reacts to price at all.
  
  
• A value of 1 means demand moves roughly proportionally with price.
  
  
• Values above 2 indicate high price sensitivity.
  
  
• Most real-world retail SKUs land between 0 and 3.5.
  
  

A number far outside that range is more often a sign of thin data than a genuinely unusual product. If a SKU's elasticity comes back at 9 or negative 4, check the sample size and the time window before you trust it.

A Worked Example

Say a SKU is priced at $10.00 and typically sells 1,000 units a week. You raise the price 10%, to $11.00, and hold everything else steady for a full comparable period. Weekly quantity settles at 920 units, a decline of 8%.

Price elasticity = -8% ÷ 10% = -0.8 (economists usually drop the negative sign and read it as 0.8 in magnitude).

That's below 1, so demand moved less than proportionally with price. Revenue on that SKU actually rose: 1,000 units at $10.00 was $10,000 a week; 920 units at $11.00 is $10,120 a week. This SKU absorbed the increase and generated more revenue doing it, which is the exact outcome you're screening for. Run the same calculation on a SKU where quantity fell 15% against the same 10% price move and the number comes back at 1.5, comfortably in elastic territory, and revenue would have dropped instead.

Why Category-Level Elasticity Misleads You at the SKU Level

A category can look moderately elastic overall while hiding SKUs at both extremes underneath it. Two SKUs in the same category, one with no close substitute, one sitting next to near-identical competitors, can behave completely differently while averaging out to the same category number.

That's the core reason a category-wide pricing decision is a blunt instrument. You need the calculation to run at the SKU level, not the rollup level, which is precisely the kind of analysis merchandising teams are increasingly expected to run without waiting weeks for a data team to build a custom report.

Four Signals Beyond the Raw Number

The elasticity number tells you what happened. It doesn't tell you why, and "why" is what determines whether last quarter's inelastic reading will still hold next quarter. Four structural signals shift how much weight to put on the raw number.

None of these four replace the formula. They explain it, and they're what let you judge whether an inelastic reading is durable or a temporary artifact of the period you measured.

The Mistake Most Teams Make

Confounding variables, a competitor stockout, a recent promotion, seasonality, can make a SKU look inelastic or elastic for reasons that have nothing to do with genuine price tolerance. Raise a price the same week a competitor runs out of stock, and the SKU looks far more price-tolerant than it actually is. The elasticity number is real, but the story behind it is temporary.

A result confirmed across multiple periods is far more trustworthy than a single clean-looking data point. If a SKU reads as inelastic in one quarter, check the same calculation against at least one other comparable period before you treat the finding as durable enough to act on.

Running This Across a Full Catalog

The math is straightforward for one SKU and genuinely difficult at the scale most retailers operate at, where a full catalog can run into the tens of thousands of active items across multiple locations. Analyzing pricing opportunities across the entire assortment rather than a sample means the SKUs worth raising prices on get found because someone asked the question of every product, not just the handful a category manager happened to flag for review.

This is where an agentic analytics platform built for operational retail data earns its keep. Instead of exporting transaction history to a spreadsheet and running the formula SKU by SKU, a team can ask the question in plain language, across the full catalog, and get elasticity readings alongside the structural signals that explain them, in one pass rather than a week of manual pulls. Lumi AI is built specifically for this kind of operational data, ERP, inventory, and sales history, rather than as a general-purpose BI tool bolted onto a dashboard.

The same logic applies within broader category management and merchandising work, where pricing decisions sit alongside assortment and placement calls that all depend on understanding how individual SKUs, not just categories, actually behave.

Turning This Into a Repeatable Process

Conditions shift, so a SKU that was safely inelastic a year ago isn't guaranteed to still be. A new competitor enters the category, a substitute product launches, or a loyal customer segment ages out and gets replaced by more price-sensitive shoppers. Treating elasticity as a once-a-year pricing project misses all of that drift until it's already cost you volume.

Building this into regular sales and customer analytics work keeps the picture current. A self-service analytics approach, where a pricing or merchandising team can re-run the elasticity check whenever they need it rather than submitting a request and waiting, is what makes the difference between catching a shift early and finding out about it in a quarterly business review.

This works best alongside a knowledge management layer where the team defines what counts as a comparable period, a meaningful price change, or an acceptable elasticity threshold for a given category, so the analysis reflects how your business actually prices, not a generic default. It also pairs naturally with SKU rationalization work: a SKU that can absorb a price increase and one that's a candidate for delisting are different findings from the same underlying transaction data, and a platform built to ask both questions saves a second data pull.

One structural signal worth checking before finalizing a price move on any SKU: whether it drives traffic to other purchases in the basket. A basket analysis can surface a SKU that looks like a safe, inelastic candidate for a price increase on paper but that also anchors a larger basket, meaning a price move on it risks more than its own line of revenue. Predictive analytics can help project how a confirmed elasticity reading is likely to hold up as conditions continue to shift.

Comparing Elasticity Profiles: A Quick Reference

FAQ

What price elasticity value makes a SKU safe for a price increase?

No universal cutoff exists, but a value close to 0 generally makes a reasonable candidate. Values above 1 need any increase weighed carefully against likely volume loss.

Can you calculate elasticity accurately without a data science team?

The formula itself is simple arithmetic: percentage change in quantity demanded divided by percentage change in price. The harder part is isolating the price effect from seasonality and promotions happening at the same time.

How often should SKU-level pricing elasticity be reviewed?

Treat it as an ongoing check, not an annual project. Conditions shift regularly enough that a once-a-year review misses changes that happened mid-year.

Does a low elasticity number always mean a price increase is safe?

Not on its own. Confirm the result across more than one period and against structural signals like substitute availability, margin cushion, purchase habit, and price salience.

Why does a category-level elasticity number matter less than a SKU-level one?

A category can look moderately elastic overall while hiding SKUs at both extremes underneath it. Two SKUs in the same category can behave completely differently while averaging out to the same category-wide figure.

What's the biggest mistake teams make when reading elasticity results?

Treating a single clean-looking data point as proof, when confounding factors like a competitor stockout or a recent promotion can make a SKU look more or less price-tolerant than it actually is.

Run This Across Your Full Catalog

The formula tells you which SKUs moved less when price changed. The structural signals tell you why. Running both together, across the full catalog instead of a sample, is where most teams get stuck, not because the math is hard, but because doing it SKU by SKU in a spreadsheet doesn't scale to a real assortment.

If your team wants to see what this looks like against your own transaction data rather than a sample, schedule a demo with Lumi AI and bring your actual pricing question. You can also review Lumi's pricing plans to see what fits your team's scale.