← Back to Blog

Resolution vs. Results: Why Changing Your Pricing Model Without Changing Your Architecture Is a Trap

Results as a Service changes your invoice. Resolution as a Service (RaaS) changes your architecture. Here is why the difference determines whether you survive renewal.

Results as a Service is a pricing model. Resolution as a Service (RaaS) is a business transformation architecture. That distinction is not semantic. It is the difference between vendors who survive the next renewal cycle and vendors who discover, too late, that they changed the invoice before they changed anything that mattered.

The market is moving in the right direction. Outcome-based pricing is gaining traction. Seat-based pricing adoption in enterprise software fell from 21% to 15% in a single year, while hybrid and outcome-based models rose from 27% to 41% over the same period. Vendors who have recognized that billing for access rather than value is structurally untenable are reading the situation correctly. The instinct is sound. The execution, in most cases, is not.

Changing the Contract Does Not Change the Architecture

Most vendors pivoting to outcome-based billing make the same move: they restructure the contract language while leaving the product architecture, customer success motion, and internal measurement systems untouched. They now promise results. They have no reliable mechanism to define, deliver, or attribute them.

This is the Results-as-a-Service failure mode. Results-as-a-Service frames the AI pricing transition as an outcome billing problem: figure out how to invoice for something other than seats, and the transition is complete. The framing is not wrong about the destination. It is wrong about what it takes to get there.

A vendor who bills for outcomes without an underlying architecture designed to produce and verify outcomes is exposed at exactly one moment: renewal. The customer contracted for results. The customer experienced ambiguous delivery. The customer’s procurement team, now armed with AI-generated usage analytics and a CFO watching their own efficiency metrics, will not renew at the same rate. The contract promised accountability. The invoice arrives without evidence.

Outcome-based pricing without a High-Fidelity Repository means the vendor cannot prove what the agent resolved, cannot distinguish its contribution from ambient noise in the customer’s business, and cannot defend the invoice at renewal.

The Attribution Problem Is Not Theoretical

The core structural failure in Results-as-a-Service execution is attribution. When an AI agent handles a support ticket, automates a compliance review, or resolves a data quality issue, who can prove it was the platform’s execution that produced the outcome, rather than a concurrent human process, a system update, or the natural resolution of the issue over time?

Under seat-based pricing, this question was irrelevant. The customer paid for access, and access was delivered. Under outcome-based pricing, the question is contractually central. The vendor gets paid when the problem is solved. The customer will, at some point, ask how many problems were actually solved, by what mechanism, and how the vendor knows.

Resolution as a Service answers this question before it is asked. The foundational unit of value in the RaaS architecture is the Atomic Resolution: a discrete, verifiable unit of work that satisfies three specific criteria. It must be verifiable, meaning a problem was solved rather than attempted. It must be attributable, meaning the resolution is traceable to the platform’s AI execution rather than a human override or an external process. And it must be finite, meaning it has a clear endpoint that prevents open-ended agentic loops from consuming unlimited compute under a fixed resolution fee.

Without all three criteria, you do not have a resolution. You have an activity log. Activity logs do not hold up at renewal.

The measurement trust infrastructure that makes Atomic Resolution defensible is the High-Fidelity Repository. A graph-structured institutional knowledge architecture, the Repository gives AI agents the domain context they need to execute resolutions with accuracy and auditability. It is also what generates the evidentiary record that answers the attribution question. Every resolution executed against a mature Repository produces a verifiable log: the input, the action sequence, the output, the timestamp. That log is the commercial foundation of the RaaS relationship. Without it, “we resolved your problems” is an assertion. With it, it is a documented record.

This is the architectural requirement that Results-as-a-Service misses. You can change your contract to bill for outcomes. You cannot defend those billings without the underlying architecture to prove what you resolved, to whom, and how.

The Economic Frame That Makes the Model Viable

There is a second structural problem with pricing model changes that skip the architectural work: they produce undefendable unit economics.

The 1-to-4 Rule governs RaaS viability. For every dollar of AI infrastructure and compute spend, a RaaS vendor must capture at least four dollars of Resolution Value. That ratio is what restores the 75% gross margins that institutional investors require, recovering from the approximately 52% gross margin compression that AI-native SaaS companies are currently experiencing under seat-based pricing.

Vendors adopting outcome billing without the underlying architectural work cannot apply the 1-to-4 Rule, because they cannot measure cost-to-serve at the resolution level. They do not know which resolution types are profitable at their proposed pricing. They do not know which enterprise customers are generating negative margins at high resolution volume. They are billing for outcomes without the measurement infrastructure to know whether those outcomes are being delivered at a viable cost.

The result is a second wave of margin compression, worse than the first. The seat compression problem produced declining revenue on a stable cost base. The unstructured outcome billing problem produces declining revenue on a rising, unmeasured cost base, because AI compute scales with usage intensity and the vendor has no mechanism to detect when specific resolution types cross below the economic threshold.

The Three-Phase RaaS Transition Roadmap exists precisely to prevent this sequence. Phase 1 is a Revenue Audit, mapping ARR exposure to seat risk and identifying Ghost Seats, licensed seats no longer actively used because AI has absorbed the workflow. Phase 2 is the Hybrid Pilot, instrumenting the platform to track resolutions per customer and cost-to-serve per resolution type against existing seat contracts, before a single customer has been moved to outcome pricing. Phase 3 is Full RaaS Diversification, converting customers to outcome-based pricing using the evidence base that Phase 2 produced.

The most common failure mode identified in CPAG’s Vendor Transition Playbook is skipping Phase 2. Vendors go from recognizing the problem to repricing contracts without the measurement infrastructure to know whether they are pricing above or below their actual cost-to-serve. Results-as-a-Service, as a market phenomenon, is largely a population of Phase 2 skippers.

The Category Line

The distinction between Results as a Service and Resolution as a Service reflects a genuine disagreement about what the transition actually is.

Results-as-a-Service says: the problem is how you charge. Change the invoice structure and you have made the transition.

Resolution as a Service says: the problem is what you are. You are a seat-based vendor whose entire product architecture, customer success motion, and measurement infrastructure was designed around human headcount expansion. Changing the invoice does not change any of that. It adds a new set of contractual commitments on top of a system not designed to fulfill them.

The vendors who survive the next three years will not be the ones who repriced fastest. They will be the ones who rebuilt the underlying system before they changed the invoice, and who can now defend every resolution claim with an evidentiary record that no procurement team can dismiss.

That is not a billing model. That is a business transformation. The pricing follows the architecture. It does not replace it.


The question of what it means to verifiably prove that a machine solved something, rather than merely that a problem stopped occurring, sits at a deeper layer than commercial contract design. If the governance dimensions of AI attribution and accountability are the questions your organization is wrestling with alongside the commercial ones, the work at middlewayinai.com examines exactly that territory.

Prescription

The immediate intervention: Before any conversation about repricing customers to an outcome-based model, run a Phase 1 Revenue Audit against the Three-Phase RaaS Transition Roadmap. Map your ARR by seat exposure and AI exposure. Identify your Ghost Seat Rate. Then identify five to ten candidate resolution types in your platform and apply the three Atomic Resolution criteria to each: verifiable, attributable, and finite. If you cannot pass all three tests for at least three resolution types, you are not ready to price outcomes. You are ready to build the infrastructure to price them.

The RaaS Vendor Transition Playbook walks through the Phase 1 to Phase 3 sequence in operational detail, including the measurement trust infrastructure, the 1-to-4 Rule diagnostic, and the High-Fidelity Repository build roadmap. Request a playbook session to map your specific ARR exposure and identify your first viable resolution types.

The Socratic question: If your largest enterprise customer’s procurement team asked you today to produce a verifiable record of every resolution your platform delivered in the last 90 days, including which were completed autonomously and which required human intervention, could you deliver it? If the answer is no, what exactly are you planning to put on the outcome-based invoice?