Klarna's 2025 annual report shows transaction count growing 25%, while customer service and operations expenses rose only about 2%. The company also reported that its AI assistant handled 80% of customer-service chats, with human support still available. Klarna 2025 Form 20-F

Business grew faster than expenses

Klarna 2025 Form 20-F · p. 133

In 2025, Klarna’s transaction count grew faster than its customer service and operations expenses.

2025 growth over 2024 (%)
  • Transaction count25
  • Service and operations expenses (approx.)2
View year-over-year growth data
Business grew faster than expenses · 2025 growth over 2024 (%)
Metric2025 growth over 2024 (%)
Transaction count25
Service and operations expenses (approx.)2

Each metric uses its own 2024 value as the denominator. Percentages follow the whole-number figures in the annual report; expenses rose from US$203 million to US$207 million. Transactions are not support cases. This chart cannot separate the contributions of AI, scale, and other factors.

Source

A software buyer can see an attractive result: more business handled at close to the previous cost. A software seller still has questions. How much of the saving will the customer pay you? If one person handles more work, what happens to a bill based on headcount?

I would decide what work the product takes on before choosing the billing unit. Klarna illustrates the demand side. Its report does not tell us how much each software supplier earned, and this chart cannot isolate AI's contribution.

One “completion” can mean three different things

Suppose we sell a returns-processing service. A model reads the complaint, finds the order, and submits a refund instruction. There are at least three possible endpoints: successful execution, a case that meets the contract's closure conditions, and a customer who receives the money and buys again.

The first is easiest for a system to observe. The last may matter most to the merchant, but the supplier controls less of it. Logistics and banking still have work to do, and a repeat purchase depends on more than the return. Charging only for the instruction leaves follow-up with the customer; promising the entire eventual result may take on factors beyond the supplier's control.

Intercom's Fin documentation makes the distinction tangible. For chat and email used with Intercom, a resolution can be confirmed by the customer or assumed when no further help is requested after an answer. A successfully executed, preconfigured Procedure handoff to a human or workflow can also be billable. Each conversation is charged at most once. If a customer later returns to the same resolved conversation for help, the resolution charge is deducted. Fin's outcome and billing definitions

A handoff is not necessarily failure. If the purchased service is investigation and routing, a complete handoff can be worth paying for. Conversely, ending a conversation does not establish that a refund has reached the bank account. The billed outcome is an agreed deliverable, not a substitute for the customer's business benefit.

I would discuss reopened cases, missing information, and handoffs while setting prices. A single price per success can encourage preference for inexpensive cases while difficult ones return to the customer. That is an inference about incentives. Evaluation should examine accepted and rejected work alongside the success count.

Users may leave your interface while the system still earns revenue

The article about apps asks whether coordination can move to a common place. For SaaS, another question follows: must revenue follow the interface?

Atlassian's MCP offers a concrete example. External AI tools can search Jira and Confluence, create work items, or update pages under existing permissions. Its documentation also says retrieving data or generating insights through MCP consumes Rovo credits. Atlassian's announcement, usage documentation

The user can change entry points while official records and execution remain in the original platform. If every assistant must return there to read data, check access, and write results, more entry points may benefit that platform.

A wooden service cabinet separates into three tiers linked by thin cords: a control panel at the top, a mechanical arm moving task cards in the middle, and a drawer holding records and a ledger below.
The interface, execution, and official records can come from different providers. Vertical position does not rank their value.

I would not judge such a product's decline from login counts alone. Why must the customer still go through it: dependable transactions, shared organizational records, or merely data that is awkward to move? The first two provide continuing work. The last may lose bargaining power as alternatives improve.

Nor does a convenient new entry point necessarily collect the largest share. It may compare providers and direct work, but still need the platform that can authorize a transaction. To understand who captures value, follow the job: who has substitutes, who can refuse, and who must still contribute?

The remaining human work determines the cost per case

Executing work can incur model fees, tool calls, retries, and review for each case. Once routine requests are automated, the cases left for people may concentrate missing information, disputes, and unusual rules. Fewer handoffs do not mean easier handoffs.

Pilot's Core plan explicitly includes a bookkeeper who handles, explains, and reviews the books. Software and professional work are delivered together. Human involvement alone does not establish that automation has failed. Pilot's plans

I would distinguish recurring firefighting from work that leaves reusable classification rules, checks, and handoff information. The former requires more experienced staff as customers grow. The latter may lower the cost of similar cases later, though delivery records still need to demonstrate that improvement.

My operating calculation would be:

Include unsuccessful cases from the same period. Do not count retry costs twice if they already sit in model or labor expenses. This is a delivery analysis, not a financial-statement gross-margin formula. Research, sales, onboarding, and initial data cleanup still belong in the economics of the whole business.

Customer-side work matters too. A supplier can lower its own unit cost while forcing the customer to add supervision and repair. That is a poor basis for renewal.

Savings still have to be divided

“We replace expensive labor, so we can charge a lot” establishes the size of the problem, not the price. Alternatives matter. If several products deliver the same refund, the work remains useful while the price can fall. Cheaper models may bring more competitors rather than simply increasing incumbent profits.

Lower prices can also make previously uneconomical work worth doing, expanding demand. I would therefore neither focus only on disappearing seats nor assume outcome pricing must win. Salesforce's Agentforce currently offers user-, conversation-, and action-based options with different conditions. Pricing documentation

Seats can remain understandable for tools used extensively by professionals. Clearly scoped cases may suit per-case billing. Expert availability and continuing service may justify a fixed fee plus volume. Product documentation here was checked on October 27, 2026; this article does not compare changing unit prices.

To build this business, I would start with recurring work whose closure conditions can be stated, including returns, rework, and human time in the calculation. First establish that the customer actually has less work, then test what price that supports. If exceptions keep consuming the margin, I would narrow the service before claiming AI can take over an entire role.