Buying and budgeting
Ask what “resolved” means before you pay for it
Inspect outcome-based billing without confusing a vendor-defined resolution with a correct customer outcome.
Published · Collection dates are retrospective editorial dates.
A dashboard can say a conversation was resolved while the customer still has a problem. That does not necessarily mean the dashboard is broken. It may mean “resolved” is a defined product event rather than a direct observation that the customer's underlying task succeeded.
When billing is attached to that event, the definition deserves careful attention. You need to understand what starts a charge, what can reverse it, and how you will evaluate service quality separately.
The important distinction is between a contract definition and an operating outcome. Both can be legitimate. They should not quietly become the same metric in your business case.
A public example, with its boundary
As checked on October 10, 2026, Intercom's Fin AI Agent outcomes documentation describes confirmed and assumed resolutions. It also says a resolution is deducted if the customer later returns to the same conversation seeking further assistance, including across billing periods. The page describes other outcome types, including procedure handoffs.
Those are specific product definitions. They are not a universal rule for AI support billing, and this article does not quote a price or describe your negotiated contract. Check the current documentation and applicable terms for the product you are buying.
The example illustrates why a buyer should read beyond the word “resolution.” A conversation ending, an answer being accepted, and a business task being completed are different events.
Trace the customer's task past the final answer
Imagine a hypothetical customer asking how to update a delivery address. The system provides an approved explanation. The customer leaves the conversation. The address may still be unchanged because the customer has not completed the next step.
That can be a valid informational interaction. It should not be counted internally as a completed address change. Your quality evaluation needs to match what the workflow promised to do.
Now consider a system that actually updates the address. The evidence should include the correct order, the authorized request, the resulting address, and the customer's confirmation. A fluent answer is insufficient evidence for that action.
| Event | What it establishes | What it does not establish alone |
|---|---|---|
| Conversation ended | No further message in that interaction at that point | The customer achieved their goal |
| Customer accepted an answer | A positive response to the information | Every downstream action succeeded |
| Tool reported success | A system accepted or completed a technical request | The request matched the customer's intent |
| Correct business outcome verified | The agreed task was completed properly | The whole service is reliable across other tasks |
Use these distinctions in reporting. They make the numbers more useful without declaring a vendor's legitimate billing event meaningless.
Ask the billing questions in writing
Request the current definition of every billable outcome. Include the exact treatment of unanswered clarifications, handoffs, disqualifications, duplicate contacts, and reopened conversations. Do not assume the model for one channel applies to another.
Ask how the system groups conversations. A customer who moves from chat to email may create a different record. A later complaint may arrive in a new thread. Whether those events affect billing is a contractual and product question, not something to infer from the customer's intent.
Find out what evidence accompanies a charge. Can you connect an invoice line or usage entry to the relevant conversation and event? How long is that evidence retained? Who can access it? What is the process and time limit for disputing an incorrect classification?
A sample invoice based on a set of test interactions is often more informative than a headline rate. Have the supplier classify the interactions and explain each charge under the published terms.
Build a separate quality sample
Review a selection of billed outcomes for correctness. Include clean-looking interactions and high-consequence cases, not just conversations flagged as failures. A system may confidently close the wrong answer.
Use a rubric your team can explain: approved information used, identity requirements met, correct action taken, customer expectation accurate, and next owner clear where work remains. Record severe mistakes separately rather than hiding them inside an average.
This separation also protects a good system from unfair judgment. A correct handoff can be valuable even if it is not an automated resolution. An accurate informational answer can be useful even if the customer still needs to complete a separate step.
Budget for the definitions you are buying
Estimate costs using the actual chargeable categories, not an imagined automation rate. Then add internal review and exception work. If you compare suppliers, apply each supplier's rules to the same representative workload.
Run scenarios for uncertainty. If more conversations qualify as billable than expected, what happens to cost? If many apparently completed interactions return through another channel, what happens to staff workload? Label those as estimates until a pilot provides evidence.
Assign finance and operations different but connected responsibilities. Finance should be able to reconcile charges. Operations should be able to assess whether customer work was completed properly. Neither team should have to treat the other team's metric as a substitute for its own.
A useful outcome contract is one you can explain with a concrete interaction and verify against a record. Read the definition before multiplying the rate, and keep the customer's actual result in view after the invoice is paid.
Sources
For help defining this workflow, explore our customer messaging work.
Keep reading
