Support Pricing Is Moving From Seats to Outcomes. Here Is What That Means for Buyers

For twenty years, support software was priced one way: a fixed fee per agent, per month. It was simple, predictable, and finance teams liked it. That model is now being joined by two others, and the reason is not marketing fashion.

Why the shift is happening

Traditional software has near-zero marginal cost. Adding a user costs the vendor almost nothing, which makes per-seat pricing a clean way to align price with the size of the customer.

AI capability breaks that. Every answer a model generates costs the vendor real money, and it costs more for longer conversations and larger context. Once a meaningful share of the product has a per-use cost, the vendor either builds that into a seat price with generous assumptions, or meters it.

Most vendors chose to meter it. That is the entire origin of the shift, and understanding it explains most of the buying decisions that follow.

The three units, and what each rewards

Once usage is metered, the choice of unit becomes a design decision. Three are common, and they reward different behaviour.

Per conversation. Charged when a conversation happens, regardless of what happened in it. Cost tracks demand, which is fairer than seats for seasonal businesses. The weakness is that outcome is not part of the unit: an abandoned chat and a perfect answer cost identically. The vendor earns the same whether the customer left satisfied or gave up.

Per message. Charged per exchange. This is the least aligned unit available, because a verbose model or a chatty customer inflates the count without adding value. The same conversation might be thirty billable messages or one billable resolution, which means a headline rate looking thirty times cheaper can be identical or worse in practice.

Per resolution. Charged only when an issue is genuinely solved. This aligns vendor revenue with customer outcome, which is the strongest version of the model. It also makes the definition of a resolution the most important term in the contract, because the vendor wrote it.

The definition problem

This is where buyers get caught.

A vendor quoting seventy percent resolution and a vendor quoting thirty-five percent may be describing identical performance, if the first counts any conversation the customer did not escalate and the second counts only conversations with a confirmed answer and no repeat contact.

So the questions to ask are specific:

• Does an abandoned chat count as a resolution?
• Is a conversation handed to a human billed?
• Does a reopened conversation retract the charge?
• Can I audit a sample of billed resolutions?

A vendor unwilling to answer all four in writing has told you something useful. We have written the full comparison of pricing models with the questions for each.

The spend cap question

Usage pricing without a ceiling is an unbounded liability. Not a theoretical one: an incident, a viral post, or a carrier disruption can multiply volume within hours, and the invoice follows.

The right question to ask a vendor is not whether costs can spike. It is what mechanism stops them. A hard monthly cap, alerts before you reach it, and a defined behaviour at the cap, ideally routing everything to your team so customers are still served while the spend stops.

With a cap, a usage model is a bounded line item that finance can approve. Without one, it is a risk they will keep raising.

What this means for your evaluation

The practical change is that you can no longer compare list prices, because the vendors are not selling the same unit.

The comparison that works is cost per resolved issue at your actual volume. Take your monthly count of genuinely resolved customer issues. For a seat model, divide your total including every add-on by that number. For a usage model, apply the rate at the same volume. Now you have two versions of the same figure.

That calculation frequently produces a surprise, because seat pricing hides its total across a base licence, an AI add-on, and sometimes channel fees, while usage pricing puts everything on one line.

Where the models genuinely differ

Three situations separate them sharply.

During an incident. Per-conversation billing charges for every one of the thousand people asking when a broken thing will be fixed. Per-resolution billing charges for none of them, because none were resolved.

When automation improves. Seat pricing does not fall when your AI resolves more, because you are paying for logins. Outcome pricing falls immediately, because you are paying for outcomes.

When you want company-wide visibility. Seat pricing charges for every additional person who can see customer problems, which pushes teams to ration access and creates a coordination tax. Outcome pricing does not.

The honest counter-argument

Seat pricing has a genuine advantage: it is completely predictable. A quiet month and a brutal month cost the same, which is exactly what some finance teams want.

If your volume is stable, your team is stable, and predictability matters more to you than efficiency, seats are a reasonable choice and the shift described here is not a reason to move. The teams for whom outcome pricing changes things are the ones whose volume is growing faster than their headcount, which is most software companies.

Where we stand

Fidiora prices per genuine resolution at a published rate, with the definition written in the customer’s favour and available in full. Handoffs, abandoned chats, and timeouts are never billed, and a monthly spend cap means the invoice cannot exceed a number you set.

We are obviously not neutral about which model is better. What we would say to any buyer, including one not considering us, is this: ask for the definition in writing, ask for the cap, and convert everything to cost per resolved issue before you compare anything.