How Pricing Pages Fail

The pricing page is usually the second or third page a serious visitor opens, and often the last. It is where interest converts into a decision or quietly ends, and it tends to receive far less attention than the homepage that people spend less time on.

The failures are consistent enough to enumerate.

Failure one: no price

The most common, and the most costly.

"Contact us for pricing" is chosen for reasonable-sounding reasons: the offering is complex, prices vary, a conversation would explain the value better. All true, and none of it addresses what the visitor is doing, which is trying to work out whether this is a plausible option at all.

Without any number, they cannot. So they do one of two things. They leave and look at a competitor who published something. Or they make up a figure based on nothing, and the figure they invent is usually wrong in whichever direction is worse for you.

If genuine variation makes a single price impossible, a range works, and so does an example: "most businesses of this size pay between X and Y" tells a visitor what they need without committing you to a number for every case.

Failure two: tiers that describe features instead of customers

A typical pricing page presents three columns of feature lists and asks the visitor to work out which one is theirs. That is a comparison task, performed with incomplete information, by someone who does not yet know what half the features mean.

The visitor's actual question is not "which of these features do I want" but "which of these is meant for someone like me". A tier that begins by naming its intended customer — team size, stage, situation — answers that in one line, and the feature list becomes supporting detail rather than the decision itself.

The related error is differentiating tiers on things nobody can evaluate in advance. Nobody knows how many API calls they will make. Segmenting on something the customer cannot estimate converts a pricing decision into a guess, and people avoid making guesses that cost money.

Failure three: the terms are missing

Price is only half of what a buyer needs. The other half is what happens afterwards, and it is routinely absent.

Can I leave? When does it take effect? Does the price change at renewal, and by how much? What happens if I need to reduce my usage rather than increase it?

Withholding this does not defer the question; it just makes the visitor assume the least favourable answer, because a company that does not publish its cancellation terms is not usually thought to have generous ones.

Stating them plainly costs nothing and removes an objection before it forms. Ours is that you can cancel at any time, with cancellation taking effect at the end of the current billing period [1]. Whatever your version is, the page is better with it than without it, even when the terms are ordinary — perhaps especially then.

Failure four: the form arrives too early

Many pricing pages hide the number behind a form, which reverses the order of the transaction. The visitor is asked to give something before receiving anything, at the precise moment they are least committed.

The stated reason is lead capture. The actual effect is that the people who complete the form are disproportionately those with no alternatives, and everyone else has gone.

Where a form is genuinely needed, ask for as little as will do. Every field is a reason to abandon, and fields collected because they might be useful to someone eventually are the clearest instance of the habit worth avoiding — gathering data speculatively "in case it is useful later" [2]. A name and an email address will support a conversation. Job title, company size, and timeframe can be asked in that conversation, by a person, when they are relevant.

The mechanical failures

Two more, both boring and both common.

The page is slow, often because pricing is loaded dynamically from somewhere else and the visitor watches an empty table. Web Vitals frames performance as "quality signals that are essential to delivering a great user experience on the web" [3], and there is no page where that matters more: a blank pricing table at the moment of maximum intent is the worst possible time to be absent.

And the page is not readable on a phone. Three-column comparison tables degrade badly on small screens, frequently into horizontal scrolling that hides the column a visitor wanted. A large share of first visits are mobile, and a pricing table that requires sideways scrolling to compare is a pricing table that will not be compared.

The anchoring problem with three tiers

The three-column layout is so standard that its effects go unexamined, and it does something specific to how people choose.

Presented with three options, most people take the middle one. This is well known and widely exploited, which is fine as far as it goes. The problem is what it does to the two on either side.

The cheapest tier stops being an offer and becomes a device — deliberately limited so nobody picks it. Visitors who genuinely belong there sense this, and what they learn is that the smallest version of you is not seriously meant. Some of them leave rather than buy a plan the page has signalled is a mistake.

The most expensive tier often has the opposite problem: it exists to make the middle look reasonable, and its contents are assembled for contrast rather than for a real customer.

The correction is to design each tier for somebody specific and be able to name who. If you cannot describe the customer who should choose your entry plan, and be glad they did, then it is not a plan — it is a rhetorical device, and it is costing you the segment it appears to serve.

What a good pricing page does

It states a number, or a range, above the fold. It names who each option is for before listing what each includes. It answers the obvious follow-up questions — commitment, cancellation, what changes the price — on the same page rather than in a linked document. It asks for nothing before it has given something. And it loads quickly enough to be read on a phone on a train.

None of that is a design problem. It is a decision about how much you are willing to tell someone before they talk to you, and the businesses that tell more generally get to talk to better-qualified people.