The Four Data Sources Every Pricing Decision Needs

Pricing arguments inside software companies tend to be arguments about data that nobody has. Someone believes enterprise customers are underpaying. Someone else believes the mid-market plan is too expensive. Both positions are plausible, neither is checkable, and the discussion resolves on seniority rather than evidence.

The way out is unglamorous. Solutioneers pricing work builds a baseline from four sources: billing, CRM, product usage and cost data. Each one answers a question the others cannot, and each one has a specific failure mode when it is missing.

Billing data tells you what customers actually pay

Not list price. Not the price in the proposal. What landed on the invoice, including discounts, credits, overages and the negotiated terms that nobody remembered to write down centrally.

Billing data is the only honest record of your price realisation. Most companies are surprised by it the first time they look, because the gap between the published price and the average realised price is wider than anyone expected.

Without billing data you are reasoning about your price list rather than your prices. Every conclusion you reach will be about a company that does not exist.

CRM data tells you how those prices were arrived at

Billing says a customer pays a certain amount. The CRM says why: which rep, which competitor was in the deal, what the customer asked for, what was conceded and at which stage.

This is where discount patterns become visible. The CRM is also where you find out whether a discount tracked deal size, which is defensible, or tracked which salesperson ran the deal, which is not.

Without CRM data you can see that realised prices vary but you cannot see what drives the variation, so you cannot fix it. You end up changing list prices to solve a discounting problem, which does not work.

Product usage data tells you what customers value

Entitlement is not usage. Customers buy plans containing features they never open, and they lean hard on a small number of capabilities that often sit in the wrong tier.

Usage data answers the packaging questions. Which capabilities do customers adopt first. Which ones correlate with renewal. Which ones are used by one department and billed to the whole company. Which paid add-on has almost no engagement and is therefore a refund request waiting to happen.

Without usage data you will price on what you believe is valuable rather than what customers return to.

Cost data tells you what you can afford to charge

For a long time this mattered least in software, because serving one more customer cost close to nothing. That assumption no longer holds where AI and infrastructure costs scale with use.

Cost data closes the loop. It tells you whether a plan that looks healthy on revenue is actually healthy on margin, and it tells you which customers are expensive to serve rather than merely large.

Without cost data you can grow revenue and lose money doing it, and you will not see it until the gross margin line moves at the end of a quarter.

In text: 1. Billing: what customers really pay 2. CRM: how that price was reached 3. Usage: what they actually use 4. Cost: what it costs to serve

The common failure is three out of four

Most companies have three of these. The missing one is almost always cost or usage, and the missing one quietly bounds what the pricing work can conclude.

A company with billing, CRM and usage but no cost data can design good packaging and cannot tell you whether the new premium tier makes money. A company with billing, CRM and cost but no usage data can protect margin and will keep guessing about which features belong where.

The gap is not usually that the data does not exist. It exists, in four systems, owned by four teams, with no shared customer identifier. Joining it is the work.

Joining it is the expensive part

Each source uses a different key. Billing knows account IDs. The CRM knows opportunity and company records. The product knows user and workspace IDs. Cost data knows infrastructure tags and vendor invoices.

Until those resolve to one customer, every analysis is manual, every refresh is a project, and the baseline goes stale the moment it is built. This is the reason pricing reviews feel heavy and therefore happen rarely.

That connected view is what StackIQ exists to produce, and it is why the same foundation serves both pricing decisions and spend decisions.

Where to start

Pick the pricing question you most want to answer this quarter. Work backwards to the two or three sources it requires. Join those first, for a subset of customers if that is faster, and accept that the first version will be imperfect.

A partial baseline that gets refreshed beats a complete one that gets built once.

If you want to build that baseline properly, our pricing and packaging work starts there.

Related reading: Why an Annual Pricing Review Is Too Slow When You Ship Every Month and Where Discounting Quietly Leaks Revenue in Sales-Led Deals.