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

SaaS pricing research compares how buyers respond to complete software packages, including seats, usage, features and the resulting bill. LedgerBridge, an illustrative invoice-exception platform, must decide whether finance teams value a higher tier once they calculate the charges at their actual usage. A low headline price can lose its appeal when the buyer counts every editor and invoice.

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.

One package decision, with two very different bills

LedgerBridge serves 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.

Several roles shape the account’s purchase

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.

Comprehension changes the package comparison

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.

Trade-off research separates terms that 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.

The paid-access encounter changes what the buyer is deciding

The package card explains the bill. The paywall encounter explains why the account must decide now. If LedgerBridge interrupts an operator halfway through resolving an invoice, the reaction may concern lost work or permission to connect an accounting system rather than the $640 Operations package.

Consider a proposed evaluation version of the same product: prospects can review invoices and export a manual CSV during a 14-day evaluation; automated accounting-system export requires Operations. The eight-editor, 8,000-invoice account still sees the same $640 monthly bill, one-year commitment and complete terms. This extends the existing example with a testable access policy, not a change to either package's quoted entitlement.

A focused experiment could vary when the offer appears. One version presents the paid-access explanation when the operator requests automated export. Another allows a preview of the export configuration, then presents the same offer before any accounting-system connection or data transfer. Hold price, package, evaluation period and permitted fallback constant. Label a preview honestly so the operator doesn't believe an export has happened.

Before a live experiment, give operators the complete task and ask what is blocked, what remains available, what happens to unfinished work, when billing starts and who can authorize the next step. Ask controllers and IT about their own approval roles. An attractive screen doesn't repair a policy that puts the wrong person in charge of spending or access.

RevenueCat's experiment documentation describes randomly assigned paywall variants and following subscription outcomes beyond the initial encounter. Its examples concern subscription apps; LedgerBridge still needs an account-level design that respects shared users and its own purchasing process.

For this B2B test, choose and save a stable account assignment before the encounter, so different employees don't receive conflicting terms. Record evaluation eligibility, assigned variant, actual gate views, dismissal, return to work, approval requested, subscription accepted, payment, connection approved and first successful automated export. Keep the exact screen and entitlement-policy version with those events. A gate view is a diagnostic exposure, not the same denominator as every eligible account assigned to the test.

Define the primary conversion window and denominator in advance, such as accounts paying within 30 days of assignment divided by eligible assigned accounts. Follow those same cohorts through a declared later window, such as day 90, for continuing paid status, successful use, refunds, cancellations and support demands. Report paywall-view-to-payment as a conditional diagnostic beside the assigned-account comparison; don't use it to hide prospects who never reached the gate.

The better encounter is the one that improves a viable purchase and continued use without confusing buyers about access, billing or lost work. Vensia can help investigate modeled understanding of those terms and objections to the proposed encounter. Payment, successful export and retention still have to come from the product and commercial records.

A package advances when buyers and economics agree

Vensia 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. If you need a conjoint study, agree the design and how it will be run up front. Do not assume it comes with every pricing study.

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.

Related guides: Van Westendorp; B2B buying-group research; pricing research consulting.