You're building the pricing page for a B2B SaaS and every decision feels like a guess: how many plans, which billing model, where the sales button goes. Your first action is to write one sentence per plan naming the buyer it's for. If two plans get the same sentence, you have one plan too many, and you can settle that before any layout work.
Most advice on a b2b saas pricing page comes with confident numbers attached. I've removed the ones I couldn't trace to a primary source, so what follows separates what the documentation and studies say from what I'd recommend. Where it's my judgement, I say so.
How many tiers should a B2B SaaS pricing page have?
Start with three: an entry plan, the main paid plan and a contact-sales plan. Add a fourth only when your data shows a real gap between two existing plans. The research on too many options is weaker than the popular rule suggests.
The rule that six tiers push buyers into research mode is often repeated as settled. The best-known test of it is a meta-analysis by Scheibehenne, Greifeneder and Todd in the Journal of Consumer Research, covering 63 conditions from 50 experiments with 5,036 participants. It found a mean effect of virtually zero, with considerable variance between studies, and no sufficient conditions that reliably trigger choice overload (Scheibehenne et al., 2010, retrieved 30 September 2026). Those were mostly consumer choices, not SaaS plans, so I'm not claiming it proves anything about pricing pages. It does mean "never more than four tiers" isn't a law.
There is one documented ceiling, and it's a tooling one. Stripe's embeddable pricing table shows a maximum of four products, with up to three prices per product (Stripe pricing table docs, retrieved 30 September 2026). If you use it, four is your limit whatever your preference.
This is my working heuristic for what each count asks of the visitor, not measured data:
| Plans | What it asks of the visitor | When I'd use it |
|---|---|---|
| Two | Free or paid, with no middle | A single-buyer product with one clear upgrade trigger |
| Three | Pick your size | The default for an early SaaS MVP |
| Four | Pick your size, with a custom-terms option | When sales-assisted deals already exist |
| Five or more | Compare a grid | Only when each plan has a distinct buyer |
Stripe's table also lets you highlight one product, which is how most pages implement a "most popular" label. I haven't found primary evidence on whether that label changes what people choose. If you use it, mark the plan that customers really pick most, because a badge on a plan nobody buys invites a question you can't answer. Until you have plan-mix data, I'd launch without it. That's a recommendation, not a finding.
For a real data point from my own work, Callidus, the clinic SaaS I built with React, Firebase and Stripe Connect, is listed at £15 per month on the Starter plan and £50 per month on the Aesthetics plan. It adds £25 per month per extra user and a 14-day free trial, per its case study. That's two plans plus a seat add-on, so it doesn't follow the three-plan default, and I don't have conversion data to tell you whether that helped or hurt.
Which billing model should a B2B SaaS pricing page show?
Choose the billing model before the layout, because the page can't hide a model the buyer can't predict. Flat-rate and per-seat plans let buyers calculate a bill, while usage-based plans need a stated floor or cap.
Stripe's pricing-model documentation defines four patterns, and the pricing table supports three of them (Stripe pricing models, retrieved 30 September 2026):
| Model | Stripe's description | Pricing table support | My view on the page |
|---|---|---|---|
| Flat rate | Customers pick a service tier and pay a flat rate | Yes | Simplest to read, one number per plan |
| Per-seat | Each pricing unit represents one user | Yes | Buyers can calculate their own bill |
| Tiered | Unit cost changes with quantity or usage | Yes | Needs an example so the math is visible |
| Usage-based | Charges based on usage, including fixed fee and overage | No | Show the fixed fee first, then the overage rule |
The pricing-table column comes from the limitations section of Stripe's pricing table docs, which says the table supports flat-rate, per-seat, tiered and trials but doesn't support usage-based models. The last column is my judgement. If your product bills on usage, the fixed-fee-and-overage variant is the one that gives the visitor a number to start from, and metering and usage-based billing covers the build side.
Two smaller details from the same docs affect per-seat and tiered plans. The pricing table's default maximum quantity is 99, and tiered options for quantities above the maximum don't appear in the selector unless you raise it. If your plan is sold per seat and larger teams exist, check the selector shows the tier a 150-person customer would land in.
Trials have a documented catch too. The table can start a free trial without collecting a payment method, using the option to only collect payment method information if required, but Stripe's docs say to set up email reminders to collect payment details before the trial ends, because otherwise Stripe pauses the trial. A trial with no card is a pricing decision and an email decision at the same time.
I'd avoid a pure pay-as-you-go headline for a B2B buyer who has to get a budget approved. That's a recommendation, not a finding, and a developer tool with a generous free allowance may be the exception.
Where do annual pricing, feature gates and Contact Sales belong?
Show the annual option where the price is read, gate features the user only needs after their first win, and keep contact-sales visually separate from self-serve plans. These are layout recommendations, and only one has a documented constraint.
How should you display the annual discount?
Put the discount where visitors already look, which is next to the price, not behind a control they have to discover. Whether to offer annual at all is a separate question with its own trade-offs on cash and churn measurement, covered in annual versus monthly pricing for B2B SaaS. I haven't found a primary study on toggle versus callout placement, so test it on your own traffic.
What belongs on each plan card?
Show three or four differentiators per plan, written as outcomes, and push the long feature list below the cards. Stripe's pricing table supports a marketing feature list per product, such as a seat limit or a board count, so the structure is there to keep it short. That length is my preference. I haven't seen primary evidence for an exact number, and a plan with a single clear difference is easier to describe than one with fifteen checkboxes that look alike.
Which features should be gated?
Gate features that matter after the first win, such as audit logs, exports or API access, and leave adoption features such as team invites and the core workflow open. This is my reasoning, not a measured rule: a gate in front of the first successful use blocks the experience you need the buyer to have before paying. The same reasoning applies to trials, which a free trial that converts explores further.
Where does Contact Sales go?
Below or beside the self-serve plans, with its own button and framing, so it reads as a different buyer path and not a fourth price. Stripe's pricing table allows exactly one product with a custom call-to-action that redirects to any URL, which suits a contact-sales plan. The same page says its call-to-action takes customers directly to checkout, with no intermediate step such as asking them to create an account first.
What should a pricing FAQ answer?
Answer the questions that stop a purchase: changing plans, what counts toward a limit, what happens over the limit, and whether there are extra fees. Write each answer to match your real configuration, because buyers will hold you to it.
Plan changes are the clearest example. In Stripe Billing the default proration behavior creates proration items when a subscription changes, and Stripe's own example shows a customer who upgrades from a 10 USD monthly plan to a 20 USD plan halfway through the period being billed an additional 5 USD. The docs also say positive prorations aren't immediately billed unless you choose to bill them (Stripe prorations, retrieved 30 September 2026). So "you'll be charged the difference immediately" may be false in your setup. Check what your integration does before you publish that sentence.
How do you know your pricing page converts?
You know only by measuring visitors through to paid accounts, and a small site rarely has the traffic to read a pricing test quickly. Before changing any number, check whether a test is even possible.
The sample-size problem is covered in pricing page A/B testing, including what to do when you don't have the traffic. The short version is that you can still learn from structured conversations. Consider a founder who asks three people matching their ideal customer to talk through the page aloud without help. The points where they pause or ask a question are the points to fix. That's a hypothetical illustration of a method, not a result from a client.
I'd also keep the honest limits in view. I can tell you what the docs and studies above support. I can't tell you that any layout lifts conversion by a given percentage, and I'd distrust any post that does without showing its data. BookBed, my Flutter, Firebase and Stripe booking app, has subscriptions wired and tested at €9 per month for up to twenty units but not activated for paid traffic, so it has no pricing-page conversion data either. The wider billing picture is in SaaS billing and payments.
Write the one-sentence buyer for each plan now. Which two plans share the same sentence?