writing

NC · article

Outcome-Based Pricing for AI: RaaS vs SaaS, and What to Check

AI vendors are moving from seats to results: per resolution, per outcome, per qualified lead. That shifts one risk to the vendor and hands the buyer a new one: who defines the result, and who counts it.

by Nic Chin11 min readAI Pricing / AI Agents

part of Hiring and Scoping AI Work · 10 articles

The short answer: RaaS, or Results-as-a-Service, prices AI software by what it achieves instead of by seats. It is a real shift and a sensible one, but it does not remove the risk of paying for AI that does not work. It moves that risk into a definition. The vendor usually writes the definition of an outcome, runs the system that decides when one happened, and sends the invoice. Before you sign, the most important thing to negotiate is not the price per outcome; it is how an outcome is defined, counted and checked.

RaaS vs SaaS in One Table

A note on the name first. Searched on its own, “RaaS” returns a hormone system, and in security it means ransomware-as-a-service. Buyers and vendors mostly say outcome-based pricing, pay per resolution or service-as-software. They describe the same shift.

SaaS compared with Results-as-a-Service
 SaaSRaaS / outcome-based
You pay forAccess: seats, plans, usageA counted result: a resolution, a qualified lead, a processed document
Who carries the risk it doesn’t workMostly youMostly the vendor
The new riskShelfware: paying for seats nobody usesDefinition drift: paying for results that were counted, not achieved
BudgetingPredictableVariable, usually with a minimum commitment underneath
What you need to checkAdoptionThe meter: how each outcome is decided, and whether you can see it

The economic argument for the shift is large. Foundation Capital’s service-as-software thesis puts the opportunity at $4.6 trillion: roughly $2.3 trillion of salaries plus $2.3 trillion of outsourced services that software could now perform rather than assist. If software does the work, it is natural to price it like work.

How Four Vendors Define an Outcome

These are the published definitions as of 16 October 2026. They are not the same, and the differences are where the money is.

How AI vendors define a billable outcome
VendorPriceWhat counts
Intercom Fin$0.99 per outcome, at most one per conversationA resolution, where no further help is requested after Fin’s last answer, or a completed hand-off procedure, which is billed even though a person takes over. Minimum commitments apply.
ZendeskPer automated resolutionFor email and web forms, a conversation inactive for 72 hours with positive or no feedback, no human reply, and an LLM check that the answer was relevant. Messaging uses a shorter window.
Salesforce Agentforce$2 per conversation; $2 per resolution for the Help Agent; Flex Credits per actionNot defined on the pricing page. An executive told CIO.com that an escalation to a human is not a resolution, with a 1,000-resolution minimum.
SierraPer outcome, agreed per customerCriteria agreed upfront for each outcome; an unresolved conversation is “in most cases” not charged. No public detail on disputes.

Read the Zendesk definition closely and you can see the shape of the problem. Silence for 72 hours counts as success. A customer who gave up and phoned instead is, by that rule, a resolution. That is not bad faith: inactivity is a reasonable stand-in when you cannot observe the customer’s satisfaction. But it is a stand-in, chosen by the party that bills for it.

The Real Problem Is Measurement, Not Price

Bain’s survey of around 200 B2B software companies found only about 10% rely on outcome-based meters; most still price by output or effort. Bain’s explanation is that an outcome has to be observable, uniquely attributable to the AI and contractible before you can bill for it. Most outcomes fail at least one of those tests.

TechTarget’s reporting on outcome-based AI pricing puts the buyer’s position plainly: the party choosing the stand-in is the party sending the invoice, and there is no standard that makes one vendor’s price per resolution comparable with another’s.

This is an engineering problem before it is a commercial one. Counting outcomes honestly needs three things most AI products do not have on day one: a written definition of the outcome, an evaluation set that tests whether the system’s own judgement of “resolved” agrees with a human’s, and a record of every billed outcome that someone outside the vendor can inspect. I have built the first two for my own systems; the gap between what a system reports and what an independent check finds is usually larger than anyone expects. In one of mine, retrieval found the right document 94% of the time across six benchmark suites while only 74% of answers passed end to end. A meter that counted retrieval would have billed for 20 points of failure (the full breakdown is on the benchmarks page).

Eight Checks Before You Sign an Outcome-Based AI Contract

  1. The definition is in the contract, word for word, not on a help page the vendor can change. Zendesk’s own help article notes that accounts moved to a new resolution model on 18 May 2026.
  2. Hand-offs are priced explicitly. Is an escalation to a person free, billed as an outcome, or billed as something else?
  3. Silence is not success unless you agree it is. Ask how a customer who switched channel is counted, and whether reopened tickets reverse the charge.
  4. You get a record per billed outcome: ID, timestamp, the rule that fired and any model check that confirmed it. Without it, the invoice cannot be audited.
  5. You can sample and dispute. A right to review a sample each month, mark it against the definition, and get credits for misclassified outcomes.
  6. Minimums and platform fees are visible. Many per-outcome prices sit on top of a minimum commitment. Model the bill at your real volume, not the vendor’s example.
  7. You keep the evaluation set. If the vendor’s accuracy claims are tested on their data, build your own labelled set of real cases. It is the only thing that lets you compare vendors or leave one. How to build one is in building an LLM evaluation set.
  8. The data path is the same as any AI vendor. Outcome pricing changes the meter, not the security questions: what the agent can reach, what it logs and where the logs go. The LLM security checklist covers those.

If You Want to Sell Your Own AI Product by the Outcome

Gartner expects that by 2028 over half of enterprises will favour platforms that commit to workflow results over assistive AI. If you build AI products, your buyers will start asking for outcome pricing. The architecture has to support it before the pricing page does:

  • An outcome event in code, emitted at one place, with the rule that produced it. Not inferred later from analytics.
  • An audit record per outcome, append-only and joined to the full trace of the run, so a customer’s dispute can be answered from evidence. What to record is in LLM audit trail.
  • A false-outcome rate you measure yourself. Sample billed outcomes, have a person mark them, and publish the error rate to customers before they find it.
  • Cost per outcome, not cost per call. One resolution can take three model calls or thirty. Gartner expects generative AI’s cost per resolution to exceed $3 by 2030, so a fixed price per outcome needs a ceiling on the work behind it.
  • A gate that refuses to claim what it cannot prove. On a multi-agent system I built, the public results endpoint has a gate that reports when the evidence does not support a claim of skill, and it says so in public. The case study explains how. An outcome meter should be able to do the same.

Where Fixed-Scope Work Fits

Professional services are moving the same way. McKinsey has said about a quarter of its global fees now come from outcome-based arrangements. Bain’s point still applies to consultants, though: outcome deals are slow to negotiate, because someone has to define and measure the outcome first.

I price my own work in the middle. Every engagement is sold as a defined result with a fixed price agreed before work starts, never by the hour: a discovery sprint that ends in a prototype, an architecture document, an evaluation set and a fixed build estimate; an AI security and architecture review that ends in a ranked fix list. That is not pure outcome pricing, and I do not call it that. It is the honest version available before an outcome has been defined and measured, which is usually the work the engagement exists to do.

Frequently Asked Questions

What is RaaS (Results-as-a-Service)?

Results-as-a-Service is software, usually an AI agent, priced by the result it produces rather than by seats or usage: a support conversation resolved, a lead qualified, a document processed. It is also called outcome-based pricing or outcome-as-a-service. The vendor carries more of the risk that the software does not work; the buyer takes on a new risk, which is how the result is defined and counted.

What is the difference between RaaS and SaaS?

SaaS charges for access, typically per seat per month, and leaves it to you to get value from it. RaaS charges for a counted result. With SaaS the question is whether your team will use it; with RaaS the question is whether the thing being counted is the thing you value, and who decides when it happened.

What counts as a resolution in AI pricing?

Whatever the vendor’s definition says, and the definitions differ. Intercom bills when no further help is requested after Fin’s last answer, and also when a hand-off procedure completes. Zendesk counts an email or web-form resolution after 72 hours of inactivity with no human reply and an LLM check that the answer was relevant. Salesforce’s pricing page does not define one; an executive told CIO.com that an escalation to a human is not a resolution.

Is outcome-based pricing cheaper than SaaS?

Not necessarily. It moves cost from licences you might not use to results you might count generously. Check for minimum commitments and platform fees underneath the per-result price, and model the bill at your real volume. Gartner expects the cost per resolution for generative AI in customer service to exceed $3 by 2030, so per-result prices are not guaranteed to fall.

How do you audit an outcome-based AI invoice?

Ask for the record behind each billed outcome: the conversation or job ID, the timestamp, the rule that classified it as an outcome and any model check that confirmed it. Sample at least a few dozen a month and mark them yourself against the contract definition. If the vendor cannot give you per-outcome records, you cannot audit the invoice, only trust it.

Negotiate the Meter

Outcome-based pricing is good for buyers when the outcome is defined by both sides, recorded per event and auditable. It is expensive when it is a help-centre definition and a monthly total. If you are choosing between AI vendors priced this way, or designing a product that will be, the measurement is architecture work, and it is cheaper to get right before the contract than after the first disputed invoice. I do that work for teams in the UK, US and Europe; the build vs buy guide is a good place to start.

Ready to discuss your AI project?

Book a free 45-minute call to explore how AI can transform your business. Or if you already have a codebase, get an instant architecture report at SystemAudit.dev No technical knowledge needed, results in 3 minutes.

Or describe your project in the chat, or email nic.chin@nicchin.com

About the Author

Nic Chin is an AI Architect and Fractional CTO who helps companies design and deploy production AI systems including RAG pipelines, multi-agent systems, and AI automation platforms. He has delivered enterprise AI solutions across the UK, US, and Europe, and provides AI consulting in Malaysia and Singapore.