Raise prices with data, not with your gut

Data-driven pricing means deciding what you charge based on what your sales already tell you, not on what the Thursday committee thinks. It sounds obvious and almost nobody does it: in most mid-sized companies the price comes from cost plus an inherited margin, from whatever the competitor down the road is doing, or from the last argument with a big account. Three sources, and not one of them looks at the data.

Price is also the fastest lever there is. Moving your average price by 1% at the same volume improves operating margin far more than cutting purchasing costs by 1%, and you don't have to renegotiate with anyone. The problem is symmetric: being 1% too low, or raising prices where you shouldn't and losing the wrong customer, does exactly the same damage in reverse. That's why this gets tested, not improvised.

This guide is for general management, sales leadership and financial control in companies selling hundreds or thousands of SKUs, or services on a rate card. It isn't about magic algorithms: it's about what data you need, how to tell whether customers will absorb an increase, and how to test it without wrecking your margin.

What is pricing optimisation — and what isn't it?

Optimising prices means finding, for each combination of product, customer and channel, the price that maximises an objective you define: margin, volume, market share or customer lifetime value. Not all of them at once. That's the first decision, and it's usually still unmade.

What it is not:

• It isn't raising everything by 5%. That's a flat increase, anyone can do it in a spreadsheet, and the damage concentrates on your most sensitive products — usually the ones that bring in new customers.
• It isn't airline-style dynamic pricing. That model needs perishable inventory, highly variable demand and customers used to prices moving. If you sell industrial components to distributors on annual agreements, changing prices three times a week is a fast way to lose the account.
• It isn't a tool. There's very good pricing software out there, but if your item master is a mess and you don't know the real cost per SKU, the tool just accelerates the error.

The version that works for a mid-sized company is duller: understanding which products and which customers can absorb a higher price, which can't, and having a procedure for moving prices under control. That's pricing optimisation even if no model is involved.

What data do you need before touching a price?

Less than someone will try to sell you, but specific. If any of the first three are missing, this isn't a pricing project: it's a data project.

| Data | What it's for | Where it usually breaks | |---|---|---| | Two years of transactions with actual line-level price | Seeing what was really charged, not the list price | Discounts live in another table, or are applied at invoice foot rather than per line | | Unit cost per SKU and date | Calculating real margin, not catalogue margin | Annual average cost that hides raw material increases | | Volume by product, customer and period | Measuring what happened when prices moved | Returns and credit notes nobody subtracts | | Discounts, rebates and promotions | Knowing the net pocket price | Year-end rebates never allocated back to the product | | Market or competitor price | Setting a realistic ceiling | Only checked on the ten famous products |

The concept that uncovers the most money is net pocket price: what's left after trade discount, rebate, freight, financing, payment terms and cost to serve. Plenty of companies discover on calculating it that their largest customer is their least profitable one, and that a "star" product loses money the moment it ships express.

Eighty per cent of the value in a first pricing project usually comes from calculating real line-level margin properly. The rest is fine-tuning.

If reading that table tells you your data doesn't look like this, start there: data quality before models. No algorithm fixes a misallocated cost.

What is price elasticity, and why does almost nobody measure it correctly?

Elasticity measures how much quantity falls when you raise the price. Raise by 10% and sell 5% fewer units and elasticity is -0.5: the product holds, because you lose volume more slowly than you gain in price. Raise by 10% and sell 20% fewer and the product is elastic — that increase costs you money.

The formula is trivial. The hard part is that historical data almost never gives it to you cleanly, for three reasons:

• You never moved price on its own. You raised it in January, alongside the catalogue refresh and a competitor campaign. What you're measuring is the sum of all three.
• Reverse causality. You cut the price because sales were falling. The data says "I cut price and sold more", when reality ran the other way.
• Narrow range. If price only moved 3% in two years, you can't extrapolate what a 15% rise would do. You'd be inventing outside the observed range.

How to work on this without building an econometrics department:

1. Look for natural variation. Regions, channels or branches charging different prices for the same product. If one region charges 6% more and loses less volume, that's a real signal. 2. Group into families. With 4,000 SKUs there's never enough history per product. With 30 homogeneous families, there is. Estimate elasticity by family and apply it to members with judgement. 3. Watch purchase frequency, not just basket size. In services and subscriptions the customer doesn't buy less: they leave months later. Elasticity shows up in the cancellation, not the order. Tie this to your churn prediction.

A practical rule that avoids embarrassment: distrust any elasticity estimated from fewer than 30 observations of real price movement — and any model that won't tell you its confidence interval.

Business rules or models: which fits your case?

This is the decision that wastes the most budget. A well-built rules system covers 70% of cases in a mid-sized company. Models earn their keep when there's volume, variety and frequency.

| | Business rules | Statistical model | |---|---|---| | What it is | Written logic: minimum margins by family, bands by segment, rounding, volume tiers | Estimated elasticity and optimal price by product or family | | When it fits | Under 1,000 SKUs, annual prices, negotiated B2B sales | Thousands of SKUs, frequent changes, ecommerce, retail | | Data required | Reliable cost and customer segmentation | The above plus broad history with real price variation | | Time to live | 4-8 weeks | 3-6 months including data preparation | | Risk | Falls short, misses finer opportunities | Recommends nonsense on poor data; nobody understands why | | Who maintains it | Financial control, reviewed quarterly | Data team with continuous monitoring |

The pattern that works is putting them in series rather than choosing: the model proposes, the rules constrain. The model suggests €18.40; the rule says this segment doesn't rise more than 8% at once and margin never drops below 22%; out comes €17.90. That way the system never publishes a price management wouldn't sign off.

One thing neither of them gets to decide: your signal products. Every catalogue has five or ten SKUs whose price customers use to judge you entirely. Those are set by hand and watched, whatever the model says.

How do you test a price change without wrecking your margin?

This is where a serious project separates from a slide deck. You don't roll a new pricing policy across the whole catalogue on day one. You test it on a bounded, reversible slice.

A protocol that works in mid-sized companies:

1. Choose the scope. One product family or customer segment representing 5-15% of revenue. Enough to see signal, small enough not to hurt if it goes wrong. 2. Define the control group. Another region, another channel, or the rest of the catalogue behaving similarly. Without a control you can't separate your increase from seasonality. 3. Write down what you'll measure and when, in advance. Gross margin for the family, units, active customer count, lost order rate. Plus the abort threshold: "if units drop more than 12% for two consecutive months, we revert". 4. Let a full purchase cycle run. If your customers buy every six weeks, a two-week test says nothing. This is the most common mistake and the most expensive. 5. Check the effect on everything else. Cannibalisation is real: you raise SKU A and B takes off. If you only look at A, the test lies. 6. Decide in writing. Keep, revert or extend — with the number in front of you. And record what you learned, because that learning is the asset.

Two warnings on B2B. First: in negotiated sales there's no clean A/B test, there's a wave rollout — branch by branch, with talk tracks for the sales team. Second: tell customers on agreements before you raise. A surprise increase costs more in relationship than it gains in margin.

In ecommerce you can test more finely, but be careful about the same customer seeing two different prices: that isn't a test, it's a problem. The usual approach is testing across periods or separate markets. More context in AI for ecommerce.

Where do pricing projects go wrong?

The failures repeat so reliably you can almost list them from memory:

• Optimising without segmenting. The same product has different optimal prices depending on who buys, how much and with what service. Without customer segmentation, the recommendation is an average that suits nobody.
• Ignoring the sales team. The system proposes a price and the rep keeps discounting because their bonus depends on volume. Price isn't optimised by software: it's optimised by changing the incentive too.
• Confusing margin with profit. You raise price, percentage margin improves, volume falls and you cover fixed costs worse. The KPI that matters is total contribution margin in euros. Picking the right indicator is half the job: business KPIs.
• Forgetting cost to serve. Two customers at the same price don't leave the same behind if one orders 40 times a month in small deliveries.
• Not looking at future demand. An optimal price with the wrong stock is useless. Pricing and demand forecasting feed each other.
• Raising where it hurts the brand. Some increases are correct in the spreadsheet and a commercial mistake. Human judgement still outranks the model on signal products.

What does it cost, and how do you measure the return?

A realistic first project in a mid-sized company — real margin diagnosis, segmentation, rules and one controlled test — sits in the range of a medium-sized data project: weeks of work, not a year, and no new platform in phase one. The expensive part isn't the model: it's getting costs and discounts in order.

Measure the return like this, and agree it before you start:

• Baseline. Contribution margin for the last 12 months by family and segment. Without this there's no possible discussion six months from now.
• Isolated price effect. Margin difference between test scope and control, net of seasonality and cost changes.
• Volume and mix effect. Units lost, customers lost, shifts in what gets bought.
• Total cost. Internal hours included, not just the supplier invoice.

The full framework is in measuring AI ROI, and it applies even when there's no model involved: what you're measuring is a business decision, not a technology.

Frequently asked questions

Do I need AI to optimise prices?

Not to start. Real line-level margin, simple segmentation and written rules capture most of the value in the first few months. Models pay off when you have thousands of SKUs, frequent price changes and enough history with real variation.

How much history do I need to estimate elasticity?

Two years is reasonable to cover seasonality, and what matters isn't length but whether price actually moved during that period. With flat prices for two years there's no elasticity to estimate: you'll have to generate it through controlled tests.

Can I charge different prices to different customers?

In B2B it's the norm and it's legitimate when it reflects volume, service or payment terms, and it's documented. In B2C there are more limits, especially where the difference is based on personal data or shades into discrimination; check that with whoever owns compliance before switching it on.

How often should I review prices?

A structured quarterly review, with a deeper annual one for rate cards and agreements. If your raw material or energy costs swing hard, the trigger stops being the calendar and becomes a threshold: when cost rises above X, prices get reviewed.

Where to start

Pull real contribution margin for the last twelve months by product and customer, discounts and rebates included, and sort it high to low. That single list usually answers the three questions that matter: where you're giving product away, where you have room to raise, and which customers are absorbing the margin you thought you were earning. It's days of work, not months.

At adask we build that picture from the data already sitting in your ERP, without switching you to a new system, and we write down the rules and the test protocol before touching a single price. If you want to know what can be drawn from what you already have, request the audit; if you'd rather talk it through on a call, let's talk.