Before You Pay an AI Vendor Per Outcome, Define the Outcome

AI vendors are beginning to charge for completed work instead of seats. Buyers like the idea. G2's 2026 AI Agents Insight Report found that preference for pay-per-outcome pricing rose from 11 percent to 19 percent in a year, while preference for fixed pricing fell. That makes sense. If software is doing work, why pay for access when you can pay for the result?

The hard part arrives one sentence later: What exactly is the result? A task can be completed by the system and still rejected by the person who requested it. It can be accepted by that person and still fail to change the business metric that justified the purchase. Those are three different events, and a pricing model that calls all three an outcome creates a disagreement waiting to happen.

One word is covering three different things

Delivered work is the easiest event to count. The agent answered a ticket, generated a qualified lead, reconciled a transaction, or completed a configured workflow. The system can usually record that event without human interpretation. Delivery proves that the agent acted. It does not prove that the work was correct, useful, or durable.

Accepted work adds a validation step. A customer confirms that the answer helped. An employee approves the analysis. A downstream system accepts a clean record. Acceptance is closer to value because somebody or something outside the agent has evaluated the result. It still may not be the result the business ultimately cares about.

A business outcome is the change that justified deploying the agent: lower cost per resolved case, faster cash collection, higher conversion, fewer errors, shorter cycle time, or more retained customers. That result often appears later and depends on factors beyond the vendor's system. It is the most meaningful level and the hardest one to attribute cleanly.

None of these definitions is automatically right. A vendor may reasonably charge for a delivered action when the buyer controls every later step. A buyer may reasonably require acceptance when quality is part of the promise. The problem starts when the contract says outcome and each side quietly supplies a different definition.

Intercom shows why the details matter

Intercom's Fin documentation offers a useful public example because it spells out the meter. A support resolution can be confirmed by the customer or assumed when the customer leaves after receiving an answer without asking for more help. If that customer later returns to the same conversation seeking further assistance, the earlier resolution is deducted and is not charged. Intercom also documents which handoffs, escalations, and failed procedures are billable.

That definition may or may not fit every support organization, but a buyer can inspect it. The assumed-resolution rule, return behavior, one-charge-per-conversation policy, and usage controls turn a vague commercial promise into events that can be tested. This is what outcome pricing needs: a definition precise enough that finance, operations, and the vendor can reconstruct the same bill.

Write the validation rule before the invoice arrives

The validation rule should identify who or what can accept an outcome, how long that decision stays open, and what evidence closes it. Explicit customer confirmation is strong evidence. Silence may be a workable proxy in a high-volume workflow, but the buyer should know the inactivity window and test how often silence hides dissatisfaction. Automated acceptance can work when the downstream condition is objective, such as a record passing required checks.

• Acceptance authority: name the person, customer action, system event, or test that can validate the work.
• Validation window: state how long an outcome remains provisional before it becomes billable.
• Quality threshold: define the accuracy, completeness, policy, and service requirements that the work must satisfy.
• Sampling rights: preserve the buyer's ability to inspect a representative set of outcomes, including failures and edge cases.
• Dispute path: set a practical process and deadline for challenging events that do not meet the definition.

Avoid making the vendor's own success label the only acceptance evidence. The agent is part of the system being measured. A durable arrangement includes a signal from the customer, a human reviewer, or the buyer's downstream system. For high-volume work, that can be a statistically useful sample rather than a person reviewing every event.

Decide what rework does to the meter

Rework is where attractive pricing models often become confusing. If the agent produces a draft, receives corrections, and produces a second draft, was that one outcome or two? If a support issue reopens next week, does the earlier resolution reverse? If a record is accepted and later found to contain a material error, can the buyer claw back the charge?

These questions need rules for retries, reopenings, reversals, duplicates, partial completion, and work finished by a human. The rule should follow the business process. A customer problem that returns because the answer failed is usually not a second success. A new problem in the same conversation may be. A human correcting an agent's material mistake should not make the original attempt look fully automated.

Require evidence that survives a billing dispute

An outcome record should connect the charge to the work. At minimum, I would want an event identifier, timestamp, workflow and version, outcome type, acceptance signal, validation window, reversal status, and enough context to inspect the event without exposing unnecessary sensitive data. If a human intervened, that should be visible too.

The buyer should be able to export this evidence and reconcile it with an invoice. Aggregate dashboards are useful for operating the program, but they are not a substitute for event-level support when the count is questioned. The evidence also needs a retention period long enough to cover reopenings, credits, and the buyer's normal audit cycle.

Put seven terms in the contract

• The exact billable event and every excluded event.
• The validation method, acceptance authority, and provisional period.
• The treatment of retries, rework, reopenings, reversals, duplicates, and human completion.
• The evidence attached to each charge and the buyer's export and audit rights.
• The dispute, credit, and correction process, including deadlines for both sides.
• Spend caps, alerts, forecast assumptions, and the behavior when a cap is reached.
• A change-control rule for definitions, model behavior, workflow versions, and pricing.

Then test the definition on real work before expanding usage. Pick a bounded cohort, run the vendor's count beside the buyer's count, inspect disagreements, and calculate the cost per accepted result and the cost per business result. The goal is not to negotiate a perfect universal definition. It is to learn whether the commercial unit matches the operating value in this workflow.

Manage the outcome, not just the invoice

Outcome pricing can create healthy alignment, but the invoice is only one view. Leaders also need to see which tools and agents are producing the work, which workflows they serve, who owns them, what the organization is spending, where adoption is growing, and whether accepted activity is connected to a business result. Without that operating context, a precise billing definition can still fund the wrong workflow.

Proxon brings usage, tools, agents, workflows, ownership, spend, adoption, and outcomes into one management view. It does not decide whether a vendor's charge is contractually valid. It gives leaders the evidence to compare activity, cost, ownership, and results as they decide where an outcome-priced program should expand.

Paying for results is a sensible direction for AI software. Just do not let the word outcome do all the work. Define the event, the evidence, and the reversal before the first invoice makes the ambiguity expensive.