Problem
Customer‑service software has been selling efficiency for years. Bots that deflect tickets, copilots that help human agents, automations that promise shorter queues. But with agentic AI a more uncomfortable question appears: if the agent does not resolve, why should you pay as if it did?
At Relate 2026, Zendesk pushed that conversation to the front with its “Autonomous Service Workforce”, MCP support and an expansion of results‑based pricing.
The signal is not only from CX. It is from the SaaS market: the economic unit of the agent is moving from access to outcome.
Thesis
Resolution‑based pricing forces AI to stop hiding behind activity.
A seat measures access. A token measures consumption. A resolution measures value, but requires definition, verification and dispute. That’s why Zendesk’s move is interesting: if the agent is charged for outcome, the platform must prove that the result was real, useful and attributable.
That logic will extend beyond support. Sales, operations, finance and IT will also have to answer: what counts as work done.
Framework
An outcome‑centric agent needs four definitions before it can be billed:
- Result: what event marks that the work is done.
- Quality: what criteria prevent a bad solution from being counted as success.
- Attribution: which part of the outcome was produced by the agent and which part by a human.
- Exclusion: which cases should not be billed even though there was activity.
Mini‑case: an agent resolves a return. If it confirms eligibility, issues a label, informs the timeline and closes the ticket without human intervention, it can be counted as an outcome. If it only gives a generic answer and the customer writes back, it is activity. The difference looks small on a dashboard, but huge on the P&L.
Measurable signal: ratio of verified resolutions versus automated interactions.
Position: outcome‑based pricing is good for buyers only if the outcome definition is auditable.
Why it matters now
Zendesk announced support for Model Context Protocol, including customer and server experiences, together with Agent Builder, omnichannel agents, copilots and pricing tied to verifiable resolutions.
That package shows three trends together: specialized agents, open integration via MCP and monetization by completed work. If those three pieces consolidate, service software stops selling tools and starts selling operational capacity.
Anti‑example
“We charge for automatic resolution, but the definition is decided by the vendor.”
That is a conflict of incentives. If the provider unilaterally decides what counts as success, the buyer pays for a metric they do not control. A good outcomes contract needs shared criteria, audit, and a dispute mechanism.
Protocol (3 steps)
- Define negative outcome. Not only what counts as success; what invalidates a resolution.
- Separate deflection from resolution. Avoiding a contact does not always equal solving a problem.
- Measure recurrence. If the customer returns for the same issue, the previous outcome was weak.
| Old metric | New metric | Risk |
|---|---|---|
| deflected tickets | verified resolutions | hide frustration |
| average time | closure quality | empty speed |
| cost per seat | cost per outcome | attribution dispute |
| automated volume | automated value | activity without ROI |
Related
- Decision Quality KPI: the indicator that replaces speed
- AI Evaluation Stack 2026: measuring without theater
- Human-in-the-Loop Debt: when quality control destroys margin
Sources consulted
- Zendesk introduces the Autonomous Service Workforce
- Zendesk outcome-based pricing
- Understanding outcome-based pricing
Next step
If you purchase support agents, ask for three examples of billable resolutions and three examples of non‑billable interactions. The difference will say more than the demo.
Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.