SaaS Pricing Pages That Sell: Patterns and Examples From the German Market

«Our pricing page gets visitors, but it doesn't convert.» I hear this sentence in almost every first conversation with SaaS teams. The cause is rarely the price itself: the page answers the wrong questions, hides decisive numbers, or forces prospects into a sales call they never wanted.

The data on this is unambiguous. In a Gartner survey of 632 B2B buyers, 61 percent preferred buying without contacting sales; in the follow-up survey published in March 2026, that figure had already reached 67 percent. Your pricing page is where this self-service happens — or fails.

And this is no longer about small sums: according to McKinsey's B2B Pulse 2024, 39 percent of buyers are willing to close orders above $500,000 through self-service or remote contact. Two years earlier, it was only 28 percent.

In this article I take the pricing page apart into its building blocks, settle the question «transparent or on request?», and show you, on four examples from the German market verified on September 22, 2026, what sets good pricing pages apart. This article is one piece of our guide to the anatomy of a B2B SaaS website.

First, a definition: a pricing page is not a price list. It is a decision aid for people who are close to buying. Visitors arrive with three questions: What will it cost me? Which plan fits me? What happens if I get it wrong? Each of the five building blocks answers at least one of them.

More than four plans overwhelm; a single one doesn't segment. Naming is the decisive part: the German accounting software sevDesk simply calls its plans «Rechnung» (invoicing) and «Buchhaltung» (bookkeeping), after the job the customer wants done. Lexware Office works with sizes S to XL and attaches a concrete use case to each tier.

The second decision is the pricing axis: per user (awork), per feature scope (sevDesk, Lexware Office), or per workforce size (Staffbase). Choose the axis that grows with your customers' value. A tool that becomes more valuable with every additional user may charge per user; a bookkeeping tool for solo founders may not.

The rule of thumb: your prospect must recognize themselves in a plan name instead of having to study your feature matrix.

The plan cards at the top condense; the table below them proves. awork lists more than 30 criteria, from project limits to SSO and support levels. sevDesk groups its table into categories such as e-invoicing, taxes, integrations, and support. That grouping is the difference between a reference work and an imposition: nobody reads 40 unsorted rows.

A practical trick: collapse the categories by default and leave only the headings visible. Whoever needs details opens them deliberately; everyone else scrolls on to the FAQ without fatigue. The table still lives in the source code and stays readable for search engines.

An anchor signals which plan is the normal choice. sevDesk highlights exactly one plan with «Unsere Empfehlung» (our recommendation), Lexware Office with «Am beliebtesten» (most popular). awork instead labels every plan with a team size, from «Empfohlen für 1–5 User» (recommended for 1–5 users) up to the 100+ user tier. Both patterns set a default — that is not chance, it is conversion craft.

The second anchor is the billing term. awork shows €12 with annual billing next to €16 with monthly billing; sevDesk states discounts of 25 and 50 percent right at the term toggle. The monthly price makes the annual price look cheap.

The FAQ on the pricing page is sales work without a sales rep. awork answers 14 questions, Lexware Office nine, Staffbase six. The topics are the same everywhere: cancellation terms, payment methods, plan changes, data export. Collect your questions from real sales conversations, not from your idea of them.

The last building block defuses the residual risk: awork advertises a trial without a credit card, Lexware Office 30 days of full access to its largest plan plus monthly cancellation. Every risk you visibly defuse is one objection fewer in your prospect's head.

Now for the crux of B2B pricing. There is no blanket answer, but there are clear criteria. Transparent prices work when your product sells itself: self-service checkout, a trial phase, prices in the two- to three-digit monthly range. How you turn trials into paying customers is covered in my article on trial and demo conversion.

Price on request is legitimate when every single deal really is calculated individually: enterprise contracts, strongly fluctuating user counts, rollout projects with a services component. The danger: you lose the growing group of self-service buyers, which Gartner most recently put at 67 percent, and you never measure that loss.

The middle ground is allowed and often the best choice: awork shows three plans with prices and places an enterprise package «on request» next to them. That way you serve both buyer types on one page.

One argument for transparency is easily overlooked: pre-qualification. Whoever knows your prices and still inquires has already accepted the budget. Every first call that fails over a €50 price expectation when your entry tier starts at 500 is an hour of sales time that a visible number would have saved.

Whatever you choose: measure it. A pricing page without event tracking on plan clicks and FAQ opens is flying blind. In my experience, a lightweight tool like Umami is enough; what matters is that you see the drop-off between price view and sign-up at all.

I retrieved and reviewed the following four pricing pages on September 22, 2026. All four are SaaS products from the German market, and all observations apply as of that date: pricing pages change constantly, which will become a technical argument later on. I would have liked to add Personio, but the site blocked automated retrieval; I only describe here what I checked myself.

The accounting software shows four plans from €0 to €34.90 per month. The toggle for 1, 12, or 24 months states the savings openly: the «Buchhaltung» (bookkeeping) plan drops from €25.90 on monthly payment to €19.90 on a 24-month term. The badge «Unsere Empfehlung» additionally steers visitors to exactly this plan.

Your takeaway: put a plain figure on term discounts instead of hiding them in the fine print.

The project management tool awork combines three transparent plans (€5, €12, and €22 per user per month with annual billing) with an enterprise package on request. Instead of a «popular» badge, every plan carries a team-size recommendation, from the Basic plan «für 1–5 User» (for 1–5 users) to the enterprise package «für 100+ User» (for 100+ users). Add a comparison table with more than 30 criteria and a trial without a credit card.

Your takeaway: a recommendation by team size answers the question «Which plan fits me?» more precisely than any «popular» badge.

Four tiers from €7.90 to €32.90 per month, halved for the first three months. The L plan carries the badge «Am beliebtesten». Notable: the 30-day trial includes the full XL scope, payroll module included, and right on the page sit 4.3 out of 5 stars from 2,447 eKomi reviews.

Your takeaway: a review score next to the price answers the unspoken question «Can I trust these people?».

The employee communications platform names no prices. Instead, the page differentiates three packages by workforce type (frontline, entire workforce, enterprise), shows a logo slider with more than 1,500 enterprise customers, and backs up the value with figures such as 87 percent app adoption in the first year. Six FAQ entries answer, among other things, how quickly a quote arrives.

Your takeaway: if you leave out the price, you must prove the value twice over and make the step to a quote as small as possible.

The most common maintenance mistake I see in SaaS projects: prices hard-coded in the frontend. Every price change then needs a developer and a deployment. Worse still: pricing page, footer, and comparison articles drift apart because someone forgets one spot.

Buyers register exactly these contradictions. In the same Gartner survey, 69 percent report inconsistencies between what the website says and what sales tells them. A hard-coded price is the easiest way to produce that inconsistency yourself.

Our practice: plans are structured content in the headless CMS. In Sanity, we model a document type «plan» with price fields per billing interval, feature references, and a badge field for the recommendation. Pricing page, comparison table, and footer pull from the same source.

A side effect of structured maintenance: you can additionally serve your prices as schema.org markup (Product with Offer) without maintaining them twice. Search engines and AI assistants then read your prices by machine — same source, one more renderer.

My assessment from our own projects, not a study: moving from hard-coded prices to CMS-managed ones rarely takes more than two developer days in a Next.js project. Where the pricing page sits in the overall budget is broken down in the article What does a SaaS website cost?.

If your pricing page gets visitors but delivers no deals, that is rarely a price problem — it is a page problem, and page problems can be solved. As a B2B website agency, we build pricing pages with a clear anchor, an honest FAQ, and prices maintained in the CMS instead of the code.

The fastest route to a better pricing page: we look at it together. Bring your current page and the conversion numbers of the last three months; then we won't talk theory, we'll talk about your numbers. Book a free intro call — 30 minutes, concrete pointers, no sales show.