Should You Price an AI Feature by Seat or by Usage?

Should you price an AI feature by seat or by usage?

Price by seat when usage per person is fairly even and the feature is part of daily work. Price by usage when a few customers use far more than others and each use costs you real money. For most B2B SaaS teams, a hybrid works best: seats with an included usage allowance and a clear price for more.

AI features broke a pricing habit many SaaS companies relied on. Traditional software costs almost nothing extra when a customer uses it more. An AI feature is different. Every request to a model has a cost, and a heavy user can cost many times more than a light one.

That makes the old answer, "just add it to the per-seat price," risky. It can also make the new answer, "charge per use," scary for buyers who want a predictable bill. Here is how I would think through the choice.

Why is AI feature pricing different from normal SaaS pricing?

AI features have a real cost every time someone uses them, because each request runs on a model you pay for. Usage can vary hugely between customers and between users at the same customer. That combination of variable cost and uneven use is what makes flat per-seat pricing risky for AI features.

With most SaaS features, your margin barely changes whether a customer logs in once a week or all day. With an AI feature, your best and most active customers can become your least profitable ones if pricing ignores usage.

There is also uncertainty on your side. Model costs, model choices, and how customers use the feature can all shift over time. Whatever pricing you pick should leave room to adjust without breaking promises to existing customers.

When does seat-based pricing work for an AI feature?

Seat-based pricing works when each user's usage is fairly similar, the feature is part of daily work rather than occasional bursts, and the cost per user is small compared to the seat price. It is simple for buyers to budget and easy for sales to explain, which matters a lot in B2B deals.

Seats suit features like an AI writing assistant inside a tool people already use every day. Most users will use it a moderate amount. A few will use it heavily, but the average stays predictable.

The risk is the heavy user. If a small group uses the feature far more than everyone else, they eat your margin while paying the same as light users. Add a fair-use limit in your terms so you have a way to handle extreme cases without changing the price for everyone.

When does usage-based pricing work better?

Usage-based pricing works better when usage varies widely between customers, when each use delivers a clear unit of value, and when the cost per use is significant. Examples include enriching records, generating reports, or processing documents. Customers who get more value pay more, and your costs stay tied to revenue.

The key is a unit the buyer understands and values. "Per enriched contact" or "per document processed" makes sense to a buyer. "Per thousand tokens" usually does not. Price in the buyer's language, even if your costs are measured differently underneath.

The downside is unpredictability. Finance teams dislike bills that change every month. If you choose usage pricing, help buyers estimate their spend before they sign. I wrote about how to present this in how to explain usage-based pricing without scaring buyers.

What are the hybrid options?

The common hybrids are seats with an included usage allowance, a platform fee plus usage, and prepaid credits that customers draw down. Each one gives buyers a predictable base while tying heavy use to extra revenue. For most B2B teams, seats plus an allowance is the easiest to explain and sell.

Seats with an allowance works like this: each seat includes a set amount of AI usage per month, enough for a typical user. Teams that need more can buy extra in blocks. Light users never notice a limit. Heavy users pay for what they use.

Credits are flexible but add mental overhead. Buyers have to translate credits into actions, and unused credits create awkward renewal conversations. Use them when your AI features vary a lot in cost and you need one shared currency across them.

How do you choose the usage metric?

Pick a metric that matches the value the customer gets, grows with their success, is easy to predict, and roughly tracks your cost. Good metrics are things buyers already count, like records, documents, or reports. Avoid metrics that are technical, hard to estimate, or that punish customers for using the product well.

Test the metric with a simple question: can a buyer estimate next month's usage in under a minute? If they need to understand model internals to answer, the metric is wrong.

Also check that the metric does not create bad incentives. If you charge per AI-generated draft, users may avoid regenerating a poor draft to save money, and then blame your product for the result. The metric should encourage the behavior that makes customers successful.

How do you protect your margins without scaring buyers?

Know your cost per unit and your heaviest users before you set prices. Set the included allowance above typical usage, add a fair-use clause for extreme cases, and price overage clearly. Show buyers a simple estimate and an alert before they go over. Predictability is what keeps a usage component from feeling like a trap.

Measure real usage during a beta before you publish prices. Look at the distribution, not just the average. The average hides the handful of users who could cost you the most.

Leave yourself room to change. State in your terms that AI usage allowances may be reviewed, and give customers notice before any change. That honesty costs you little and protects you if model costs or usage patterns shift. For annual deals, think about how this interacts with the term, which I covered in whether a SaaS should offer annual-only pricing.

How do you test the pricing before committing?

Run a paid beta with a few customers on the pricing model you favor, track their actual usage and cost, and ask them to forecast their own usage before and after. Compare forecast to reality. If buyers cannot predict their bill, or your heavy users are unprofitable, adjust the model before you publish it.

Talk to the people who sign the contract, not just the users. Ask finance or procurement which model they would approve faster. Their answer often decides the deal more than the feature itself.

Keep the first public version simple. You can add tiers, credits, or add-ons later. It is much harder to simplify a complicated pricing model after customers have signed up to it.

What should you do next?

Pull usage and cost data for your AI feature, or estimate it from a beta. Look at how evenly usage spreads across users. If it is even, start with seats and a fair-use limit. If it is uneven, start with seats plus an included allowance and a clear price for more. Test with real buyers before you publish.

Write down the assumptions behind your choice, such as cost per use and typical usage, and review them every quarter. AI feature pricing will need more frequent adjustment than the rest of your pricing page.

I build websites and the automations behind them for lead generation, and pricing pages are where these decisions meet buyers. If you want help presenting an AI feature's pricing clearly, reach out and let's chat.