Before You Price an AI Feature, Decide What You Are Counting

Salesforce, Intercom and Zoom sell AI by the action, the conversation, the outcome, the seat, or inside the core plan at no extra charge. Three software companies described how they chose, and their accounts, read against those public price lists, point to four facts to settle before picking a billing unit: what one use costs in terms the customer recognizes, what unit the customer already buys, who sets the end price, and what counts as an outcome. None of the three companies reports revenue from its choice, so this explains the reasoning, not what pays.

Yupana makes controlling software for mid-sized companies. While building it, the team had to decide how customers would pay for the steps a language model performs. A familiar answer was available: an AI quota, a block of credits that each use draws down. Jens Hagel, Yupana's co-founder, said in a written response to PSEEDR that the team instead "chose a visible counter on every AI step over selling an AI quota."

The reason was a number from the company's own pilot. "On our own pilot data, one contract extraction by the language model cost about €0.02, roughly 6,290 tokens," Hagel wrote. "At that price a credit bundle is packaging, and a counter lets each user judge whether a step is worth it." He was equally clear about what he cannot show: "We have no revenue figures yet, so I can't claim the choice has paid off." Hagel co-founded Yupana, which is offered by frag.hugo Informationssicherheit GmbH in Hamburg.

The case is small, but it reverses the usual order of the pricing debate. That debate tends to start with the model: bundle, add-on, credits, usage or outcome. Hagel started with the measured cost of one step that a user would recognize, and the billing choice followed from it.

The same order helps any team pricing an AI feature, including one added to a product customers already pay for. Before choosing a model, settle four facts:

• what one use of the feature costs, measured in a unit the customer recognizes;
• what unit the customer already pays for, and whether it grows with the feature's use;
• who sets the price the end customer sees;
• if value is the unit, what exactly counts as delivered value.

One AI product, several meters

The evidence comes from two kinds of source. Three software companies described their own decisions in writing; PSEEDR did not audit their figures. Large vendors' public pricing pages show which units they actually sell, and those pages establish the first point: the unit is a choice.

Salesforce's Agentforce pricing page lists one product family under several units. Flex Credits cost $500 per 100,000 credits, and the page's worked examples price one action at 20 credits, or $0.10. Customer-facing agents can instead be bought at $2 per conversation, and Help Agent resolutions are listed at $2 each. For employees, the page offers a $5 per user monthly licence that still draws on Flex Credits, $125 per user per month add-ons described as "Unmetered Agentforce usage for employees", and an Agentforce Coworker licence at $50 per user per month with all Coworker searches included. Flex Credits and Conversations "will not be supported in the same org," so an organization picks one of those two meters. The page says it is subject to change; these are the figures it listed in early November 2026.

Intercom splits Fin in a similar way on its pricing page. The Fin AI agent costs $0.99 per outcome, with a minimum of 50 outcomes a month when it runs on another vendor's helpdesk, or alongside a $19 monthly seat on Intercom's own helpdesk. Copilot, the assistant for human support agents, costs $35 per user per month. Operator, part of a Pro add-on, is measured in credits, with extra credits at $0.01 each.

Read side by side, the two price lists show a tendency rather than a rule. Both vendors sell per-person prices for AI that assists employees during their working day, and Salesforce sells some of that use unmetered, although it also offers a metered route through the $5 licence. When the AI acts for the buyer's own customers, both vendors count events. Even then they disagree about which event. Flex Credits charge for each action. Fin's page says, "You're only charged for one outcome per conversation, even if Fin takes multiple actions." The same kind of support work is priced by different units.

That is PSEEDR's reading of two price lists; neither vendor states it as a policy. It still changes the question a pricing team should ask. The question is not only whether to meter, but what one unit should be and who will watch the count.

Fact one: what one use costs, in a unit the customer recognizes

Hagel's figure is useful because its unit is a contract extraction, a task his users ask for. Model providers bill in tokens. Customers do not think in tokens.

His two numbers can be divided. €0.02 for about 6,290 tokens works out to roughly €3.20 per million tokens, blended across whatever mix of input and output the step used. Hagel did not say which model produced the figure or how the tokens split, and PSEEDR has not checked it against a provider's price list. Treat it as one company's pilot measurement. Its value for other teams is the method: take a task the customer recognizes, count its tokens in your own logs, and price those tokens at your provider's rates. As an illustration only, not Yupana data, a user who ran 200 extractions in a month at Hagel's measured rate would cause about €4 of model cost.

At that size, consider what a credit bundle does. A bundle converts an uncertain cost into a prepaid allowance. That protects the vendor's margin when one use is expensive, or when use varies widely from customer to customer, and it gives the buyer a spending ceiling. When one use costs a couple of cents and the cost is known, most of that protection is unneeded. What remains is a second unit the customer has to learn and track, which is what Hagel means by "packaging". A counter does a different job. It shows the cost at the moment a user decides to run a step, and it leaves the judgment to that user.

That comparison is PSEEDR's analysis of Hagel's reasoning. Nothing in his account shows that the counter improves adoption or margin. His choice also depends on conditions that may not hold elsewhere. It would weaken if the cost of one step varied by large multiples, for example with document length; if one customer's use could grow without limit; or if buyers needed a fixed annual budget more than per-step judgment.

Dora Bloom, chief revenue officer at iotum, described a rule in her own written response to PSEEDR that starts from the same measurement. Her rule is that "if the cost of a capability rises with how much it gets used, bill it that way," while a feature that is part of everyday use of the product should be bundled. The rule is hers, and later sections test it against her own company and against a large vendor that breaks it on purpose. Its first half still depends on Hagel's kind of measurement. A team cannot know how cost rises with use until it has measured the cost of one use.

Fact two: the unit the customer already buys

MentorCity sells mentoring software to companies, schools and nonprofits. Its enterprise page says the platform is "quoted rather than listed, and priced on the number of active participants in your programs." The same page describes AI notetaking that runs inside the platform's video conferencing.

Shawn Mintz, MentorCity's CEO, said in a written response to PSEEDR that "the AI we have shipped so far went into the plan people already pay for rather than being sold as a separate line." He gave the licence unit as the first reason: "Our licence is counted by active participants, so what a customer pays already tracks the size of their program." A separate feature charge, he wrote, "would have hit the schools and nonprofits with the least room to absorb it." He also rejected billing by the session, because it "would push a program to count the wrong thing." Notetaking reduces a program manager's administrative work, but in his words it "is not a thing anyone shops for on its own." His conclusion: "So there is no revenue story to report." He added that MentorCity's newer AI work is still in development and that nothing has been priced separately.

MentorCity's enterprise page confirms the per-participant licence and the notetaking feature. It does not say how AI features sit within its packages, so the in-plan decision and its reasons are Mintz's account.

The existing unit can carry the feature for a structural reason. Notetaking runs during sessions, and sessions happen between the participants the licence already counts. While each participant's use stays within a normal range, the feature's cost grows roughly with the number the customer already pays for. That is PSEEDR's inference from how the product is structured, not a cost figure MentorCity reported. It fails under the same condition that breaks flat pricing elsewhere: when a few participants can use the feature far more than the rest.

Mintz's "count the wrong thing" makes a second point. A meter is also an incentive. A price on each mentoring session would put a cost on the behavior the program exists to encourage. Salesforce's unmetered per-employee add-on reflects a similar logic for internal users: a flat per-person price removes the reason to ration use. The page does not state that motive, so the parallel is PSEEDR's reading.

The test for a team is two questions. Does the licence unit already grow with the AI feature's use? Would a new meter put a price on the behavior the customer bought the product for?

Fact three: who sets the end price

iotum's own pages describe a communications platform "white-labelled for service providers". Its white-label page addresses managed service providers, PBX vendors and carriers, and offers them video and messaging "under your own plans, rates, and brand identity." Its partner page tells partners, "You control pricing, packaging, and billing." The current pages list "AI transcriptions and sentiment insights" among the meeting features, and the home page pitches the reseller offer with "No add-ons, no upsells, no surprise line items." The partner page also mentions "Bundled and modular pricing", and iotum does not publish what partners pay. The pages therefore do not show whether iotum's AI features carry a separate charge to partners.

Bloom said that iotum folded an AI assistant into its meeting product, and that it has been part of the platform "since the late 2010s". She tied the decision to the channel. "We sell to service providers who white label the platform and price it for their own customers," she wrote, and "a separate AI line item would have made every one of them reopen their own packaging and their own contracts to pass it through." In her account, "The assistant became a reason to choose the platform rather than a revenue line of its own." The company's pages do not date any AI feature or use the word assistant, so the history, the reasoning and the outcome are Bloom's account. If her dating is right, the decision also predates current language-model pricing, so it says more about the channel than about inference cost.

What the case adds is a fact that many pricing discussions skip. When partners set the end price, a new line item from the vendor is not one pricing decision. It is one decision for each partner, who must choose whether to pass the charge on, absorb it or rebuild their own packages. That is PSEEDR's inference from iotum's partner terms and one executive's account. It is not evidence that channel sales require bundling, and the case does not show what happens with partners who already resell metered services.

Fact four: if you charge for outcomes, what counts

Outcome pricing promises the closest link between price and value, and Fin's pricing page shows that the definition of an outcome is part of the product. A billable outcome is one of five events: a resolution; a procedure handoff, when Fin completes a procedure the customer configured to end with a human; a disqualification, when Fin finds that a sales prospect does not meet the customer's criteria; a self-serve routing, such as directing a prospect to sign up for a trial; or a qualification. The first four cost $0.99 each. A qualification costs $9.99. "You're not charged when a conversation is simply passed to your team without an outcome," the page adds.

The resolution itself is a proxy. The page defines it as "No further help is requested after Fin's last answer." A customer whose problem was solved requests no further help, but so does a customer who gave up. As written on the pricing page, the definition does not separate the two. That is PSEEDR's reading of a one-line definition, and Fin may apply checks the page does not describe. The definition is reasonable and observable, and it still counts something different from "the problem was solved". Salesforce lists $2 per Help Agent resolution beside $2 per conversation, so on one price list the same price buys two different events. Intercom's own guide to AI agent pricing acknowledges that definitions of what counts as a resolution vary between vendors.

For a team that wants to price its own AI feature by outcome, the order of work follows. Write the counting rule before setting the price. Decide who determines that an outcome happened, from which data, within what time window, and how a customer can dispute it. Without that rule, an outcome price works like a per-event price whose events the customer can contest.

Bundling pays for the AI from the core price

Zoom took the opposite route from metering. In a September 2023 announcement, Zoom said its generative AI assistant, AI Companion, was now included at no additional cost for customers with paid Zoom user accounts. Zoom presented the move as a challenge to the industry's pricing model, and its product pages still describe the assistant as included with paid services. Those paid plans are themselves priced per user per month, so the bundled assistant rides on a per-person unit, much as MentorCity's notetaking rides on a per-participant one.

A generative assistant's compute bill grows with every summary and draft it produces. Zoom is therefore bundling a feature whose cost follows use, which is the case Bloom's rule says to meter. In the same announcement, Zoom said its approach combines its own large language models with third-party models in part to lower costs. That pairing is telling. A company that bundles a usage-variable feature has a strong reason to work on the cost of each use, because no customer pays for that use directly. Bloom's own outcome describes a similar aim: an AI feature that helps win the platform sale rather than producing its own revenue line.

Bundling a usage-variable feature is not a pricing error. It is a decision to pay for the feature from the core subscription, because the feature helps sell or keep that subscription. It works under two conditions: use per account must stay bounded enough that heavy users do not erase the core plan's margin, and the feature must protect a sale the company would otherwise risk losing. Neither Zoom's announcement nor Bloom's account includes cost or margin data, so these conditions are PSEEDR's inference, not their findings.

If you meter, show the meter

The large vendors that meter AI also sell visibility with it. Salesforce says customers can monitor Flex Credit consumption "in near real time" in its Digital Wallet and "get proactive threshold alerts". If a customer exceeds its balance, "There is no overage penalty": usage is billed at the contracted rate monthly in arrears, and Salesforce points customers to the alerts to prevent overages. Fin's page offers "configurable alerts, limits, and real-time reporting", and Operator credits come with hard limits. Hagel's counter on every AI step is the most granular version of the same idea.

The pages show that at these vendors metering ships with visibility and limits. They do not show that these controls raise adoption or reduce billing disputes. PSEEDR's inference is narrower: a meter the customer cannot see produces bills that arrive as surprises.

One more detail separates a prepaid bundle from a pay-as-you-go count. Salesforce says "Unused Flex Credits do not roll over into subsequent subscription terms." A prepaid bundle can leave the buyer paying for credits it never used. A count billed only for steps actually run does not have that problem, but Hagel did not describe how, or whether, Yupana bills the steps its counter shows.

What to settle before choosing a unit

The opening question was which facts should decide how to charge for an AI feature. The answer is four facts, in order. Measure the cost of one use in a unit the customer recognizes. Check whether the unit the customer already buys grows with that use. Find out who sets the end price. If the unit is an outcome, write down what counts. With those facts in hand, the options sort by condition. The table below is PSEEDR's synthesis of the cases and price lists above.

The three companies' accounts explain reasoning, not results. None reports revenue figures for its choice. Hagel and Mintz said so plainly; Bloom describes the result as a reason to choose the platform rather than a revenue line. The table shows when each option is coherent, not which one earns more.

One question stays open. Hagel's counter works because each step is cheap and the user can judge it. As the number of steps per user rises, asking someone to weigh every step may cost more in attention than it protects in margin. Where that point sits, and whether it moves when the counter shows a running monthly total instead of a per-step figure, is something only teams that have run both designs can answer.