Personalized Pricing Pages for B2B: What to Change

Most B2B sites personalize the homepage and a few landing pages, then show every visitor the same pricing page. That is odd, because the pricing page is where a lot of evaluations either move toward a sales conversation or quietly end.

The opposite mistake is worse. Change the wrong things on a pricing page and buyers start to wonder whether they are being shown a special, higher number. This post covers B2B pricing page personalization in practical terms: which elements are safe to change by segment, which must stay identical for everyone, in what order to test them, and how to deal with the fact that most pricing pages do not get enough traffic for quick A/B tests.

Why pricing pages need stricter rules than other pages

On a blog post or a landing page, the visitor does not know or care what anyone else sees. Swapping a case study for a manufacturing visitor has no downside.

Pricing pages are shared. A buyer screenshots your plans and drops them into a Slack channel with three colleagues and a procurement contact. Review sites and comparison articles copy your prices. If two people from the same buying group see different numbers for the same plan, you now have to explain that in the first sales call, and you start the relationship on the back foot.

So the rule we use: personalize the context around the price, never the price. If you want to see how established SaaS companies structure that context today, our breakdown of SaaS pricing page examples is a good reference.

The legal side

Rules on personalized pricing are also tightening. In the EU, the Omnibus Directive requires traders selling to consumers to disclose when a price was personalised on the basis of automated decision-making (Directive (EU) 2019/2161), and the Geo-blocking Regulation restricts treating customers differently by nationality or place of residence without objective justification (Regulation (EU) 2018/302). Those rules are mostly written with consumers in mind, and B2B pricing is largely a matter of contract, but if your pricing page is public and some buyers are sole traders, you are closer to that line than you might think. This is not legal advice: ask counsel before any price varies by visitor. Negotiated discounts belong in a sales conversation and a written quote, not in a rule on the website.

What to personalize and what to keep fixed

If you genuinely need different prices for different segments, express that in packaging (a separate enterprise tier with its own scope) or in a sales-led quote. Do not let a personalization rule change a number on a public page. Besides the trust problem, it creates a support problem: your sales team needs to know which number each prospect saw.

Social proof: the safest first change

A 50-person startup looking at your plans wants evidence that companies its size use you and can afford you. A 5,000-person company wants to see that you work at scale and pass security reviews. "Trusted by 500+ companies" with a random logo strip answers neither question.

How to set it up:

1. Tag every logo and testimonial you have permission to use by industry, company size band and main use case.
2. Build one logo set per primary segment. Our post on firmographic segments that convert covers how to choose those segments.
3. Map each segment to its set in your personalization rules, with the generic set as the fallback.
4. For testimonials, pick quotes about the outcome that segment worries about: speed to value for small teams, security and scale for large ones.

Our view: this is the change to test first because it alters who the page appears to be for without touching anything about the offer. If it does not move your pricing-page-to-demo rate, the more involved changes probably will not either, and you have learned that cheaply.

If you do not have enough logos

Early-stage companies often have too few customers to build several logo sets. Personalize testimonials instead. You need a handful that speak to different concerns, for example:

• Fast setup without engineering help (small teams)
• Measurable conversion or pipeline impact (growth-focused buyers)
• Reliability, security review, SSO (enterprise evaluators)
• Support quality and responsiveness (teams burned by a previous vendor)

Show the one that matches the visitor's segment. Do not invent or paraphrase quotes to fill a gap; an empty slot is better than a fake testimonial.

Feature emphasis: reorder, never hide

Plan cards often list a long column of features, and visitors read the first few before deciding whether the plan fits. If the features a segment cares about sit near the bottom, they may never be seen.

Reordering means each segment sees its most relevant capabilities first, while the full list stays identical. A healthcare company sees data residency and compliance near the top. A SaaS company sees API access and integrations near the top.

Worked example (illustrative)

Example: a product with around 30 features across three plans and two priority segments, SaaS companies and financial services.

Same features, same plans, same prices. The only difference is what the visitor sees in the first second. Two things to check before shipping it: the comparison table further down the page should use the same order as the cards (or stay in the default order everywhere), and sales should know the order differs so they are not confused by a prospect's screenshot.

Plan recommendation: moving the "Recommended" badge

Most pricing pages highlight one tier as "Most popular" or "Recommended," usually the middle one. Moving that badge to the tier that fits the visitor's size is a small change, and defaults are known to influence choices (the classic reference is Johnson and Goldstein's work on default effects), so treat it as a real intervention, not decoration.

A simple mapping:

• Under 50 employees: highlight the entry or middle tier. These teams need to prove value before asking for more budget.
• 50 to 500 employees: highlight the middle or professional tier.
• Over 500 employees: highlight the enterprise tier, since they will need SSO, security reviews and contract terms anyway.

When not to do this: if your company-size data is unreliable (many visitors on residential or VPN connections, or a lot of traffic from agencies researching on behalf of clients), a wrong recommendation is worse than a neutral one. Only move the badge when the match confidence is high, and fall back to your normal default otherwise. Measure plan mix and downstream close rates, not just clicks, because a badge that steers people into the wrong plan raises clicks and lowers revenue.

Two details that are easy to miss. The label has to be true for each segment: if different visitors see different plans highlighted, "Most popular" is wrong for at least some of them, so use "Recommended for teams of 200+" instead. And do not hide the cheap plan from large companies; a single department inside a large company may only need the entry tier.

Enterprise visitors: grid, banner or "talk to us"

If enterprise deals always need custom pricing, showing a standard grid can anchor large buyers to a number you will never charge. If your enterprise tier is standardized, keep the grid. A middle path that works for many teams: keep the full grid for everyone, and add a banner above it for enterprise-sized visitors, such as "Teams your size usually need SSO and a custom DPA. Talk to us about the Enterprise plan." Some enterprise buyers want to self-serve early in an evaluation, and this keeps both paths open.

CTA wording by journey stage

A first-time visitor who landed on pricing from a search result is in a different place than someone who has read four feature pages and come back twice. Our guide to personalizing by buyer journey stage covers the detection logic in more depth. For the pricing page specifically:

Keep the destination consistent where you can. Changing the button text is low risk. Changing where the button goes (video vs. calendar vs. form) changes the funnel, and you need to measure it as a separate test.

FAQ sets by company size

The FAQ at the bottom of a pricing page handles objections. Different segments raise different ones:

• Small companies: Can I start small and upgrade later? Is there a minimum contract? Do I need a developer to install it? How long does setup take?
• Mid-market: Which tools does it integrate with? What support and training are included? What does switching from our current tool involve?
• Enterprise: Do you have SOC 2 or ISO 27001? Will you sign our DPA? What SLA do you offer? Which identity providers do you support for SSO?

Showing every question to everyone produces a wall of text. Build one set per company-size band and swap them with your segmentation rules. Keep a short shared set (cancellation, billing currency, taxes) visible to all.

Currency by location

Showing prices in the visitor's currency removes a mental conversion step, and it is one of the few location-based changes that belongs on a pricing page. Three conditions keep it honest:

• Only show currencies you actually invoice in. A converted estimate in a currency you do not bill in creates confusion at checkout.
• Each currency has one fixed price list, the same for every visitor who sees that currency.
• A manual switcher is always visible, and the visitor's choice persists across pages. IP location is wrong for VPN users and for buyers whose company pays in a different currency than the one their office is in.

Run currency as a separate rule from the segment rules, so a size-band variant and a currency choice never conflict. Clicks on the switcher are a useful signal: a high rate means the automatic choice is wrong for many visitors.

Testing when the pricing page has little traffic

This is where most pricing page plans fall apart, and it is worth doing the arithmetic before you start.

Worked sample-size example

Example: a pricing page with 2,000 visitors a month and a 5% pricing-page-to-demo-request rate. You want to detect a 20% relative lift (5% to 6%) at the usual settings of 95% significance and 80% power. The standard two-proportion formula (the same one behind Evan Miller's sample size calculator) gives roughly 8,000 visitors per variant, about 16,000 in total. At 2,000 visitors a month, that is around eight months for one test. Splitting the traffic into three segments makes it worse.

Now take a higher-frequency metric. If 20% of pricing page visitors click any CTA and you want to detect a lift to 24%, the same formula needs roughly 1,700 visitors per variant, about 3,400 in total, or under two months at the same traffic. You can check both scenarios with our A/B test calculator.

What that means in practice:

1. Use CTA click rate as the primary test metric (our CTR calculator works it out per segment) and demo requests as a guardrail you watch, not one you expect to reach significance on.
2. Test one change at a time across all segments together, rather than different changes per segment in parallel.
3. Bundle changes when traffic is very low. Social proof and CTA wording can ship together as one "personalized vs. default" test.
4. Keep a holdout group that sees the default page, assigned per visitor for the full test, so you can measure the combined effect after several changes have shipped.
5. Analyze identified visitors only. Unidentified visitors see the default in both arms, and including them dilutes the result toward zero.
6. Set guardrails: self-serve revenue per visitor must not fall, and refund or downgrade rates in the first 30 days must not rise.
7. Decide the test length before you start and do not stop early because the dashboard looks good on day nine.

Our conversion rate optimisation guide has more on low-traffic testing, and you can run each test as a controlled experiment with a holdout through an A/B testing setup built for segment-level reporting.

Suggested order

1. Social proof swap. Lowest risk, easy to revert.
2. CTA wording. Low risk if the destination stays the same.
3. FAQ sets. Low risk, below the fold. Watch pricing page exits.
4. Feature reordering. Medium risk, changes the first impression. Watch for sales or support questions about "missing" features.
5. Plan recommendation. Medium risk, changes which plan people consider. Measure plan mix and close rates.

Implementation walkthrough

This assumes you already have visitor identification and basic segments in place.

1. Audit the page. List every element (headline, plan names, prices, feature lists, CTAs, social proof, FAQ, content below the grid) and mark each as "context" (can be personalized) or "offer" (fixed), using the table above.
2. Choose pricing page segments. Company size is usually the most useful split here because it tracks budget, buying process and feature needs. Use employee bands that match your plans, not generic bands: if your Team plan is built for up to 50 seats, your first band ends at 50. Start with three bands. Add industry only if your use cases differ sharply by vertical.
3. Decide the data source per variable. Company size and industry come from visitor identification or your CRM for known leads; location comes from the IP country. Write down what happens when a value is missing: the visitor sees the default page.
4. Build the variants. Per segment: a logo set, one or two testimonials, a reordered top of the feature list, an FAQ set, and CTA copy per stage. Only use logos and quotes you have written permission to show; a segment with no permitted proof gets the default strip.
5. Configure rules and a strong default. Keep rules mutually exclusive and evaluated in a fixed order. Plenty of visitors will not match a segment (unknown company, residential IP, agency researcher). They see the default, so make the default good in its own right rather than leaving last year's page in place.
6. Build it so nothing jumps. The table should render with the default highlight and swap the badge without shifting layout. Never render prices client-side after a lookup; the prices should be in the HTML from the first byte.
7. QA every segment. Force each rule (a test IP, a CRM test record, a VPN for currency) and check desktop and mobile. Check that the currency switcher overrides the automatic choice.
8. Ship one layer at a time in the order above, with the test length decided up front.
9. Watch weekly: pricing page exit rate by segment, CTA click rate by segment, plan mix, and how often sales hears pricing confusion on calls.

Example segment rules (illustrative)

Example: a fictional SaaS company with three plans, Starter (up to 10 seats), Team (up to 50 seats) and Business (custom). Rules are evaluated top to bottom; the first match wins.

For a visitor from a 1,200-person company (rule 2), the page changes from Team highlighted as "Most popular", a startup logo strip, an FAQ opening with "Can I cancel anytime?" and a "Get started" button, to Business highlighted as "Recommended for teams of 200+", two logos from companies of a similar size, an FAQ opening with "How do you handle security reviews?" and "Talk to us about rollout". Every price on the page is unchanged.

What most teams get wrong

Changing prices instead of context

"Larger companies have bigger budgets, so show them higher prices" sounds clever for about a week. Buyers compare notes, review sites publish your numbers, and the first time a prospect quotes a lower price back at your rep, the conversation is about trust instead of value.

Too many variants on day one

Four company sizes times three industries is twelve variants. Nobody can write twelve good versions of a pricing page, the traffic cannot measure them, and when one segment's numbers drop you cannot tell why. Start with three variants by company size. Add more only after the first three have been measured.

Neglecting the default

Teams pour effort into variants and leave the default untouched. Since a large share of visitors will always see the default, it deserves the same care as any variant.

Measuring only the aggregate

An overall lift can hide a strong gain in one segment and a drop in another. Look at results per segment in your personalization analytics before calling a test.

What to measure beyond the pricing page

• Pricing page to demo or contact rate, per segment. The main outcome, even if it is slow to reach significance.
• Plan mix and average deal size. Plan recommendation changes should push more visitors toward the tier that fits; check that it is the right tier, not just a bigger one.
• Sales cycle length for deals that came through the personalized page vs. the holdout.
• Pricing questions on sales calls and in support, which should fall as the FAQ sets do their job.

For the broader picture of where the pricing page sits in your funnel, see our post on B2B conversion rate optimization, and the guide to personalizing by company size for how to set up the size bands this post relies on.

Where to start

Swap the social proof by company size, keep everything else as it is, and run it against a holdout with CTA click rate as the metric. It takes a day to set up. If it works, add CTA wording and FAQ sets, then feature order, then the plan badge. If it does not, you have saved yourself from building five layers of variants on a page that was not the bottleneck.

If you want to run this in Markettailor, you map segments to logo sets, FAQ sets and CTA copy in the same rules you use for the rest of the site, and the plans are on our pricing page (which, for the record, shows the same prices to everyone).

Frequently Asked Questions

Is it legal to show different prices to different website visitors?

It depends on jurisdiction and on who the buyer is. In the EU, rules require disclosure when a consumer price is personalised by automated decision-making, and restrict unjustified differences by nationality or residence. B2B pricing is mostly governed by contract, but public pages reach sole traders too. Keep list prices identical for all visitors and ask counsel before changing that.

What should I personalize first on a pricing page?

The social proof next to the table, by company size. It changes who the page appears to be for without touching the offer, it is easy to QA and easy to revert. Add CTA wording and FAQ sets next, then feature order and the plan badge.

Should the pricing page show local currency automatically?

Yes, if you invoice in that currency, with a visible switcher so the visitor can override it. Each currency should have one fixed price list. Only offer currencies you actually charge in.

How long does it take to test pricing page personalization?

Usually longer than teams expect, because pricing pages get a small share of total traffic. Calculate the sample size before launch from your baseline conversion rate and the smallest lift worth acting on. If the answer is several months, use CTA clicks as the primary metric, bundle changes into one personalized-vs-default test, or accept a documented before/after comparison.