How to Price an AI Service: Four Models and the Floor Rule

Software pricing used to be easy in one particular way. You built the thing once, hosting cost was near zero per extra user, and a flat monthly fee worked whether someone logged in twice a month or forty times a day.

An AI service breaks that. Every run spends real money on model tokens, retrieval, and compute. Your heaviest users become your least profitable accounts, and that happens quietly, on a spreadsheet you are not looking at. What follows is the four pricing models, who each one suits, where each one breaks, and the one rule that applies regardless of which you choose.

Why is seat-based pricing losing ground?

Because headcount stopped tracking value. When a service does work autonomously, doing the job better means the customer needs fewer people logged in, so your revenue falls exactly as your product improves. That is a strange incentive to build a business on.

The market has been moving accordingly. Growth Unhinged's 2025 State of B2B Monetization report found pure seat-based pricing fell from 21% to 15% of companies in twelve months, while hybrid pricing rose from 27% to 41%.

There is a second problem. Two customers on the same seat price can cost you wildly different amounts. One runs five queries a month. The other wires up a script and runs fifty thousand. Under a flat seat fee you fund the difference yourself.

How does usage-based pricing work?

You charge per unit consumed: a call, a task, a document, a minute. Revenue then moves with your costs, which is the main thing it fixes. A customer who triples their volume triples their bill, so a usage spike stops being a margin event.

It breaks on the buyer's side. Finance teams struggle to approve a line item that could be $400 or $4,000, and that uncertainty stalls deals. It also creates an odd incentive for you: if you optimise your prompts and halve your token use, you halve your revenue too, unless you reprice.

What is outcome-based pricing?

You charge only when a defined result happens. Not per attempt, not per minute, but per resolved ticket, per qualified lead, per booked appointment. Buyers like it because the return is obvious and the failure risk sits with you.

It breaks on definitions. Someone has to decide what counts as the outcome, and that someone is usually the vendor. Intercom's Fin is the clearest live example: it charges $0.99 per resolution, and Intercom's own documentation defines a resolution as a conversation where Fin answered and the customer either confirmed it helped or left without asking again. Read that definition twice. A customer who gives up and closes the tab can look identical to a customer who was helped.

The rest of Fin's price list shows how much scaffolding an outcome model needs once it meets reality: a minimum monthly resolution count, plus separate charges for a handoff, a disqualification, and a qualification. "Just charge for outcomes" turns into a rate card fairly quickly.

Does anyone have this settled?

No, and the clearest evidence is that Salesforce currently runs three pricing models for Agentforce at the same time: roughly $2 per conversation, consumption-based Flex Credits at around $500 per 100,000 credits, and per-user licensing from about $125 per user per month.

A company with Salesforce's pricing resources offering three simultaneous answers is not indecision. It is a reasonable read of the situation: different buyers need different risk profiles, and nobody has found the single structure that fits all of them. If you feel unsure about which model to pick, you are in good company, and you are allowed to run more than one.

Which model fits your service?

Hybrid is where most mature companies land, and there is some evidence it pays: Maxio's 2025 pricing research reports companies on subscription-plus-usage models showing a 21% higher median growth rate than those on pure subscription or pure usage.

What is the floor rule?

Your price per task must exceed what that task costs you to run. This is arithmetic rather than strategy, and it is the part people skip.

Add up what one run actually costs:

cost per call = model tokens
              + retrieval and vector queries
              + sandbox or container runtime
              + third-party API and search fees

Now price a flat $50 per month unlimited plan against it, assuming $0.15 of compute per query:

• A light user runs 10 queries. You spend $1.50 and keep $48.50.
• A scripted power user runs 1,000 queries. You spend $150 and collect $50.
• That single account loses $100, wiping out the margin from roughly two light users.

You do not need many of the second kind. This is why unlimited plans on AI services quietly stop working: the average looks fine right up until the distribution has a tail, and usage distributions almost always have a tail.

Set a minimum unit price comfortably above your loaded cost, and put a real limit on every tier: an included allowance, metered overage above it, or a hard cap. A spend cap also happens to be the thing that makes nervous buyers sign, so it protects both sides.

How do you move existing clients onto it?

Measure before you touch a contract. Log your real cost and task volume per account for a month or two while leaving invoices alone, so you learn where your light and heavy users actually sit rather than guessing.

Then price the base fee at roughly a client's observed median usage, include an allowance that covers a normal month, and meter above it. Offer a spend cap from the start rather than waiting to be asked. Frame the change around work delivered rather than compute consumed, because "you are paying for tokens" is a worse sentence than "you are paying for the tickets we close".

If you are still deciding how to package the underlying know-how rather than how to meter it, the leverage and leakage tradeoff comes first: what you sell determines what you can meter. Per-call marketplaces exist for people who would rather not build billing at all, Askpert among them, though the pricing logic here applies whichever route you take.