Two years ago, charging for outcomes was a contrarian position. Today it is the direction the whole category is moving. Seat-based pricing fell from 21% of SaaS companies to 15% in twelve months, hybrid models jumped from 27% to 41%, and Gartner now projects that at least 40% of enterprise SaaS spend will sit in usage, agent, or outcome-based models by 2030. Fin charges $0.99 per resolution. Zendesk charges $1.50. The pitch we are about to make is no longer unusual.
So this post is not going to spend much time arguing that outcome pricing is better than per-operation pricing. That argument has largely been won. It is going to spend its time on the part almost nobody publishes: how you actually measure an outcome, and who decides when one happened.
That is where these models break.
The problem outcome pricing was built to solve
The original case is still worth stating plainly, because it is why we chose this model.
When you pay per operation, your vendor’s revenue scales with activity regardless of whether that activity produced value. Imagine an automation that fires on all 10,000 of your monthly Shopify orders and runs an inventory check that almost always returns “in stock.” You pay for 10,000 operations. It produces a useful result on 80 of them. Nobody in that arrangement is motivated to fix the ratio: the vendor is paid on the 10,000, and you do not see the cost-per-result until you sit down and do the division yourself.
Per-task pricing, the model most AI agent vendors moved to first, only partly fixes this. You still pay when the agent tries and fails, and agent workloads vary 5 to 10 times between an easy case and a hard one. Salesforce Agentforce charges $2.00 per conversation whether or not the customer’s issue was resolved. Paying for attempts is better than paying for API calls. It is not the same as paying for results.
How our model works
Clarissi uses a hybrid, which is now the dominant structure in the market and for good reason.
Base retainer. Covers your dedicated embedded engineer’s time, platform access, and the infrastructure your automations run on. A flat monthly fee, not tied to volume. Founding-customer rates start at $750/mo, with regular pricing at $1,500/mo.
Outcome fee. Scoped to your operations and agreed during the Assessment. Calculated monthly from your execution record. Billed by invoice.
The outcome fee is the alignment mechanism. If automations fire 10,000 times and produce a result on 10, you pay an outcome fee on 10. That structure pushes us to tune for real results rather than raw execution count, to minimize misfires, and to expand into the outcomes where the opportunity is actually largest.
You will notice we do not publish a per-outcome rate the way Fin publishes $0.99. That is deliberate, and it is a direct consequence of the next section. A single published rate only works when every vendor and customer agrees on what one unit is. In customer support deflection, the category has converged enough for that. Across the range of operations we work in, a resolved ticket, a held fulfillment, a recovered cart, and a weekly analysis are not interchangeable units, and pretending otherwise would make the number meaningless.
The part nobody publishes
Here is the honest problem with outcome pricing, and you should ask it of us and of every other vendor making this pitch.
Who decides an outcome happened?
Outcomes rarely have a single cause. A resolved ticket, a closed deal, a recovered cart: several systems and several humans usually touched each one. Every vendor in this market names attribution as the hard problem. Almost none of them publish a method. A McKinsey analysis found 48% of firms using outcome-based models reported cash-flow problems tied directly to attribution disputes or payment timing. That is not a rounding error, that is nearly half the market discovering the contract was ambiguous after the invoice arrived.
The failure modes are specific:
- No baseline. If you cannot say what the number was before, you cannot say what changed after.
- Seasonality read as performance. Your ticket volume drops in a slow quarter and the vendor bills it as a win.
- Definition drift. The vendor’s definition of a “resolution” quietly widens over time.
- Disputes with no referee. No agreed evidence, so the argument comes down to whoever is more stubborn at renewal.
We do not think these problems are fatal. We do think the only defense is writing the method down in advance, so here is ours.
Our measurement method
A 90-day baseline, set before anything activates. Before a deflection-type automation goes live, your embedded engineer establishes your average monthly volume per ticket category, pulled from your own Gorgias or Zendesk history. If you normally receive 200 backorder tickets a month and receive 80 after activation, that is 120 tickets addressed. Those 120 are what the outcome fee applies to.
The baseline is not adjusted for seasonality in the first year. If your volume naturally falls in Q4 because you are shipping fewer orders, you still pay only against the original baseline. This cuts against us on purpose. It is the cheapest available protection against billing you for a quiet season.
The raw execution log is the evidence. Every outcome we bill for traces to a row in your execution record, and the monthly report ships with that log attached. You do not have to take the summary number on faith, and you do not have to ask for the underlying data.
Language discipline in the reporting. This one sounds small and is not. We report tickets addressed and orders proactively notified. We do not report tickets “retained,” “saved,” “deflected,” or “recovered,” because those words claim a counterfactual we cannot observe. We know a customer was notified before they wrote in. We do not know they would have written in. Proving retention would require a Shopify order-status join we do not currently run, so we do not claim it. When a vendor tells you they saved you 400 tickets, ask how they know the alternative.
If we get to the end of a month and cannot evidence an outcome under those rules, we do not bill it.
Why we can offer this at all
Outcome pricing is obviously better for the customer, which raises a fair question: why is it not universal?
Because most AI vendors cannot afford it. If every action your product takes is an unpredictable model call, your own cost of goods is a moving target, and you cannot price a result whose cost you cannot bound. Agent workloads swing 5 to 10 times between easy and hard cases, and a single overrun month can wipe out a quarter’s margin. So vendors fall back on per-seat or per-operation fees, and their runaway inference bill quietly becomes a line item on your invoice.
We can price outcomes because we control what one costs to produce. Most of the work runs deterministically with no model call at all. Data is pre-aggregated, so answering a question costs the same whether you have a hundred events or a hundred thousand. Every model call we do make is recorded and attributable to the run that caused it. When the cost of producing a result is bounded and visible, the result can be priced honestly. Being good at the engineering is what makes the pricing model possible, and we lay out that full argument in The Two Blockers Between You and AI That Runs Your Operations.
What counts as an outcome
Early on, “outcome” mostly meant a support ticket that never had to be opened, and that is still the easiest one to measure. But it spans everything the platform does for you: a live dashboard your team runs Monday mornings on, a weekly analysis that names the one thing to fix this week, a high-risk order held before it became a chargeback.
What counts as your outcome, and what its fee is, gets defined per engagement during the Assessment. That is exactly why the fee is scoped to your operations rather than printed on a rate card. It is tied to the results that matter in your business, not to a generic per-unit charge that fits everyone badly.
What if we are not delivering
If misfires are high, if results are thin, if the numbers do not justify the fee, your embedded engineer should be telling you that in the monthly report rather than hoping you do not notice.
The structure gives them a direct stake in the quality of each execution. Tuning is not a nice-to-have, it is what protects the fee.
And if after 90 days the outcome numbers do not justify continuing, you cancel with 30 days’ notice. No long-term lock-in, no multi-year commitment required to get our attention.
The test you should apply
For you: you can calculate what Clarissi is worth in dollars. Outcomes multiplied by your own cost per ticket gives a value figure. The outcome fee should be a fraction of it. If it is not, the model is not working and you should say so.
For us: outcome fees force us to build automations that produce results, tune them continuously, and go after the highest-value opportunities. We are not rewarded for volume.
That alignment is the reason we built it this way. But alignment is a claim, and claims are cheap in this category right now. The method above is how you check ours.