Enterprise AI: buy an outcome, budget the whole system
A cost model and procurement framework for moving AI from a pilot to a repeatable business process.
Public-source desk research, checked 16 October 2026. Company disclosures describe vendor claims and published terms. Commercial conclusions are Offaxis interpretation. Numerical scenarios are explicitly synthetic. We have not independently tested products or audited private company financials.
Thesis: procurement changes the product
A pilot can be approved because a demonstration looks useful. A production purchase needs an owner, a recurring budget and a defined outcome. Our thesis is that the strongest enterprise AI proposition connects the technical service to an operational result whose cost and quality can both be measured. Neither low token prices nor a long feature list establishes that result.
What the sources support
Claude’s current Enterprise pricing page separates a seat charge from API-rate consumption and describes administrative controls. The relevant commercial fact is the two-part bill: access and actual use are separate budget lines. Exact terms should be checked at purchase. This report does not estimate Anthropic’s margins. [1]
The FinOps Foundation’s AI guidance discusses workload-specific value metrics and the difficulty of comparable benchmarks. Its tools-and-services paper calls for collaboration among finance, procurement, engineering and operations, and for explicit decisions when cost per outcome becomes unacceptable. These are practitioner frameworks, not a representative estimate of every enterprise’s spending. [2] [3]
A complete cost stack
| Cost layer | What to include | Question for the buyer |
|---|---|---|
| Access | Seats, minimum commitments and unused licenses | Who needs access every month? |
| Execution | Inference, repeated attempts, tools and infrastructure | What does one accepted result consume? |
| Integration | Connectors, data preparation and maintenance | Who owns breakages and updates? |
| Assurance | Review, evaluation, controls and incident handling | How is an incorrect result detected? |
| Change and exit | Training, process redesign and migration | What happens if the supplier changes terms? |
Illustrative unit economics
Define cost per accepted outcome as total incremental monthly cost divided by outcomes meeting the agreed quality threshold. The numerator must include failed attempts and human handling; the denominator must exclude incomplete or rejected results.
Synthetic example: a support workflow incurs $3,000 access cost, $2,000 execution cost, $2,000 allocated integration cost and $3,000 review cost per month. At 5,000 accepted resolutions, the total $10,000 costs $2 per resolution. If acceptance falls to 2,500, the cost is $4 even if the model’s unit price has not changed. These inputs are illustrative assumptions, not measured customer results.
For context, suppose an equivalent existing process costs $2.50 per accepted resolution. The first scenario leaves $0.50 per resolution of apparent headroom before uncounted costs; the second does not. That is a comparison to investigate, not a promised saving. Equivalence requires matching case difficulty, service quality and escalation policy. Redeployed employee time is not automatically a cash saving.
Competition happens at several layers
A buyer can assemble a workflow from a general model API, buy a feature from an incumbent software supplier, or purchase a specialist application. Our interpretation: each route trades integration work against control and switching flexibility. An incumbent may reduce setup effort through existing distribution. A specialist may understand one process better. A custom build may offer useful control while creating a maintenance obligation.
The service provider’s defensibility should be tested against the work it removes. A thin interface is easier to substitute than a dependable process with clear failure handling. Yet deep integration can also make deployments expensive. Commercial diligence needs implementation effort and renewal evidence together.
A practical purchase sequence
- Choose a recurring task and define an accepted outcome before selecting a model.
- Record the existing process’s cost, quality and handling time on comparable cases.
- Run a capped pilot that captures retries, review and exceptions.
- Give operations and finance a shared cost-per-outcome view.
- Set expansion, pause and exit thresholds before a large commitment.
Our initial decision rule would be to expand only when comparable outcomes meet quality requirements at an acceptable full cost. Evidence that would change this thesis includes persistent high review costs, low recurring use or integration spending that overwhelms the value of the task. Conversely, steady acceptance and repeatable rollout costs strengthen a supplier’s renewal case. The report provides a decision framework, not a universal return-on-investment forecast.
Sources and evidence
Stay in the loop
Sign up for Offaxis news and updates. Free email signup; paid membership is separate.