The Pricing Knowledge Base: Price and Promotion Optimization on Fabric

Pricing has the same problem planning does

We have argued that supply chain planning was never bottlenecked by the planning engine — it was bottlenecked by data. Pricing is the same story, and if anything the data problem is worse, because the inputs that drive a good price live in more places than almost any other business decision.

To price well, you need to know what you charge today, what you have charged in the past and what happened when you did, what your competitors are charging right now, and what you and they are running as promotions. That information exists — but it is scattered across POS systems, paid data subscriptions, spreadsheets, and the ERP. Assembling it for a single pricing decision is the same manual fire drill that plagues planning. And just like planning, the answer is not to buy a monolithic pricing engine. It is to build the knowledge base first.

What goes into the pricing knowledge base

The foundation for pricing is a specific, recognizable set of inputs. Consolidated in Microsoft Fabric, together they form a pricing knowledge base — the single, current, granular view that pricing decisions draw from.

• Competitive pricing. What competitors charge, typically sourced from paid competitive-pricing data services. This is the outside-in signal that tells you where your price sits in the market.
• Sales history. What actually sold, and at what price. For retailers this comes from POS systems; for CPG brands it comes from the retailers who carry them. This is the demand response — the record of how customers reacted to past prices.
• Current prices. What you are charging right now, as the baseline every decision compares against.
• Promotional prices. The promotions you have run and are running — the deviations from baseline whose effects you need to understand and predict.

None of these lives naturally alongside the others. Competitive data arrives from a subscription. Sales history comes out of POS or from retailer feeds. Current and promotional prices live in the ERP or a pricing sheet. The knowledge base is what happens when they finally sit together, current and reconciled, in one foundation.

The applications you build on top

Once the knowledge base exists, the hard part is done. The pricing capabilities every retailer and brand wants become applications built on top of the same foundation — not separate platforms, each demanding its own data integration.

• Promotional forecasting. With sales history, current prices, and promotional history in one place, you can forecast what a promotion will actually do — lift, cannibalization, and the return on the promotional spend — before you run it.
• Price optimization. Competitive prices, sales history, and demand response together let you find the price that best balances volume and margin, at the granularity you need, instead of pricing by gut or by blanket rule.
• Promotion optimization. Beyond forecasting a single promotion, the foundation supports optimizing the promotional calendar itself — which items, which depths, which timing deliver the best result.

Each of these is an analytical method, not magic locked inside enterprise software. What made them hard was never the math — it was assembling the pricing knowledge base to run the math against. Solve the foundation, and each becomes buildable, and tailored to how you actually price. It is the same argument we make in pricing excellence: fix the foundation before reaching for optimization.

Retail and CPG: the same base, different feeds

The pattern holds across both worlds, with the data sources shifting.

For a retailer, sales history comes directly from POS, current and promotional prices from internal systems, and competitive prices from a data service — a complete, first-party picture of the market and the customer's response to it.

For a CPG brand, the sales-history signal comes from the retailers who carry the product rather than from an owned POS, combined with competitive data and the brand's own price and promotion records. Different feed, same knowledge base, same applications on top.

Different industry, different inputs, identical architecture: foundation first, pricing applications second.

One foundation, planning and pricing alike

This is the same architecture we use for planning — and that is the deeper point. The Fabric foundation that consolidates ERP, factory, and retailer data for demand planning is the same kind of foundation that consolidates competitive, POS, and promotional data for pricing. See one foundation, many applications for the general pattern, and the supply chain data foundation for the planning side.

A company that builds the foundation for planning has already done most of the work needed for pricing, and vice versa. The sales history that feeds demand planning also feeds price optimization. The result is one governed base of data driving multiple high-value decisions — instead of a separate expensive platform bought, integrated, and maintained for each.

Why this is newly possible

Two shifts make this practical. Microsoft Fabric makes it achievable to build and maintain a genuine, governed pricing knowledge base without an enterprise-scale IT project. And AI-assisted development makes building the applications on top — the forecasting, the optimization models — far faster than it used to be. Together they change the economics: pricing capability that once meant licensing a specialized platform can now be built on a foundation you may already have.

Who this is for

This fits retailers and consumer brands that want to price and promote with more rigor than spreadsheets and gut allow, but cannot justify a dedicated enterprise pricing platform — especially those already thinking about a data foundation for planning. If you are going to unify your data anyway, pricing is one of the highest-return applications you can build on top of it.

Frequently asked questions

What data do you need to optimize pricing?

At minimum: current prices, sales history (how customers responded to past prices), competitive prices, and promotional history. Unified in one place, these form a pricing knowledge base that price and promotion optimization draw from.

Where does competitive pricing data come from?

Typically from paid competitive-pricing data services that track what other retailers and brands charge. In the foundation model, that subscription data lands in the same repository as your own sales and price history, so it is usable alongside everything else.

How is pricing data different for retail vs. CPG?

The main difference is sales history. Retailers get it directly from their POS systems; CPG brands get it from the retailers who carry their products. The rest of the knowledge base — competitive prices, current prices, promotional prices — is similar, and the applications built on top are the same.

Do I need a separate platform for pricing and for planning?

No — that is the point of the foundation model. The same kind of Fabric foundation that supports demand planning can support pricing. Build the data foundation once, and both planning and pricing become applications on top of it rather than separate platform purchases.

What can you build on a pricing knowledge base?

Promotional forecasting (predicting what a promotion will do before you run it), price optimization (finding the price that best balances volume and margin), and promotion optimization (optimizing the promotional calendar itself) — each built on the same unified data.