Insight Method Research Author
Back to Method

How Should AI Applications Charge? Per-User Pricing Is the Biggest Trap of the AI Era

2024/06/03

Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle

How to price AI products is where most startup teams take the lazy route. They see competitors charging monthly fees per user and copy the model. This “copying” often digs a massive hole—because per-user pricing assumes “the more people, the more you earn.” But the value of AI products lies precisely in needing fewer and fewer people.

First, understand this: Pricing models aren’t just pricing strategy—they define what you’re actually selling.

Three Pricing Models, Three Types of Business

There are essentially three pricing models, each corresponding to completely different business logic.

Per user (per seat): you’re selling “seats.” More people means more revenue, provided more people use it. This is the traditional SaaS approach.

Usage-based: you’re selling “workload.” Pay for what you use—per token, per request, per consumption. This is infrastructure-layer thinking.

Outcome-based: you’re selling “results.” You only charge when you deliver results; no results, no charge. This is the most extreme and powerful model.

No model is inherently better—the key is fit. But the AI era presents a major problem: per-user pricing, the most comfortable path, is being blocked by AI itself.

Why Per-User Pricing Is a Trap in the AI Era

Per-user pricing logic rests on the premise that “products are for people to use.” But AI products sell precisely on “replacing people.”

If an AI customer service system truly replaces three human agents, per-user pricing lets you charge for only one seat while delivering three people’s worth of value. The more customers save on headcount, the less you earn—the more value the product creates, the less you charge. This is a direct conflict between pricing logic and product logic.

This is why leading AI companies would rather take risks with usage-based or outcome-based models: they know per-user pricing caps their own value.

Outcome-Based Is the Strongest but Hardest

The most extreme model is outcome-based: charge only when the product solves the problem; no solution, no charge.

Customers love this model—no risk, tied to results. Vendors like it too—once successful, both deal size and trust are extremely high.

But it’s the hardest, for three reasons: you must define “success” (what counts as solved?); you must measure “success” (where does the data come from?); you must attribute “success” (is it your contribution or the customer’s luck?). Without all three, outcome-based pricing won’t work.

A counterexample illustrates the standard: some companies handle credit card chargeback recovery and only count successful recoveries, with bank settlements providing the most objective “success” evidence—so they dare to charge entirely on outcomes. If your “success” relies on subjective customer judgment, start with a hybrid model.

Apply This to Your Own Product

When pricing your product, don’t default to per-user. Think through this sequence:

First ask: does my product “augment people” or “replace people”? Augmentation can use per-user; replacement should use usage-based or outcome-based, not per-user.

Then ask: can my “success” be defined, measured, and attributed? If yes, move toward outcome-based; if not, start with usage-based and gradually work toward outcomes.

Finally ask: do I dare tie pricing to customer success? If you dare, your product will appear more valuable; if you don’t, it means you lack confidence in your product.

Pricing isn’t about filling in a price sheet—it’s redefining your product’s value. Answering these three questions is far more useful than copying a competitor’s pricing table.

Key points: Pricing models determine what you sell (seats/workload/outcomes); per-user pricing gets undermined by AI’s people-replacement logic; outcome-based is strongest but hardest (define/measure/attribute success); first ask augment vs. Replace, then decide pricing model.

Last updated on