Results as a Service Guide: Buying AI by the Result (PDF)

AI agents are increasingly sold by the result: a resolved support request, a matched invoice, a drafted certificate. Published per-result prices in customer service now run from $0.50 to $2 per resolution, and buyers say they want this model far more often than they sign it. The sticking points are the definition of a result, the checks behind each one, and a bill that finance can forecast. This guide covers each in turn: how to write the one-sentence result definition, how to check and log every result, how to set a fair price from a two-week acceptance test with a worked example, the contract terms to ask for, how the model works in regulated pharma and life sciences work, and when per-result pricing is the wrong choice.

Why buyers want to pay for results

AI agents now do work that people used to do, and that has changed what buyers expect to pay for. Foundation Capital described the shift as service-as-software in April 2024 and sized the work software could take on at $4.6 trillion across salaries and outsourced services. Sequoia put it more plainly in October 2024, writing that AI companies now sell work, and in March 2026 it listed insurance brokerage and accounting among the largest services markets within reach.

Customer service vendors were the first to publish prices on that basis. Zendesk introduced outcome-based pricing for its AI agents in August 2024. By October 2026 HubSpot charged $0.50 per resolved conversation, Fin $0.99 per outcome, Zendesk $1.50 to $2.00 per verified automated resolution, and Salesforce $2 per resolution for its Help Agent.

Exhibit 1: Published per-result prices for AI agents, checked October 18, 2026

Product	What one result is	Not billed	List price
HubSpot Customer Agent	A resolved customer conversation	Not defined in detail in the announcement	$0.50
Fin (formerly Intercom)	An outcome, at most one per conversation	Requests for a human, failed procedures, customers who come back for more help	$0.99
Gorgias AI Agent	An interaction resolved without a person	Interactions a person replies to within 72 hours	$0.90 to $1.00
Zendesk AI agents	A verified automated resolution	Escalations, failed verifications, tests and sandboxes	$1.50 to $2.00
Salesforce Agentforce Help Agent	A question that needs no human escalation	Escalations, abandoned chats, negative feedback	$2

Buyers are keener than their contracts suggest. HFS Research found in July 2026 that 76 percent of customer experience buyers were open to outcome-based or gainshare pricing, while 5 percent had such a contract. Surveys of software companies put pure outcome pricing at around 4 to 5 percent of vendors. Services firms are moving faster: TCS told Reuters in August 2026 that about 80 percent of contracts in its finance, HR and business services segment now use outcome measures.

The name varies. HubSpot co-founder Dharmesh Shah called the model Results as a Service in March 2025, although SAS had used the phrase for an analytics service in 2017. We use it because it describes what the buyer receives. The letters RaaS also stand for ransomware and robotics as a service, so we spell the name out.

Define one result before you price anything

Every per-result contract rests on one sentence that says what counts as a result. If that sentence is vague, the monthly bill turns into an argument. We write it during the scoping call, before any code exists, and both sides sign it.

A good definition names the input, the finished output and the point at which the work is done. "An invoice processed" is too loose to count. "A supplier invoice matched to its purchase order and goods receipt, with any variance above 2 percent explained and the record posted for approval in the ERP" can be counted by anyone who reads the log.

The definition also lists what is excluded. Duplicates, test items, documents in a language the agent was not built for and cases that your own policy reserves for a person are written down as out of scope. They go to your team with a reason attached and never reach the bill.

Exhibit 2: Example result definitions for five common first workflows

Workflow	One result is	Checks it must pass	Out of scope
Supplier invoice matching	An invoice matched to its purchase order and receipt, variance explained, posted for approval	PO and receipt found, totals reconcile within tolerance, vendor bank details unchanged from master data	Credit notes, invoices with no PO, first invoices from new vendors
Certificates of insurance	A certificate drafted from the policy and the request, ready for a CSR to send	Named insured, limits and endorsements match the policy, additional insured wording matches the request	Requests that need an endorsement the policy does not have
Promotional material review	An asset checked against the approved claims library, with every flag cited	Each claim matched to an approved reference or flagged, required safety information present	The final medical, legal and regulatory sign-off, which stays with the client's committee
Support requests	A request answered from approved content and not reopened within seven days	Answer cites a current article, no account change without verification, customer did not reopen	Complaints, cancellations and payment disputes
Prior authorization packets	A packet assembled with the payer's required evidence, ready for a nurse to review	Payer form complete, required clinical documents attached, codes match the order	Peer-to-peer reviews and appeals

Check every result and keep the evidence

A result becomes billable when it passes its checks and a named person on your team approves it. The checks run automatically on every item. Some are hard rules, such as totals that must reconcile. Others compare the output with the source document and flag anything the agent could not trace back to it.

Approval is the second gate. In most of the workflows we build, a person approves each result before it reaches a customer, a regulator, a carrier or the ledger. If that person rejects the result or rewrites it, it was not a result and it is not billed. Small edits, such as fixing a typo, are defined in the contract so that they do not become disputes.

Every result is written to a log with its input, the checks it passed, the approver, the time taken and the version of the model and prompt that produced it. The bill is a query on that log. When someone in finance questions a line, they can open the entry and see exactly what happened.

We recommend a monthly sample on top of the checks. A reviewer on the client side re-checks a small random set of passed results, typically 20 to 50, to confirm the automated checks still catch what they should. If the sample finds a result that should have failed, it is credited and the check is tightened before the next month.

Exhibit 3: How a result reaches the bill

A flow from left to right. An item arrives and the agent produces a draft. Automated checks run on the draft. Items that fail go to the client's team with the reason. Items that pass go to a named approver. Approved items are logged and counted, while rejected or rewritten items go back to the team and are not counted. At month end, the count of approved items times the agreed price, or the monthly minimum if that is higher, becomes the bill.

Set the price from an acceptance test

A price per result should come from measured numbers rather than a list price. A two-week acceptance test on your own work gives you four of them: the volume per month, the share of items that pass every check, the minutes a person still spends reviewing a passing result, and the minutes your team spends on each item today.

With those numbers the arithmetic is short. Doing the work by hand today costs the volume times the minutes per item times the loaded cost of a staff minute. After launch your team still handles the items that fail and still reviews the ones that pass. Whatever is left over, divided by the number of passing results, is the most you could pay per result and break even. A fair price sits well under that line, so that most of the saving stays with you.

Exhibit 4: Worked example, supplier invoice matching at 1,500 invoices a month (illustrative numbers)

Line	How it is worked out	Per month
The work by hand today	1,500 invoices at 8 minutes each, $45 an hour	$9,000
Invoices that pass every check	85 percent of 1,500	1,275
Your team on the invoices that fail	225 invoices at 8 minutes each	$1,350
Your team reviewing passing invoices	1,275 invoices at 1 minute each	$956
Break-even price per passing invoice	($9,000 less $1,350 less $956) divided by 1,275	$5.25
The bill at $1.50 per passing invoice	1,275 at $1.50, above the $1,200 minimum	$1,913
Saving at that price	$9,000 less $1,913, $1,350 and $956	$4,781

In this example the price is a little under 30 percent of the break-even line, and the client keeps about $4,800 a month after paying for the results. A $10,000 build is covered in just over two months. The numbers are illustrative. Yours come from your own test, and the calculator on our Results as a Service page runs the same sums on your inputs.

Model usage and hosting sit outside this sum when the agent runs in your own cloud tenant, as ours do. Ask any vendor whether the price per result includes model costs, because the answer changes the comparison more than most buyers expect.

Why finance teams hesitate, and what answers them

The strongest objection usually comes from finance. In Futurum's second-half 2026 survey of enterprise software buyers, per-seat was still the preferred model for separately billed AI, at 42.3 percent against 21.1 percent for outcome-based pricing. In an a16z buyer survey cited by BCG, 36 percent of buyers worried about cost predictability and 47 percent struggled to define clear, measurable outcomes.

Both worries have practical answers. A fixed price per result with a monthly minimum, and a cap where the budget needs one, keeps the bill inside a range finance can forecast. A written result definition with automated checks and open log access settles most arguments about what was billed before they start. We put more effort into the definition than into the price, because a precise definition makes the price easy to agree.

Ask for the bill at your expected pass rate and again at a pass rate ten points higher. If the second number would worry your CFO, agree a cap before you sign rather than after the first good month.

Contract terms that keep both sides honest

A per-result contract shifts risk from the buyer to the vendor, and both sides then have a reason to read the definitions closely. A vendor paid per result has an incentive to count generously. A buyer has an incentive to reject borderline work. The terms below are how we keep those incentives from turning into a monthly dispute.

Exhibit 5: Terms to ask for in a per-result contract

Term	What it says	Why it matters
Result definition	The signed sentence, with what is included and excluded	Settles what can be billed before the first bill
Checks and approval	The automated checks and the person who approves	Makes passing something you can observe
Price per result	One fixed price, or tiers by monthly volume	Lets finance forecast the bill
Monthly minimum	The floor that pays for monitoring and upkeep	Keeps a quiet month workable without padding the price
Monthly cap	An optional ceiling on the bill	Protects the budget if volume spikes
Repricing	When the price can change, and from which logged data	Keeps the price fair as volume and pass rate move
Log access	The buyer can read every result record	Lets finance audit any line
Sampling and credits	A monthly re-check, with credit for results that should have failed	Keeps the checks honest
Model and hosting costs	Who pays for model usage and cloud	Changes the real price per result
Exit	What the buyer keeps: code, prompts, checks and logs	Avoids lock-in to the vendor

Our own terms follow this list. The build is $10,000, paid only when it passes the acceptance criteria you signed. After launch the price per passing result is fixed from the test, the monthly minimum is $1,200, and results that fail a check or that your team finishes are not billed. The agent, its prompts and its logs live in your tenant from the first day.

Results pricing in regulated work

In pharma and life sciences, the final decision on most documents belongs to a person by rule. Promotional material goes through a medical, legal and regulatory review, quality records need a named approver, and system changes follow the company's validation procedures. None of this rules out paying per result. It moves the result one step earlier, to the work handed to the approver.

A result in this setting is a draft that passed its checks and that the approver accepted without rework: an asset with every claim matched to an approved reference or flagged, or a deviation report with its evidence attached. The approver's decision stays theirs. Several of our pharma and life sciences clients pay us on results-based terms like these, and their names stay confidential.

The kind of check that makes this work is shown by a scanner we built for a European pharmaceutical regulator. It reviews advertising against health-claims rules, and review time per asset went from two or three hours to about two minutes. Every flag cites the rule it came from, which is what lets a reviewer accept or reject it quickly.

Systems that support GxP work should be built to the company's validation expectations, with change control over model and prompt updates. A per-result contract in this setting should say who approves a model change and how it is tested before it reaches production, because a model update can move the pass rate and therefore the bill.

When per-result pricing is the wrong choice

Some work should not be priced per result. Where a good output is a matter of taste, such as a marketing concept, a result cannot be checked without an argument. A workflow with a few dozen items a month is better served by a fixed build, because the minimum would make up most of the bill. And when nobody knows what the work costs today, a week of timing has to come before any price.

Costs can also move. Gartner predicted in January 2026 that generative AI cost per resolution in customer service will exceed $3 by 2030, and a McKinsey partner told Fortune that the same agent task can cost up to 30 times more from one run to another. A vendor that prices per result carries that variance, which is fair to the buyer, but the contract then needs a repricing rule that both sides accept in advance.

None of this argues against the model. It argues for starting with one workflow where the result is easy to count, measuring it properly, and adding the next workflow once the first bill has been checked line by line.

What to do with this on Monday morning

Pick one workflow where a finished result fits in one sentence, and write that sentence this week.
Time 30 items by hand to get today's minutes per item, and ask finance for the loaded cost of an hour of staff time.
List the checks a result must pass and name the person who approves it.
Ask every AI vendor what they charge for, what happens to failed attempts and whether model costs are included.
Run an acceptance test on a sample of real work before agreeing any price per result.
Put log access, monthly sampling, repricing and what you keep on exit into the contract.

Sources

Buying AI by the result: a Results as a Service guide for operators and finance teams