Bruce MacVarish, Sr. Director, AI Innovation & Strategy at Oracle, has spent his career building and pricing enterprise software products. This is the first in a series of guest posts from Bruce on GTM strategy in the age of AI.
Artificial intelligence is changing what customers are willing to pay for.
When software mainly automated tasks, the reasonable unit of sale was the seat, the license, or the hour. As AI systems take on more of the work itself, from qualifying leads to resolving support tickets to writing code, the more durable unit of sale becomes the result those systems produce. This is the shift from selling capability to selling Outcomes.
This piece lays out the principles behind an outcomes-based value creation strategy, the go to market practices that support it, and the measurement infrastructure required to make outcome based pricing credible and defensible. It closes with a set of operating recommendations for leaders who want to build or convert a business around Outcomes rather than usage or effort.
The central argument is straightforward. Outcome based selling is only as strong as the measurement layer behind it. Without a rigorous, transparent, and mutually trusted way to define, attribute, and verify results, an Outcomes strategy is just a marketing label on top of a conventional subscription. With that measurement layer in place, Outcomes become a genuine source of differentiation, pricing power, and customer loyalty.
Why Value Creation Is Moving to Outcomes
For most of the software era, vendors sold access. A customer paid for a seat, a license, or a block of compute, and then had to do the work of turning that access into value. The vendor’s job ended at delivery of the tool. The customer’s job began at adoption.
AI changes this arrangement because it closes the gap between access and result. A model that drafts a contract, resolves a support ticket, or qualifies a sales lead is not simply a tool that helps a person do a task faster. In many cases it does the task. When the system itself produces the deliverable, charging for access to the system rather than for the deliverable starts to look arbitrary to the buyer. Why pay for a seat when no person needs to sit in it?
This is the underlying force pushing value creation toward Outcomes. It is not a marketing trend so much as a natural consequence of automation maturing to the point where the system, not the user, is the primary unit of production. Buyers increasingly ask a simple question: what did I get, not what did I have access to.
From Effort to Result
Traditional software and services pricing is anchored to inputs: hours billed, seats provisioned, tickets processed, tokens consumed. Outcome based pricing is anchored to outputs: leads converted, cases resolved, costs avoided, revenue generated. The distinction matters because inputs are easy to measure and hard to connect to value, while outputs are hard to measure and directly represent value. An Outcomes strategy accepts the harder measurement problem in exchange for a pricing model that is naturally aligned with what the customer actually cares about.
Principles of an Outcomes Based Strategy
Principle One: Define the Outcome Before the Offer
An Outcome must be defined in terms the customer already uses to run their business, such as cost per resolution, qualified pipeline generated, or days sales outstanding. If the definition requires inventing a new metric that only exists inside the vendor’s dashboard, adoption will stall because the buyer has no internal frame of reference for judging success.
Principle Two: Price the Result, Not the Mechanism
The pricing conversation should center on the Outcome delivered, with the underlying AI system treated as the mechanism that makes the pricing possible rather than as the product itself. This does not mean hiding the technology. It means keeping the commercial conversation focused on the business result, while the technical conversation, which still matters to technical buyers, happens separately.
Case Study: Intercom Fin
Intercom charges a small fee only when its Fin agent fully resolves a customer conversation, with no charge for failed attempts, and a resolution is counted when the customer confirms it or does not follow up. The Outcome is defined in a metric support leaders already track, and the vendor absorbs the cost of failed attempts rather than passing that risk to the customer. This pairing of a familiar metric with genuine downside exposure is a large part of why the model scaled to tens of millions of dollars in revenue within its first year.
Principle Three: Share the Risk
Outcome based models only feel fair to customers when the vendor accepts some of the downside if results fall short. This can take the form of a lower base fee with upside tied to performance, service credits for missed targets, or an explicit right to exit if Outcomes are not met within an agreed period. A vendor unwilling to share any risk is, in practice, still selling access dressed up in Outcome language.
Principle Four: Make Attribution Explicit
Every Outcome-based arrangement should specify, in writing, how the result will be attributed to the vendor’s system as opposed to other factors already at work in the customer’s business. Ambiguity here is the most common source of disputes and the fastest way to erode trust once a contract is running.
Principle Five: Treat the Outcome as a Moving Target
Markets, customer businesses, and AI capability all shift over time. An Outcomes contract signed today should include a mechanism for revisiting the definition of success, whether that is a quarterly review or a renegotiation clause tied to material changes in the customer’s business.
Go-to-Market Practices for Outcome Selling
Marketing
Marketing for an Outcomes business looks different from marketing for a software product in several concrete ways.
- Lead with the metric the buyer already reports to their own leadership, not with product features or model capability.
- Replace product demonstrations with evidence: audited case studies, before and after figures, and third-party validation where possible.
- Shift category language away from software toward managed Outcomes or performance partnership, since the true competitive set is often internal headcount or a consulting engagement rather than another software vendor.
- Be conservative in public claims. Overstated Outcome claims are more damaging to an Outcomes brand than they would be to a conventional software brand, because the entire pitch rests on credibility of results.
Sales
Outcome based sales cycles tend to run longer at the front end because the buyer, quite reasonably, wants to understand how results will be measured and what happens if they are not achieved. This upfront cost is repaid later through materially higher retention, since a customer who is renewing based on demonstrated results has a much stronger reason to stay than one renewing out of habit or switching cost.
- Build a joint measurement plan with the customer during the sales process, not after signature.
- Use a pilot or proof-of-value period with a small, well-defined workflow and Outcome before committing to a full Outcome based contract.
- Involve finance and operations stakeholders early, since they are typically the ones who must validate attribution methodology.
- Compensate sales on realized Outcomes for at least a portion of variable pay, so incentives do not encourage overselling capability the product cannot back up.
Contracting
Outcome based contracts need more precision than traditional license agreements. At minimum they should specify:
- A written definition of the AI Outcome and the exact formula used to calculate it.
- The data sources and AI systems-of-record that will be used to measure that Outcome.
- The attribution methodology, including how the effect of the vendor’s system will be isolated from other variables.
- The remedy structure if targets are missed, such as fee rebates, service credits, or termination rights.
- A cadence for reviewing and, if necessary, renegotiating the Outcome definition.
Case Study: Decagon
Decagon, a conversational AI platform serving customers with complex, custom multi step workflows, deliberately chose not to price strictly per Outcome. Charging on a narrow per resolution basis created margin risk given how much each customer’s workflow configuration varied, and company leadership has been candid that parsing the definition of an outcome case by case invites exactly the kind of dispute an Outcomes strategy is supposed to avoid. Instead, pricing is anchored to conversation volume while success is still communicated to customers in Outcome terms. The lesson for contracting is that a defensible, low dispute unit of measure is sometimes worth more than a purer Outcome metric that cannot be applied consistently across a diverse customer base.
The Measurement Layer
The measurement layer is the operational and technical infrastructure that makes an Outcomes strategy credible. It is the part of the business that answers three questions on an ongoing basis: what happened, how much of it can be attributed to the system, and how confident are we in that attribution. Everything else in an AI Outcomes strategy, pricing, contracting, retention, ultimately depends on the strength of this layer.
Core Components
| Component | Purpose | Typical Elements |
| Instrumentation | Capture the raw events needed to observe the outcome as it happens | Event logging, API telemetry, integration with the customer’s systems of record |
| Baseline and Control | Establish what would have happened without the system | Pre-deployment baseline period, holdout groups, matched historical cohorts |
| Attribution Model | Isolate the system’s contribution from other factors | Statistical models, incrementality testing, causal inference methods |
| Verification | Confirm the numbers are accurate and not manipulated | Third party audit rights, reconciliation with customer data, anomaly detection |
| Reporting | Present results in terms the customer already trusts | Shared dashboards, agreed reporting cadence, joint sign off on figures |
Baselines and Counterfactuals
The hardest and most important part of the measurement layer is establishing a credible counterfactual: what would have happened if the system had not been used. Without this, any observed improvement is only correlated with the system’s presence, not proven to be caused by it. Common approaches include running a baseline period before deployment, holding out a control group that continues using the prior process, or building a matched comparison from historical data with similar conditions. The right choice depends on the customer’s tolerance for a controlled rollout and the size of the population being measured.
Attribution Discipline
Attribution should be treated as a discipline with its own standards, not an afterthought layered on top of a dashboard. This typically means separating correlation from causation explicitly in reporting, disclosing confidence intervals rather than single point estimates, and being willing to report a smaller, defensible number rather than a larger, contestable one. Vendors that consistently under-claim and overdeliver on Outcomes build far more durable pricing power than those that do the reverse.
Case Study: Zendesk Automated Resolution
Zendesk’s automated resolution pricing infers a successful Outcome from signals such as a customer accepting a help center article, but falls back to a simple rule when no explicit signal is available: an issue is treated as resolved once there has been no further communication for seventy-two consecutive hours. The gap this exposes is a textbook measurement layer failure. Silence is not evidence of satisfaction. A customer who quietly gives up and takes their business elsewhere passes the same automated check as a customer who is genuinely satisfied, and both are billed identically as a successful Outcome. The case is a useful warning that a metric can be precisely defined and consistently measured while still being a weak proxy for the result the customer actually cares about.
Governance and Trust
Because Outcome based revenue depends on figures the vendor itself often calculates, governance matters as much as technology. Practical mechanisms include giving customers read access to the underlying data rather than only the finished report, offering third party audit rights for high value contracts, and publishing a clear methodology document that does not change without notice. Trust in the measurement layer is the actual product being sold in an Outcomes business, even more than the AI system that produces the result.
Data and Privacy Considerations
Measurement often requires access to sensitive operational data, which introduces its own obligations. A well-built measurement layer minimizes the data it collects to what is strictly necessary for attribution, applies appropriate access controls, and is explicit with customers about what is retained, for how long, and for what purpose. This is not only a compliance matter. Customers who trust how their data is handled are far more willing to share the data needed to prove Outcomes in the first place.
Organizational Implications
Moving to an Outcomes model changes incentives and responsibilities across the business, not only in sales and marketing.
- Customer success shifts from a retention function to a revenue function, since the team responsible for proving and expanding Outcomes is directly connected to renewal and expansion revenue.
- Product and engineering need to build measurement and reporting as first class features rather than internal analytics, since customers will rely on them directly.
- Finance needs new revenue recognition practices for contracts where fees vary with performance rather than usage.
- Legal and contracting need standardized language for attribution methodology and remedies, so each deal does not require building this from scratch.
Recommendations for Operating an Outcome Focused Business
The following recommendations summarize how to put the principles above into practice.
- Build the measurement layer before scaling Outcome based pricing. A strong measurement capability applied to a handful of accounts is worth more than a broad rollout built on weak attribution.
- Start with pilot engagements that use a narrow, well-defined Outcome and a clear baseline, then expand the model once the methodology has been tested with real customers.
- Share risk deliberately. Structure a portion of every Outcome based contract so the vendor is exposed to the downside of missed targets, not only the upside of results achieved.
- Give customers visibility into the data and methodology behind the numbers, rather than presenting only a finished report. Transparency is what converts a claimed Outcome into a trusted one.
- Align internal incentives, particularly in sales and customer success, with realized Outcomes rather than bookings or usage alone.
- Revisit Outcome definitions on a fixed cadence. What counts as success in a customer’s business today may not be the right measure in eighteen months.
- Report conservatively. A business that under-claims and consistently delivers builds far more pricing power over time than one that overstates results and must walk them back.
- Treat the measurement layer as core infrastructure, funded and staffed with the same seriousness as the product itself, since it is what makes every other part of the Outcomes strategy credible.
Conclusion
Outcome based value creation is a natural next step as AI systems take on more of the actual work customers used to pay people or software to help them do. The strategy is appealing because it aligns price with value in a way that seat based or usage-based models rarely achieve. It is also considerably harder to execute, because it depends on a measurement layer capable of proving, not merely asserting, that a result occurred and that the vendor’s system caused it.
Businesses that invest early in rigorous baselines, honest attribution, and transparent reporting will be the ones able to charge for Outcomes credibly and retain customers who renew because they have seen proof, not because they signed a long contract.
In an AI driven market, the measurement layer is not a supporting function behind the product. It is the product that makes everything else sellable.
