Resolution: the vendor-defined event your AI add-on invoice is built from

A resolution is the event your vendor's system marks as one. Not a customer saying their problem is over, and not your agent closing a ticket: a state transition recorded inside a platform you cannot query, of which the invoice is a count.

Two companies with identical traffic can get very different invoices from the same vendor. What separates them is whether a customer asking the same question twice in a morning generates 1 billable event or 2, and whether the test script somebody wrote in 2024 still talks to the widget.

The event the vendor is actually measuring

Nearly every counting rule here belongs to 1 of 4 families, which sound alike in a sales call and count different populations.

A system billing on its own assessment of its own work carries no external check, so pair the 4th family with a measured reopen rate. That is a different number from containment, and the two are separated in containment against deflection.

The edges where a definition turns into money

The headline rule is rarely where the disagreement lives. These 6 edges do most of the work, and a vendor who has thought about the product answers all of them at once.

• The same-day repeat. A customer returns 20 minutes later on the same subject. Ask for the re-contact window in hours, and whether it applies per customer or per thread.
• The reopen. A resolved conversation a human later finishes can bill once, bill twice, or be credited back. All 3 are defensible; only 1 is in your agreement.
• The 1-message conversation. Someone types "hi" and never returns. A timeout rule bills that, and so, usually, does a bot-only rule.
• The same person on 2 channels. Asking in chat and then emailing creates 2 conversations and, under most definitions, 2 billable events.
• Your own traffic. Test conversations, staging credentials pointed at production, uptime monitors and the QA script at 02:00 all look like customers.
• Machines. Bounce notices, out-of-office replies, another company's autoresponder and any crawler that finds an open widget all get answered, 1 event at a time.

The incentive each definition creates, stated plainly

Whoever controls the counter benefits from a generous reading of ambiguous cases, and from leaving the ambiguity in place. Whoever pays benefits from a narrow one. Neither position needs a villain to explain it — which is why the definition belongs in the contract, not in documentation a vendor revises on a Tuesday.

Any number that triggers money should be reproducible by both parties from data both parties can read. A resolution count is not.

It is the discipline behind what a health score is allowed to decide: a figure computed in 1 system that triggers a consequence in another needs its inputs written down first. What counts as a resolution in AI support pricing is settled in the agreement, not in the helpdesk.

The definition also moves the boundary between the 2 systems. If every conversation the assistant closes bills, the intents you route to it are the intents you pay for — which strengthens the case for giving it the documented half of the queue. Whether the per-event shape suits you at all is answered in resolution or seat billing.

The questions to put to a vendor in writing

1. Which state transition marks a resolution? Ask for the event by the name it carries in your admin interface.
2. What is the re-contact window in hours, and does a return inside it produce a 2nd charge?
3. Does a human touch cancel the charge, and at which point: internal note, assignment, or first reply?
4. What happens to a conversation reopened after billing — credit, no credit, or a new event?
5. Which channels are in scope, and can 1 be switched off without amending the agreement?
6. How is our own traffic excluded: sender domain, a test flag, an API key, or not at all?
7. Can we export billed events for any period, with conversation id, channel, timestamp and trigger?
8. What notice applies if the definition changes, and can it take effect mid-term?

None of this argues against buying the add-on. A vendor-run assistant answering documented questions is often the right call; the counting rule decides what it is worth. The wider decision sits under build, buy or extend, inside our SaaS and customer support work; operating a layer like this is AI agents and automation, with field notes in agents in production.

• resolution definition
• usage billing
• vendor contracts
• support AI