Why AI Pricing Breaks the Per-User Playbook

AI pricing breaks the per-user playbook because agents, which don't need their own seats, create value with your product that user-based pricing doesn't capture. A seat measures a person logged in. When an AI agent drafts the reply, reconciles the account or pulls the report, often through an API or MCP connection, the customer gets more done and the seat count doesn't move.

The usual response to this dynamic starts in the wrong place. Vendors watch their inference bill climb, add a markup to token costs and call it a pricing model. I'd start with the value the product creates and what buyers will pay for it. Then check the economics, and add protections where a few customers' usage could sink the margin.

Whatever you charge on, customers still have to forecast it. When I hosted former Salesforce pricing lead Glenn Dearing for a webinar, we ran a live poll: 56% of attendees said they price on usage or credits and their customers can't predict the bill.

This is Part 1 of a three-part series drawn from that conversation, "Pricing AI Is Hard: 8 Lessons (and a Few Scars) from 12 Years at Salesforce." Part 1 covers what changed. Part 2 covers what works now. Part 3 covers the systems Finance and RevOps need underneath.

Why per-user pricing worked for so long

Glenn ran the pricing team at Salesforce from 2012 to 2024. For most of that time, per user was the default metric, and the source of most of the company’s revenue.

It lasted because seat count closely tracked value delivered. The people logged in were the people getting work done, so more seats meant more value delivered. Cost never got in the way. Adding the hundred-and-first user cost Salesforce almost nothing to serve, so no single user could damage the economics.

SMS was the exception. Each text message carried a real cost, so Salesforce couldn't include unlimited messages. Customers understood that. They knew Salesforce wasn't trying to get rich on SMS, so they accepted a cap.

Agents break the link between seats and value

A support team of 20 can now run an agent that triages every incoming ticket and drafts the first reply. The work done in your product grows, and so does the value the customer gets from it. The seat count stays at 20.

Some customers don’t want to log in at all. They connect your product to their own agents through an API or an MCP connection and never open your interface. Charge only per seat, and your most active customer, who loves your product and gets the most value from it, can look like your smallest one.

Per user isn't going away. Glenn doesn't expect seats to disappear: a seat still grants access, and where humans are the primary users, it can still track value well. But not one attendee in our live poll said per-user pricing still works on its own. The question is what to charge for alongside the seat, and where to start when you decide.

Price for value, then check the economics

Generative AI did change the cost side. When Salesforce began planning generative AI features for its sales and service products, Glenn said the new costs "literally broke the economics on day one." Cost to serve (what the vendor pays each time a customer uses the product) stopped being close to zero. Glenn couldn't know whether a customer would spend a dollar or a penny each time they pressed enter.

The tempting fix is cost-plus pricing: take the token cost, add a markup, pass it through. I wouldn't start there. Your token costs describe your inputs, not the customer's outcome. A buyer doesn't care about your costs. They care about their outcome, such as support tickets resolved, payments processed successfully, or hours saved.

Start with the value delivered instead. Glenn's method for a new pricing project is to interview four or five friendly customers and ask how the capability would make them money or save them money. The words they use point to the metric. He'd worry less about whether that metric scales with your cost of goods sold.

After you understand the value delivery mechanism, check the margins:

1. Model the margin at realistic usage, including your heaviest customers.
2. Confirm the price on your value metric sits high enough that cost to serve can't push you underwater.
3. Protect against the outliers. Glenn's recommendation fits here: put limits on the capabilities that drive inference cost, and give customers a clear way to buy more capacity when they hit them. Fair usage clauses can also be used.

In practice, one contract can carry seats, a value-based usage metric and an allowance with a way to buy more. Each of those terms has to flow from the quote to the invoice without someone retyping it.

What is cost-plus pricing for AI?

Cost-plus pricing sets the price by adding a markup to what it costs the vendor to serve each request, such as inference and token costs. It protects margin. But it ties the price to the vendor's inputs instead of the outcome the customer pays for, and it moves every time model providers change their prices.

The customer still has to predict the bill

A pricing metric only works if buyers can forecast it. Our live poll showed how many teams are stuck there:

• 33% price on usage or credits, and their customers can predict the bill
• 56% price on usage or credits, and their customers cannot
• 11% are in the middle of a pricing change
• 0% said per-user pricing still works

Glenn has seen a well-chosen metric fail on predictability. In 2012, Salesforce moved Force.com from per-user pricing to per-application pricing, charged by the number of custom objects a customer built. Think of custom objects as database tables. The metric tracked value well. But nobody starting a new app knew whether they'd need two objects or twelve.

Salesforce built calculators that made the model a bit more digestible for CIOs. Procurement teams still couldn't follow it. The sales team couldn't explain it to customers. Within about 18 months, Salesforce unwound the model and went back to mostly per user.

I've been on the buyer's side of this. About five years ago, before Turnstile, the company I was at bought cybersecurity software priced in "nodes." The vendor went through our systems and told us how many nodes they thought we’d need for the next twelve months. They couldn't explain what in our systems would change that number. It was entirely unpredictable.

That's bill shock before the first bill arrives. When you pick the value metric, test it on the person who has to approve the budget.

Pricing now changes constantly

Glenn said nearly everyone he works with is changing pricing continuously. A new product release, a customer request or a new idea from the CEO keeps reopening it.

We're seeing the same thing, especially with sales-led teams. They run different pricing for different segments, offer different packages to sub-segments and let pricing shift over time. Agents add another reason to revisit it: as customers move work from people to agents, the value metric that fit last year may not fit next year.

Pilots and betas add another layer. Glenn's warning: you don't want to tie a customer to pilot pricing for the rest of their life. So plan how you'll migrate pilot customers over time.

What this means for Finance and RevOps

Put those shifts together and Finance and RevOps inherit a steady stream of pricing changes: new value metrics, usage allowances, fair usage terms and migrations off pilot pricing. Each one has to work in quoting, billing and reporting.

I opened the session with the point I care about most. A model that's easy to sell but can't be invoiced cleanly turns into manual billing every month.

Glenn's view, after more than two decades in pricing, is that a pricing and packaging strategy is "necessary, but not sufficient". You also need the systems that can run it.

If you're pricing AI today, these are the questions I'd ask first:

• Does your pricing capture the value agents create, not only the value from people with seats?
• Did you set the price from value first, then check margin at realistic usage? Not the other way around
• Do you have margin protection, such as limits or fair usage terms, for unusually costly usage?
• Can customers predict their bill before they sign?
• Can reps explain and quote the model without a pricing specialist on the call?
• Can you see actual usage by customer, so you can help the next customer forecast?
• Can billing change when pricing does, without months of work?

Part 2 covers Glenn's lessons on choosing a metric, predictability and legibility. Part 3 covers quoting, metering and billing.

Next in the series: Part 2: How to Price AI: Lessons From 12 Years at Salesforce

Watch the webinar

"Pricing AI Is Hard: 8 Lessons (and a Few Scars) from 12 Years at Salesforce" is available on demand. Glenn walks through all eight lessons, and we take live audience questions on sales comp, choosing a metric and when to abandon a pricing model.

Watch the recording