The useful answer
Compare providers on the full cost of an accepted outcome. Define quality, exclusions, rework, and exit terms before treating a completed action as delivered value.
Read the headline as a procurement question
“Stop buying software” is deliberately provocative. Many businesses still need durable software capabilities and people who understand them. The useful question is whether a particular purchase should be evaluated as access to a tool, delivery of a service, or a combination of both. Changing the billing label does not answer that question.
An AI supplier may price by seat, usage, task, or outcome. Each structure can fit some workflows and distort others. An executive should first decide what work the organization actually wants completed and how it will know that the result is acceptable. Only then does the pricing model become meaningful.
Choose a unit that represents business value
The FinOps Foundation distinguishes resource-efficiency measures from business unit measures. A lower cost per technical operation does not automatically show a better business result. Procurement can use that distinction to compare the cost of accepted work with the cost of simply producing more activity.
Write the acceptance rule before the price comparison
Consider a hypothetical support operation comparing a per-seat assistant with a service priced per resolved case. If “resolved” means the service closed the ticket, the provider may be paid even when the customer returns with the same unresolved issue. A useful acceptance rule would define the relevant customer outcome and the treatment of reopened cases.
The buyer also needs to classify cases that the service should not handle. A technically difficult question, a sensitive complaint, or an exception requiring management authority may properly go to a person. Excluding those cases can be sensible, but their cost still belongs in the business comparison. Otherwise the proposal makes easy work visible and hides the remainder.
Build the comparison from a representative mix of work rather than a supplier-selected demonstration. Keep the same quality standard for the existing process and the proposed service. If the new system changes which cases enter the measurement, explain that change before interpreting any apparent improvement.
Inspect the responsibility left with the buyer
NIST’s AI Risk Management Framework is intended to support trustworthiness considerations across the design, use, and evaluation of AI systems. Purchasing an external service still leaves the buyer with a deployment decision and a need to assess its own use context.
Price the work around the work
A provider’s fee is only part of the operating cost. Estimate the time spent preparing inputs, maintaining integrations, reviewing outputs, resolving disputes, handling exceptions, and supporting customers when the service cannot finish. Distinguish one-time transition costs from ongoing costs, and show which assumptions depend on future volume.
For the hypothetical support team, ask whether saved reviewer time can be used to reduce a queue, improve service, or change spending. Those are different outcomes. Available capacity can be valuable without becoming an immediate cash saving. State the intended benefit and the evidence that would demonstrate it.
Consider how the arrangement behaves when demand changes. Minimum commitments, peak-volume charges, and manual fallback costs can make an attractive average price misleading. Model a normal period and a difficult period using clearly labeled assumptions. The purpose is to expose the decision’s sensitivity, not manufacture an impressive return.
Put the awkward cases into the agreement
The following questions are a practical negotiation checklist. Obtain appropriate procurement and legal review for the actual agreement, particularly where service failures could create commitments to customers.
- Acceptance: who decides that a unit of work is complete, using which evidence?
- Rework: when an answer is corrected or a case reopens, what is charged and who performs the repair?
- Exceptions: which work is excluded, and how is it handed back with useful context?
- Changes: what happens when models, tools, prices, or supported tasks change?
- Continuity: who serves customers during an outage or supplier transition?
- Exit: which records can be exported, in what format, and how will the buyer verify removal of retained data?
Buy learning before buying dependency
Structure a bounded pilot so it produces a decision rather than a permanent exception to procurement. Define the work sample, acceptance method, operating owner, and conditions for expansion or stopping. Require enough visibility into unsuccessful cases to understand what the team will inherit at scale.
At review, compare the accepted outcomes, service quality, total operating cost, and obligations that remain with the buyer. A provider might be worth choosing even when its fee is higher if it delivers a more useful and dependable result. Conversely, an inexpensive outcome label may conceal substantial internal work.
The strategic benefit of buying work is a clearer conversation about value. It appears only when the organization can define completion, evaluate quality, and retain the ability to change course. Without those capabilities, “renting work” can become another way to rent uncertainty.
Related speaking resource
For an event or leadership discussion on this topic, explore the AI executive strategy speaking resource.
Common questions
Is outcome-based AI pricing always better than seat pricing?
No. It depends on whether the outcome is measurable, the quality standard is meaningful, and exceptions and rework are fairly allocated. Compare full operating cost and accepted results.
Who owns mistakes when an AI service performs the work?
Responsibility depends on the agreement and workflow. Define correction, escalation, customer communication, and approval duties explicitly rather than assuming outcome pricing transfers them.
Sources & edition note
This refreshed edition retains the original article title and path. It replaces the earlier commentary with an updated discussion; historical predictions and unsupported numerical claims have not been carried forward.
Examples and decision checklists are editorial guidance, not reports of measured client results. Sources reviewed November 4, 2026.