Practice note · Billing
Your AI support bill counts “resolutions” it attested itself
The invoice line reads 8,012 resolutions × $0.99. Or × $1.50, or × $2.00 — Intercom Fin, Zendesk AI, and Salesforce all now bill AI support this way, and the model is spreading.
Here is the question nobody on the invoice answers: who confirmed that each of those 8,012 was a resolution?
What “resolved” quietly includes
Across vendors, the resolution counter typically includes outcomes only the vendor's own system marked:
- Assumed resolutions — the customer stopped replying, so the conversation closed “resolved.” Community threads full of operators discovering this the hard way are not hard to find.
- Deflections — counted as outcomes on some plans even when the customer never confirmed anything.
- Confirmation-click resolutions — the customer clicked “Yes, this helped” on a prompt. One Zendesk community commenter put it plainly: “Charging an autoresolution simply because an end user clicks Yes is broken.”
- Escalations that still got counted — the AI handed off to a human, after the meter had already ticked.
None of this is hidden. It is in the pricing docs, in the definitions, in the product's own semantics. The problem is structural: the vendor's AI marks the outcome, the vendor's meter counts it, and the vendor bills it. We checked twenty vendors in this space — not one publishes a dispute process for the resolution count on your invoice.
One distinction does most of the work: who attested the outcome?
| Outcome | Attested by | Billing meaning |
|---|---|---|
resolved | the affected party (your customer actually confirmed) | settlement-grade — hard to argue with |
resolved | the vendor's own system | billable under their rules — and negotiable |
assumed_resolved | silence, interpreted | the largest gray zone on most bills |
escalated | anyone | not a resolution on any honest line |
An outcome the vendor attested and an outcome your customer attested are different facts. Blending them into one number is how a bill becomes unarguable.
The two-line statement (VSS-1)
Our open settlement-statement standard refuses to blend. A statement carries exactly two lines, computed from your own export:
Tier 1 — everything the vendor's OWN published rules would bill
(their resolutions + their assumed resolutions)
Tier 2 — only resolutions an affected party actually confirmed
The gap between the two lines is the disputed class.
Tier 1 leads the negotiation for a simple reason: every finding cites a rule the vendor itself published — the data can be disputed, and the rule citation is checkable by either side. Tier 2 is renewal leverage, not a dispute line. The two are never blended into a single “true number,” because a blended number is exactly the kind of claim both sides can reject.
And the discipline that makes it hard to attack: anything your export cannot prove is listed as UNPROVABLE and removed from any claim — with the missing evidence named, so the vendor can supply it or credit it. A statement that guesses zero rows is a statement that loses.
Run the existing tools locally
- Run it yourself: the CLI reads your conversations/tickets export on your machine and writes the one-page statement + dispute bundle.
pipx run verovo; nothing leaves your machine. - Zero install: recount Tier 1 in your browser from a counts-only export.
- Service update, 2026-10-14: the earlier free reconciliation trial is no longer a current offer. The workflow remains a research reference; current diagnostics focus on agent logs and metering samples.
→ Workflow reference · Historical proposal
What this is not
We measure, and we check conformance to declared rules. We do not adjudicate (“should have been billed”), do not touch payments, and do not take a cut of anything recovered — a meter that only earns when it finds overbilling is a meter with an incentive problem. Fixed statements, from declared rules and observed execution only.