"Token economy" has entered the outcome layer

Tokens are reshaping the value coordinates in the AI era. This is the 11th installment of the "Token Economics" series, exploring how the AI pricing model is evolving from "pay - per - usage" to "pay - for - results", as well as the underlying logic and challenges of this type of pricing model.

The image is generated by AI.

The news that "Doubao may launch a paid version" has sparked a national discussion. On June 3rd, Doubao issued a statement, responding to some of the rumored price information and confirming that it will launch a professional version, with the service being free within a certain limit.

Beyond the price, when it comes to the subscription model itself, what really triggers public discussion is not "whether AI products should be charged", but rather that users are starting to care: How long can free AI remain free? Which capabilities will continue to be open, and which will be placed in the paid tier?

Compared to the price itself, what is more worthy of our attention is the underlying industry signal: As AI products gradually move from the "user growth stage" to the "commercialization stage", more and more manufacturers are beginning to explore stable and sustainable pricing models.

Recently, I've looked through the pricing pages of many AI products, and their strategies are quite similar: Columns of packages are arranged by the number of users, months, and call volumes, just like similar products with different packaging on the shelves.

I noticed that a company named "Intercom" is a bit special.

Many people may not have heard of this company, but if you've seen the online customer service chat window popping up in the lower - right corner of an overseas website, there's a high probability that you've come into contact with products of this kind.

Intercom was founded in 2011. It is a well - known customer service and customer communication software company that has long provided online customer service, customer support, and marketing automation tools for enterprises. With the rise of generative AI, Intercom has also placed its focus on the AI customer service robot Fin, positioning it as an "AI customer service agent" capable of directly handling customer problems.

On Fin's pricing page, there is only one sentence: $0.99 for each customer problem solved. No charge if the problem is not solved.

Fin calls "solving" an "outcome". In short, I'll do this for you until the demand is fully addressed. It's valid only when it can transfer to human intervention if necessary and the context is retained. It doesn't charge by the number of conversations, nor does it care how many models, tokens, or searches you use. It only cares about one thing: Is the job done?

This doesn't seem like selling software; it's more like hiring a piece - rate worker. And there are also price differences between different model capabilities.

This also makes it so that when enterprises purchase AI, they are no longer just facing the question of "is it expensive", but a more fundamental question: What exactly am I getting for this money? Is it an account? A single call? A certain model's capabilities? Or a completed and acceptable piece of work?

This question is becoming the real starting point for the change in AI pricing.

01

The "Token Economy" Enters the Results Layer

Looking back at the evolution law of the software business model itself, we can find that the pricing power of AI is undergoing an important transformation.

In the past, the most familiar way to sell traditional software was to sell accounts.

Companies pay for CRM (software for managing customers and sales processes) based on the number of salespeople. They pay for customer service systems based on the number of seats. They pay for collaborative office software based on the number of employees. The logic is clear: I give you a set of tools, and your people use them. As for whether the customers are well - served, whether more sales are made, or whether there are fewer errors in contracts, it's mainly the buyer's responsibility.

Later, with the emergence of cloud computing and APIs, software began to be charged based on usage. Each API call, an hour of server operation, or 1GB of storage used costs money. Large models continue this logic, and tokens have become the most common unit of measurement.

Essentially, both of these charging methods are centered around the concept of "tools".

When charging by account, what is being sold is the access to the tool. When charging by usage, what is being sold is the consumption of the tool. There is still an organizational process between the buyer's desired result and the purchase: someone needs to configure the system, someone needs to handle the process, someone needs to judge right and wrong, someone needs to finish up, and someone needs to bear the consequences. You buy a hammer, and whether you can build a house depends on your own ability.

AI is starting to loosen this relationship. Because AI is not just a more complex button. It can read text, search for information, call tools, write into the system, generate records, and trigger the next process. The more it is integrated into the enterprise process, the less it resembles a "tool" and the more it resembles an outsourced piece of work.

At this time, the price tags of software also start to change.

Looking back at the company Fin, it can set prices in this way because the customer service scenario is naturally close to the concept of results.

If charged by conversation, the more the robot talks, the more money it makes. If charged by tokens, the more the model consumes, the more money it makes. When charged by the result of handling, the seller only gets paid when the job is done. The buyer only cares about whether the problem is solved, and now the seller's income is also tied to this.

This is also where AI software is differentiating from traditional SaaS. In the past, software companies sold "you can use this system", but now some AI companies have changed their tune and are selling a completed piece of work.

It's worth noting that this form is also starting to move beyond the customer service field. HighRadius, a company doing financial automation, has introduced pay - for - results into reconciliation, accounts payable, and receipt: Its pricing logic is no longer about how many invoices are processed or how many operations are completed, but more about how many processes can be accurately completed end - to - end without manual rework, and it shares the cost savings based on this.

It even funds the deployment before going live and only starts charging after going live. It also needs to write a clear standard with the customer on "what counts as success". In this way, result - based pricing is starting to move beyond the customer service field, which is naturally close to results, and the questions of "what counts as completion" and "how to calculate the money" are being written into contracts.

What is being sold is shifting from "you can use" to "this thing is already done".

02

First, Clarify: What Counts as a "Result"

However, changing the pricing method is a very complex matter that involves more than just the price.

When charging by account, the budget usually goes through software procurement. When charging by tokens,the budget is more like a technical cost. When charging by "completing a task", the budget starts to be closer to business results such as operations, human resources, and outsourcing.

This means that the competitors of an AI software company may no longer be just other software companies. It may start to compete with customer service outsourcing, process outsourcing, content review teams, financial shared centers, and even the enterprise's own operations department.

Once the price tag changes, the industry boundaries also change. It's not enough to just say "pay for results".

The phrase "pay for results" is too easily misused.

Many companies like to say they charge by results, but to sell a job as a billable result, at least four questions need to be answered.

The first question is "what does it mean to be done"?

In customer service, it's relatively easy. A problem being solved, or transferred to human intervention with the context retained, can be roughly defined. But in other scenarios, it's more troublesome.

In manuscript review, does marking the risks count as done, or does it have to be a revised manuscript? In contract preliminary review, is it enough to just point out the problems, or do the replaceable clauses also need to be provided? In financial reconciliation, finding an anomaly is just the beginning; someone needs to confirm it and complete the subsequent process before it can be considered completed.

If the boundaries are not clear, the results cannot be sold.

The second question is "how to prove that it was you who did it"?

Enterprises won't pay for a long - term claim of "I helped you improve efficiency". They need to see records. How long it took manually before and now. How many problems were missed before and now. Which were handled by AI and which were taken over by humans. Where the failed samples are kept and whether they can be reviewed in case of a dispute.

So, result - based charging cannot be supported by just a nice price page. It must be backed by logs, process records, human takeover records, quality statistics, and a review mechanism.

The third question is "how to calculate the money"?

Charging by usage is simple: pay for what you use. Charging by results is much more complicated.

Suppose the user comes back to ask again 72 hours later. Does this count as the previous problem not being solved? If AI handles part of it and then humans take over, how should the fee be calculated? If three problems are solved in one conversation, is it one result or three? If the robot gives a wrong answer but then remedies it successfully, should it be charged?

These cannot be solved by just adding a switch on the product manager's page. In the end, they all need to be included in the contract and reconciliation rules.

The fourth question is "who is responsible if something goes wrong"?

This is the most difficult question and can best show where AI currently stands.

An AI that can only give advice is still just a tool, and you have to bear the consequences of right or wrong. An AI that can take action and write data into the system is a bit like a supplier. But only when it can confidently say "leave this to me", and is willing to remedy, redo, refund, or even compensate when it fails, can it truly be sold as a "completed piece". It takes responsibility when something goes wrong.

Today, the vast majority of AI is still stuck in the first two levels. It can answer, write, and do some things within your authorized scope, but it's still far from being able to say "leave it to me, and I'll take responsibility for the result".

03

Result - Oriented AI Actually Makes Software "Heavier"

Many people mistakenly think that AI will make software "lighter". A chat box and a large model seem to be able to replace a complex system.

Result - based charging is the opposite. It will make software "heavier".

Because once the promised result is "completed and delivered", it can't rely on just a response window. You need to handle the entire chain, including where the tasks come from, who authorizes them, which tools are called, when to transfer to human intervention, and how to conduct the final acceptance.

The customer service robot needs to be connected to the knowledge base, work order system, user identity, historical orders, and human customer service. The contract review tool needs to be connected to the template library, clause library, approval process, and version records. The financial reconciliation tool needs to be connected to invoices, orders, payment flows, and exception handling processes.

These things are not glamorous, but they are the foundation for whether the result can be accepted.

So, AI software moving towards the results layer will not become thinner but heavier, evolving from a "toolbox" into an "execution system".

Result - oriented AI is more like a general contractor: It doesn't necessarily produce every part, but it needs to organize people, processes, tools, rules, and acceptance, and finally deliver an acceptable piece of work. This is why AI companies that can truly charge by results often not only have strong model capabilities. They also need to understand processes, industry rules, exception handling, and how the customer conducts internal acceptance.

04

Whether It Can Be Charged Depends on How to Accept the Results

Some time ago, I packaged a set of manuscript review capabilities into a Skill so that AI could directly read and execute it: What counts as a risk, where to set the threshold, when to transfer to human intervention, and what format to output. But the most valuable things in this set are precisely the ones that are hard to keep secret once written down: Which risks need to be escalated, why the threshold is set at this line, and how to handle marginal cases.

This is exactly the dilemma of current Skills. For AI to use them, they need to be read and executed, which means they are exposed. Once a Skill is handed to the buyer in black and white, it can be copied at a glance, and the seller's unique features will soon no longer be unique. The more an ability is written based on rules and documents, the more it can't avoid this problem.

So, in high - value scenarios, the valuable things won't be put on the table.

What is exposed to the user is an interface and an agreement on input and output. The most core judgments such as evaluation sets, upgrade standards, exception handling, and continuous calibration are...