The questions your pricing page fails to answer

There is a pattern in website chat that shows up on nearly every SaaS site: a large share of questions arrive on the pricing page, and very few of them are actually about the price. They are about what happens next, what is included, and what the commitment is.

That distinction matters because the two problems have different fixes. A price objection is a positioning problem. An information gap is a copy problem, and copy problems are cheap.

The five gaps that generate the most questions

1. What a unit actually means

Credits, seats, sources, messages, workspaces. Every SaaS has a unit and most pricing pages assume the visitor already understands it. If your plan says 500 credits, a first time visitor has no way to know whether that is generous or nothing. Anchoring it to something real, such as roughly what a small site consumes in a month, removes an entire question category.

2. What happens when you hit the limit

Does it stop, queue, throttle, or bill you extra? This is a risk question dressed as a pricing question, and leaving it unanswered makes the whole page feel like a trap. Say what happens even if the answer is unglamorous.

3. Whether you can move between plans

Upgrades are assumed. Downgrades are not. People ask because they are trying to establish whether picking wrong is expensive. One sentence about how plan changes work removes the hesitation.

4. What is not included

Feature lists say what you get. Almost nobody says what they do not get, so visitors ask. Naming a limit honestly reads as confidence, and it also stops the wrong customer from signing up and churning.

5. What the commitment is

Monthly or annual, notice period, refund position. When this is missing, people assume the least favourable version.

Why the FAQ block below the table does not solve it

Most pricing pages already have an FAQ block, and questions keep arriving anyway. Two reasons. The FAQ is usually written to reassure rather than to inform, so it answers questions nobody asked. And it sits below the fold after the decision point, so the visitor has already formed an impression of risk before reaching it.

The information that reduces hesitation should sit next to the thing causing hesitation. A limit explanation belongs in the plan card, not four screens down.

The test

Read your pricing page as somebody who has never heard of your company and has fifteen seconds. Then write down every question you cannot answer from the page alone. That list is usually close to what your chat log already contains, which is a useful confirmation that the exercise is not guesswork.

A note on showing pricing at all

Some teams hide pricing to force a conversation. That is a legitimate strategy for genuinely bespoke products. For self serve software it mostly converts a cheap information question into an expensive sales conversation, and loses the buyers who will not book a call to find out a number.

If you do publish pricing before it is final, say so plainly. A page labelled as a launch direction with honest limits is more credible than a page implying certainty you do not have.

The recognisable set

The same questions surface across most SaaS pricing pages, which is useful, because it means you can audit your own page against a list rather than waiting to be asked.

Whether a limit is hard or soft. What happens on the day you exceed it, which is a different question from what the limit is and is almost never answered. Whether the limit resets monthly or accumulates.

Whether a named integration is the full product or a webhook carrying the same name. This one causes real damage because the buyer discovers it after purchase.

Whether seats include read only users. Whether an annual plan can be cancelled mid term. What support actually means on each tier, since support is a word that spans a shared inbox and a named contact.

Why the table cannot hold them

A pricing table is a grid of plans against features. It is structurally good at what a plan costs and what is included, and structurally incapable of holding conditional answers.

Every question above is conditional. It depends on your situation, and a grid cell cannot carry a dependency without becoming a paragraph, at which point it stops being a grid.

So the answers get pushed into documentation, where the buyer will not assemble them. They open two tabs, fail to reconcile the pricing row with the docs paragraph that qualifies it, and either guess or leave.

Finding your own version of the list

You do not need any tooling for the first pass. Read the last fifty pre sale emails and count what was asked. It takes an hour and it produces a better list than any framework.

The pattern to look for is a question that required someone to reply with a link plus a clarification. The link means the answer existed. The clarification means the page did not answer it in the form the buyer needed.

Those are the rows to add, and they are usually four or five sentences, not a redesign.

What to do with the answers once you have them

Put the common ones on the pricing page itself, below the table, as a short FAQ. Not a link to documentation. The buyer is on the pricing page because that is where the decision is happening.

Keep the wording specific enough to be quotable. An answer that says limits are flexible is worse than no answer, because it reads as evasion. An answer that says the limit is soft and overage is billed at the end of the month is a fact somebody can act on.

And make the harder ones reachable rather than published, if publishing them commits you to something you are not ready to commit to. Naming the constraint and offering to discuss it is honest. Omitting it is not.

The questions you should not answer on the page

Not everything belongs on the pricing page, and a page that tries to pre empt every objection becomes unreadable.

Anything genuinely bespoke should be reachable rather than published. Volume terms, unusual contractual arrangements, anything where the honest answer is that it depends. Naming the constraint and offering to discuss it is better than a vague published answer that satisfies nobody.

Anything you are not ready to commit to should be described as planned or left off. A published price you intend to change is worse than no published price, because the first creates an expectation and the second creates a conversation.

The line is whether a specific answer would apply to most readers. If it would, publish it. If it would apply to five percent and confuse the rest, make it findable and keep the page readable.