How to Price a B2B SaaS Product: A Decision Tree

TL;DR. To price a first B2B SaaS product, answer four questions in order: who pays, which unit of value grows as the customer gets more from the product, what buyers compare you against, and whether a person has to be involved in the sale. Those answers give you a pricing hypothesis rather than a final price. Write it down, then test it deliberately across your first ten deals and revise it based on what buyers do, not just what they say.

Why use a decision tree instead of picking a number?

A first price is a guess either way. The difference is whether you can explain the guess and learn from it. A number taken from a gut feeling gives you nothing to test. A decision tree breaks the price into separate choices, so when a deal stalls you can tell which choice was wrong.

The tree has four branches, and they work best in this order. Each answer limits the options for the next:

1. Who pays? This sets whose budget you are drawing from and what that person needs to justify the purchase.
2. Which value unit scales? This sets what you charge for.
3. How do buyers compare options? This sets the reference point your price is judged against.
4. Is sales involvement needed? This sets how the price is presented, negotiated and collected.

Who pays, and is it the same person who uses the product?

Begin with the budget, not the feature list. In B2B the person who gets value from the product is often not the person who approves the spend.

Ask:

• Which person or team signs off on the purchase?
• Which budget does the money come from: an existing tool line, headcount, a project or discretionary spend?
• What does the approver have to show internally to justify the cost?

If the user and the payer are the same person, such as a team lead paying with a company card, the price has to feel reasonable without a business case. If they are different people, the price has to hold up in a conversation the user has with someone else, so your materials need to give the user the arguments to make it.

To find out who controls the budget and what they consider reasonable, use B2B Willingness-to-Pay Interview Questions. Ask about past purchases rather than hypothetical prices.

Which value unit grows as the customer gets more value?

A value unit, often called a value metric, is the thing you charge per. Good units have three properties:

• They track value. When the customer gets more out of the product, the unit goes up.
• The buyer can predict them. A budget holder can estimate next quarter's bill.
• They are hard to game. Customers cannot easily cut usage of the unit without also losing value.

Common unit	Fits when…	Watch out for…
Per seat or user	Value comes from each person collaborating in the product	Customers sharing logins or limiting access to save money
Per usage (records, runs, transactions)	Value rises with volume processed	Bills buyers cannot predict, which makes approval harder
Per account, site or entity	Each managed unit is a clear piece of value	Wide variation in size within one unit
Flat tier	Value is similar across customers, or you lack data on the unit yet	Large customers paying the same as small ones

If you are unsure, choose the simplest unit that customers already use to describe their own scale. A flat tier with one usage limit is a legitimate first hypothesis, because it lets you watch which number really varies between customers before you commit to a meter.

How do buyers compare you against their alternatives?

Buyers rarely judge a price in isolation. They compare it with something, and you need to know what that something is. It might be:

• An existing tool category, where buyers already know what similar products cost.
• A manual process, such as spreadsheets or staff time, where your price is weighed against the effort it replaces.
• Hiring or outsourcing, where your product competes with a person or an agency.
• Doing nothing, where the price has to beat the cost of living with the problem.

The reference point changes how you frame the price. Against a tool category, you have to explain why you are different. Against a manual process or doing nothing, you have to make the cost of the problem visible. Ask interviewees what they would do if your product did not exist. Their answer is your reference point.

Do buyers need a salesperson to say yes?

This branch decides how the price is presented. If buyers can understand, trust and approve the purchase without a conversation, publish the price and let them buy. If the purchase involves several approvers, security review, procurement or custom terms, a person will need to guide it, and the price usually becomes a starting point for discussion.

Choose Self-Serve vs Sales-Assisted Purchase covers this choice in detail. For pricing, the practical consequence is this: sales involvement costs money, so a sales-assisted price has to be high enough to cover that effort. A low price with a heavy sales process rarely works.

What does a pricing hypothesis look like?

Combine the four answers into one sentence you can test:

"We charge [payer] per [value unit], framed against [reference point], sold through [purchase path], at a starting price of [amount], because [reason]."

The three scenarios below are illustrative and invented for this article. The figures show structure only and are not recommended prices.

Branch	Scenario A (illustrative): team scheduling tool	Scenario B (illustrative): invoice-processing tool	Scenario C (illustrative): compliance reporting platform
Who pays	Team lead, on a card	Finance manager, from operations budget	Department head, with procurement approval
Value unit	Per active user	Per invoice processed, in bands	Per legal entity reported on
Reference point	Existing tools in the category	Staff time spent on manual entry	Outside consultants
Sales involvement	None; self-serve	Light; a call for higher bands	Required; multi-stakeholder
Hypothesis	A flat monthly fee per user, published	Three published volume bands, the top band quoted	Annual contract per entity, quoted after scoping

Notice how each answer changes the next one. Scenario C's reference point is a consultant, so its price is framed as cheaper than an engagement, not as more expensive than software.

How should you test the price across your first ten deals?

Treat the first ten deals as an experiment with a written plan. Ten deals will not prove anything statistically, but they will show you repeated patterns.

Before the first deal

• Write the hypothesis sentence and the reason for each branch.
• Decide what result would make you raise, lower or restructure the price.
• Set a discount rule, such as one fixed design-partner discount, so you do not negotiate each deal from scratch.

During each deal, record

• Who approved the purchase and which budget it came from.
• Whether the buyer questioned the price level, the unit or the structure. These are different problems.
• What the buyer compared you against.
• Whether the deal closed, stalled or was lost, and the stated reason.

After every few deals

• Change one thing at a time, such as the level, the unit or the packaging, so you can tell what caused the effect.
• Raise the price for new prospects if deals close without any objection on price.
• Revisit the value unit if customers keep asking for a different way to measure.

Record every change and the reason for it. Product Decision Log Template works well for this. Once the hypothesis holds up, run your published page through the B2B SaaS Pricing Page Checklist.

What are the common mistakes, and when does this not apply?

Pricing on cost. Your costs set a floor, not a price. Buyers pay for the value they get.

Choosing a unit customers cannot predict. Even a well-matched usage meter can stall approval if the budget holder cannot estimate the bill.

Reading every objection as "too expensive". Objections often concern the unit or the contract terms, not the amount.

Discounting without a rule. Ad hoc discounts make your early data meaningless and set expectations you will have to honour at renewal.

Changing several things at once. You will not know which change mattered.

When this does not apply. If your product is a component sold through a partner, the partner's pricing model may constrain you more than this tree does. Regulated or public-sector purchases may follow fixed procurement rules. And if you have no buyers in conversation yet, test whether the problem is worth solving first.

What else should you know about pricing a first B2B product?

Frequently asked questions

How do I price a B2B SaaS product with no customers?

+

Form a hypothesis from four answers: who pays, which value unit scales, what buyers compare you against and whether sales is needed. Then validate it through willingness-to-pay interviews and early deals. Expect to revise it, and record why each change was made.

Should my first price be low to win early customers?

+

Not by default. A low price can attract buyers who do not value the problem and makes later increases harder. If you want to reward early customers, offer a clearly stated, time-limited design-partner discount from a published price rather than lowering the price itself.

Should I publish my price or ask buyers to contact sales?

+

Publish it when buyers can understand and approve the purchase without help. Use a quoted price when the deal needs scoping, several approvers or custom terms. Many products publish lower tiers and quote the top tier, which keeps both paths open.

How often should I change my price during early deals?

+

Review the price after every few deals rather than after each one, and change only one element at a time. This keeps your evidence readable. Hold existing customers to their agreed terms, and apply changes to new prospects so that early commitments stay credible.

Related reading

• B2B Willingness-to-Pay Interview Questions: learn who controls the budget and what they consider reasonable.
• Choose Self-Serve vs Sales-Assisted Purchase: decide how buyers will reach a yes.
• B2B SaaS Pricing Page Checklist: present the tested price clearly.
• Product Decision Log Template: record each pricing change and the reason for it.