How to Write a Pricing Page for an AI Product

A pricing page for an AI product has one job a normal SaaS pricing page does not: it has to make variable costs feel predictable. Buyers already suspect that "AI-powered" means the bill could move under them without warning. Your page either resolves that suspicion in the first few seconds, or the visitor leaves to compare you against a competitor who explained it better. This is not a piece about what number to charge, that is an economics problem covered in how to price an AI product. This is about structure and copy: the order of sections, what each one has to say, and how to describe usage-based cost without hiding it or burying it in jargon.

Why AI pricing pages are harder than normal SaaS

Traditional SaaS pricing is mostly a seat problem. One user costs roughly the same to serve as another, so a tier is just a bundle of features multiplied by a headcount. The page has one job: help the buyer count seats and pick a bundle. Nobody reads a per-seat pricing page wondering if their bill could triple next month because of how they use the product.

AI products break that assumption because marginal cost is not flat. A document summarizer that costs a few cents to run once can cost fifty times more if a customer points it at their entire archive in one session. Solving that at the unit-economics level is a separate exercise, part of the broader work of AI monetization strategy. The pricing page has a narrower job: explain that variance to a buyer who has thirty seconds and no patience for a spreadsheet.

Research on SaaS pricing page design backs this up directly. Pages for AI products increasingly have to communicate two pricing logics at once, a tier or seat structure and a consumption layer sitting on top of it. A review of pricing page patterns by Webstacks found that companies like Retool and Netlify keep their existing seat-based pricing intact and add AI usage as a separate, clearly metered line item, rather than folding everything into one opaque number. The consumption layer is the part buyers struggle with, and pages that explain it clearly have a real advantage during evaluation.

The anatomy of a pricing page for an AI product

Order matters. Buyers scan pricing pages top to bottom looking for permission to stop reading, either "this is clearly not for me" or "this is clearly the one." Here is the sequence a pricing page for an AI product should follow, in order, and what each section is responsible for.

How to frame tiers and credits honestly

The hardest sentence to write on an AI pricing page is the one that defines what a credit, token, or "action" actually is. Vague versions fail because the buyer cannot map the number to their own behavior. Specific versions work: "one credit equals one generated image, up to four variations" or "one credit equals roughly 750 words of summarized output." A review of AI SaaS pricing models by billing platform Lago found the same pattern across the companies doing this well: they tie the purchasable unit to a concrete, user-facing action, such as Midjourney selling GPU minutes at a stated rate, rather than exposing a backend cost like tokens or GPU-seconds directly to the buyer.

Soft caps do more work on a pricing page than hard caps. A hard cap that cuts a customer off mid-task reads as punitive and shows up in negative reviews. A soft cap, meaning the product keeps functioning past the included allowance and either throttles, drops to a cheaper model, or bills a pre-disclosed overage rate, reads as fair because the buyer chose it in advance. State the soft cap behavior in the pricing table itself, not in a support article three clicks away.

Whether the base layer is a flat subscription or a one-time purchase with metered top-ups is a separate decision, covered in subscription vs one-time fee for an AI tool. Whichever base you choose, the usage layer sitting on top of it needs its own line, its own named unit, and its own visible rate. Do not let it hide inside the subscription price as an unstated assumption.

A worked example beats a rate card every time. Showing "processing 500 support tickets a month costs roughly this much" answers the question the buyer actually has, which is not "what is the per-unit rate" but "what will I actually pay." A live calculator is better still, but even a static example under the pricing table removes most of the guesswork.

1. Names the billable unit in plain language, not backend terms like tokens or API calls

2. Shows what happens at the limit before the buyer hits it, not after

3. States whether unused usage rolls over or resets each period

4. Gives a worked example or calculator, not only a per-unit rate

5. Puts the overage rate in the pricing table, not in the terms of service

Common mistakes on AI pricing pages

Most failures come from treating the pricing page as a place to obscure cost rather than explain it. The same instinct that makes teams cagey about whether to tell clients they use AI shows up here as vague feature language with no attached unit. It reads as hiding something even when nothing is actually being hidden.

• "Contact sales" as the only price shown, including on the entry-level tier

• Feature names like "AI-powered insights" with no cap, unit, or example attached

• Overage rates documented only in the terms of service, not on the pricing page

• Multi-variable pricing (tokens times model times feature) with no calculator or example

• Tiers that differ by seat count only, when the real cost driver is usage, so a heavy user on the cheap tier gets an unpleasant bill

• Credit balances shown with no reset or rollover policy stated anywhere

None of this replaces product-market fit. A clean, honest pricing page will not save an offer nobody wants. But for a product that already works, the pricing page is often the single highest-leverage page on the site to rewrite, because it is the one page every serious buyer reads in full before they reach for a card.

FAQ

How many pricing tiers should an AI product have?

Three or four. Fewer than three forces an all-or-nothing choice and loses the anchoring effect of a middle option. More than four turns the comparison table into a spreadsheet nobody reads to the end.

Should an AI pricing page show credits or dollars?

Both, but dollars first. Show the plan price in currency, then define the credit or usage unit underneath it in plain language. Buyers can convert dollars to value on their own; they cannot convert an abstract credit count without help.

What is a soft cap in AI pricing?

A limit the product keeps functioning past, by throttling speed, dropping to a cheaper model, or billing a pre-disclosed overage rate, instead of cutting the buyer off entirely. It protects margin without producing the support ticket a hard cutoff generates.

Do usage-based pricing pages convert worse than flat-rate pages?

Not inherently. The drop in conversion comes from ambiguity, not from usage-based billing itself. Pages that state the metering unit, show a worked example, and put the overage rate in the table convert close to flat-rate pages. Pages that hide the consumption layer behind "contact sales" do not.

Where should the overage rate go on a pricing page?

In the pricing table or the section directly below it, not in the terms of service. If a buyer has to leave the pricing page to find out what happens after they exceed a limit, the page has already failed its main job.