SaaS pricing research: test the package buyers will actually pay for

A SaaS pricing page can make a package look inexpensive until the buyer counts the people who need access and the work they need to put through it. A higher tier can look excessive until the team calculates the cost of staying on the lower one.

That is why “Would you pay $500 a month?” is usually an incomplete research question. The buyer needs to know what the price covers, what happens when usage grows and which capabilities make the product worth changing for. Your team also needs to know whether delivering that package would make economic sense.

Pricing research should connect those questions around a complete offer. Otherwise, a favorable reaction to the price can conceal a seat restriction, an overage surprise or a missing capability that stops the purchase.

One package decision, with two very different bills

Consider LedgerBridge, a fictional invoice-exception platform for mid-sized distributors. Finance operators use it to resolve invoices that fail automatic matching. The controller owns the budget, and IT must approve the connection to the accounting system. The company is deciding how to package a new automated export capability alongside seats and processing capacity. All prices and costs below are assumptions for that decision.

The two candidate packages have the same one-year commitment and monthly billing:

A target customer has eight editing users and processes 8,000 invoices each month. Team would cost $570, not $420: the base price plus $60 for three additional editors and $90 for 3,000 additional invoices. Operations would cost $640, putting the actual difference at $70 per month.

That changes the conversation. The customer is deciding whether the export workflow, capacity headroom and included access justify another $70 under its current usage. Asking about the $220 difference between headline prices would frame a different choice.

Before showing either package, LedgerBridge needs a credible outside option. In this case, the customer can keep its existing $350-a-month system and manage exceptions in a spreadsheet. That option also uses staff time, but the research should establish the workload rather than invent a dollar saving for it.

Learn how the account buys before asking what it would buy

The finance operator can explain the work: how exceptions arrive, how often exports happen and what goes wrong when another person needs access. The controller can explain approval thresholds, budget ownership and the financial case for switching. IT can identify whether the proposed export is feasible within the customer's systems and requirements.

Those perspectives should inform one account decision. They are not three independent purchases to average together. An operator's enthusiasm cannot establish that a controller will release the budget, and a controller's price approval cannot establish that IT will permit the deployment.

Start with current behavior. Establish the number of people who need editing access, which colleagues only view reports, normal invoice volume and the range in a busy month. Ask what they do today, what it costs and what would have to happen for them to reconsider it. Separate existing customers considering an upgrade from new buyers considering a switch; their alternatives and transition costs differ.

For LedgerBridge, “eight users” is not enough detail. If three are auditors who only read the output, Team's access charge changes. If invoice volume doubles during seasonal peaks, a monthly allowance that looks generous on average can become unpredictable at the moment the finance team is busiest.

Test the bill as well as the benefit

Show the complete terms, then ask the buyer to explain the offer back in their own words. Can they calculate the charge at their normal volume? What do they believe happens when they cross the allowance? Who do they think needs a paid editing seat?

This is a comprehension check before it is a preference test. A buyer who chooses Operations because they think Team blocks all use above 5,000 invoices has misunderstood the proposed offer. The next action is to clarify the terms and test again, rather than count that response as evidence for the higher tier.

Also test a busy-month scenario. Tell the respondent what changes in users or invoices and let them work through the bill. Ask whether the additional charge is acceptable, whether they could predict it and what control they would expect before incurring it. A spending alert, approval threshold or hard limit can change the practical appeal of usage pricing.

Stripe's pricing-model documentation distinguishes flat-rate, per-seat, tiered and usage-based structures, including base fees with overage. Those are billing possibilities, not evidence that customers prefer one. Choose a unit buyers understand and that your billing system can measure consistently.

Use trade-off research when several terms move together

A comparison of LedgerBridge's two cards can help identify which complete offer deserves further testing. It cannot tell the team how much of the preference comes from the seats, allowance, price or automated export, because those terms change together.

If the business needs to separate their effects, choice-based conjoint can present a designed series of feasible packages that vary those attributes. The resulting model estimates relative preferences within the tested design. Our conjoint guide explains how attributes, levels and complete alternatives fit together.

The study should preserve the real option to stay with the current system. Sawtooth's CBC documentation explains how an opt-out can represent a status quo. For LedgerBridge, “Keep the current system and spreadsheet process” is more meaningful than forcing someone to select the less objectionable new tier.

Use realistic prices and configurations, with enough variation to estimate the intended trade-offs. Avoid impossible bundles or an attractive feature that only appears in the cheapest package. Have the design reviewed before fielding, and check whether the fitted model handles tasks withheld from estimation. A polished simulator cannot repair a study whose design confounds the decisions you hoped to separate.

Be careful with the phrase “willingness to pay.” An implied feature premium depends on the alternatives available, the price levels tested and the choice model. Sawtooth's WTP guidance warns that omitting competition and the option not to buy can inflate estimates. The question is what the buyer would choose under credible conditions, including keeping their money.

A preferred package still has to work for the business

Return to the eight-editor, 8,000-invoice account. Suppose processing costs LedgerBridge $0.012 per invoice. That is $96 per month. Assume other delivery and support costs are $110 for Team and $160 for Operations.

At the proposed bills, Team would leave $364 after these specified costs: $570 minus $96 minus $110. Operations would leave $384: $640 minus $96 minus $160. The customer's extra $70 produces an extra $20 after those assumed delivery costs, before acquisition expense, development, overhead and other costs.

That does not identify a winner. It shows why the team must inspect the economics alongside preference. Operations might make implementation easier or support broader use. It might also introduce expensive exceptions. A cheaper tier could attract accounts that are inexpensive to serve or encourage customers to stay below the intended upgrade point.

Model the usage distribution, including busy accounts, rather than relying on one average customer. Check migration from existing plans as well as acquisition. Revenue from a new tier means little if it mostly discounts customers who would have paid more under the current structure.

Conjoint outputs remain shares of preference under the modeled scenario. They do not automatically forecast market share, because awareness, competition, sales execution and other conditions affect real outcomes. Sawtooth's simulator guidance makes that distinction explicit.

Choose what deserves a commercial test

Sapien can help explore pricing, bundles and reactions across data-grounded simulated buyer groups. For LedgerBridge, that could expose misunderstandings about editing seats, compare reactions to the complete offers and identify objections worth investigating with controllers and operators. A particular conjoint design and execution path should be agreed explicitly, rather than assumed from a pricing-study label.

Take the strongest feasible package into an appropriately controlled commercial test. Track the terms customers actually see, qualification, acceptance, rejection reasons, paid usage, overages and support cost. Observe whether the people who liked the package can secure approval and continue using it at the promised price.

The package is ready to advance when buyers understand the bill, the relevant account roles can accept the offer and the economics survive credible usage. Research should make those conditions clearer before the pricing page makes the promise.