Comparing AI offers: what counts as a billable outcome?

A supplier offers AI at a price per outcome. That sounds closer to business value than a price per request. It also creates a purchasing question: which event triggers the invoice, and what evidence tells the organisation that the work is complete?

As the founder of aiomics, I am interested in this connection between technical capability and a usable result. Service businesses, commercial teams and internal support functions in pharmaceutical companies encounter a straightforward version of the problem: an answer may exist while the underlying task remains open.

What suppliers mean by an outcome

Intercom Fin can charge for an assumed resolution after an answer without a further request for help. A later help request in the same conversation reverses that charge. A successfully completed, specifically configured handoff to a human or workflow can also be billed as an outcome. [1]

Under Zendesk’s tiers introduced in May 2026, an LLM-verified resolution consumes the allowance. Assisted escalations and contained conversations that fail verification do not. [2]

These descriptions were checked on 26 September 2026. They document supplier rules and establish no performance ranking for your organisation. A purchasing decision requires the actual offered model, including its channel, configuration and applicable terms.

I would place two definitions alongside each other: the offer’s billable unit and the organisation’s accepted completed case. Both can have reasonable definitions. Comparing offers requires a traceable mapping between them.

Start with a specific case

Imagine a fictional service company whose customers ask about the progress of their orders. It is trying two AI services. In this example, acceptance requires accurate information about the correct order and a documented next step when there is a delay.

The purchasing team also records which cases are eligible, when a person must take over and how long follow-up requests will be observed. A handoff can be exactly the right response. It remains visible as a handoff so the team can assess its contribution and the work still required. An unanswered contact also remains in the analysis.

This definition belongs before the price calculation. Otherwise, each service can select its own successful cases while difficult work disappears from the comparison. I would assess both offers against the same starting population and report open, excluded and accepted cases separately.

A small calculation with an important boundary

Assume 1,000 eligible cases solely for this illustration. Offer A bills 600 units at one euro each. Offer B bills 400 units at €1.50 each. Both invoices total €600. These figures describe neither real offers nor observed customer outcomes.

The organisation’s review accepts 450 cases under A and 500 under B. These can include cases completed by people, so accepted cases can exceed the number of billed AI units. Invoice cost per accepted case is therefore approximately €1.33 for A and €1.20 for B. The shares of the common starting population remain visible too: 45% and 50%. Here, the lower price per billable unit does not reveal the ranking.

Now assume €900 in additional internal effort under A and €1,400 under B. In this example, these amounts include all internal work on the 1,000 cases that has not been counted elsewhere, including review and handling of open cases. Total costs of €1,500 and €2,000 produce approximately €3.33 and €4 per accepted case. The ranking by cost per accepted case reverses.

These ratios are a snapshot. Open cases and their subsequent costs remain outstanding. A purchasing decision requires comparable observation periods, cost boundaries and remaining services. Setup, base fees and taxes were excluded to simplify the example; relevant amounts belong in the actual calculation. Differences in the quality of accepted results would require separate examination.

Ask suppliers to price five boundary cases

For the next supplier discussion, I suggest a short case exercise. This is my own proposed comparison method, with no claim that it is a scientifically validated assessment scale.

First, an answer arrives and the person goes silent. Which event is billed, and what evidence might still be missing for operational acceptance?

Second, the same person returns through another channel the next day. How are related cases recognised? Under which conditions does this create a new unit or a correction to the earlier invoice?

Third, AI prepares the work and correctly hands it to a responsible person. Which service is included, what is billed and what work remains with the team?

Fourth, processing is repeated after a technical failure. Which attempts count, and can duplicate charges be traced through a case identifier?

Fifth, the agreed allowance runs out. Which charges or interruptions follow, and how will the organisation handle the remaining cases?

For each case, request an inspectable example invoice and the underlying events. This creates a shared language for purchasing, operational teams and the supplier. Unclear answers become unresolved comparison points; they do not establish a claim about any particular product.

The decision this supports

My decision brief would contain one row per offer: unit definition, acceptance criteria, common case population, observation period, total included costs and open cases. It would also record the treatment of repeated processing, handoffs and corrections.

For medical or other consequential decisions, acceptance requires appropriately qualified criteria and accountable people. A billing rule alone establishes neither an answer’s accuracy nor patient benefit. The example here concerns commercial order-status information.

A price per outcome can make purchasing easier when the outcome is clear. The useful next step is a shared case exercise: can both sides explain the same case from the initial request through acceptance to the invoice?