Pricing Should Follow Outcomes, Not Usage
Software should charge for the result it creates, not the activity it consumes.
SaaS in general measures activity as success. It isn’t. Usage is easy to count. Outcomes are what matter.
That distinction is getting harder to ignore. As software gets more automated, more agentic, and more embedded in the work itself, charging by clicks, seats, requests, or tokens starts to feel like pricing the machinery instead of the result.
Why usage breaks
Usage-based pricing made sense when software mostly helped humans do work. More usage usually meant more dependence, and sometimes more value.
But that logic gets weaker when software starts doing the work itself. A customer should not pay more just because the system had to try harder to solve the problem using more tokens. They should pay for the problem being solved.
That is the appeal of outcome-based pricing. Not activity. Not access. Result.
Outcomes are the unit that matters
An outcome is not a page view or a token. It is a business result that someone actually cares about: a ticket resolved, a lead qualified, a workflow completed, a fraud case prevented, a deal accelerated, a hire made, revenue captured.
That is the real test. If the product is valuable, it should be able to connect its price to something the customer already recognizes as value. Otherwise, the vendor is charging for motion and calling it progress.
Measuring impact the consulting way
If you want to price on outcomes, you have to measure outcomes like a consulting firm would or the users within the company are measured for their success, Start with the business question. Define the hypothesis. Map the causal chain. Separate activity from output, output from outcome, and outcome from impact.
A useful framework is simple:
Objective: What result are we trying to improve?
Hypothesis: What do we believe will drive that result?
Baseline: Where are we starting?
Initiative: What did the software actually do?
Output: What was delivered?
Outcome: What changed?
Impact: What value was created?
Attribution confidence: How sure are we that the software caused it?
That matters because outcome-based pricing only works if both sides agree on what counts as a real result.
Measurable tools
The idea gets much more credible when it is tied to actual measures. Here are some examples for marketing teams:
Example 1: Lead qualification
Output: 500 leads scored automatically
Outcome: 35% of scored leads reach sales-qualified stage (vs 18% baseline)
Impact: $1.2M pipeline created from what would have been $450k
Example 2: Campaign optimization
Output: 12 A/B tests run across channels
Outcome: Best-performing creative gets 28% higher conversion
Impact: $750k incremental revenue from reallocating $200k ad spend
Other measures work the same way:
Time saved. Hours avoided per week reviewing reports.
Resolution rate. Percent of issues solved without escalation.
Cycle time reduction. Days shaved from lead-to-opportunity.
Error reduction. Fewer bad leads passed to sales.
Revenue impact. Dollars created above baseline performance.
These are not vanity metrics. They are the bridge between software activity and business value.
The agentic shift
This is where the idea gets more interesting. If the AI works well enough, the user may not need to log in at all. The system can monitor what matters, surface what changed, and deliver the relevant information directly to where the user lives. Ecosystems like OpenClaw/Hermes are already delivering value with no user interface. KaaS companies have the deep domain knowledge to deliver a higher quality result but the interface might be just chat.
That changes the value proposition completely. The platform is no longer just a place to go. It becomes a layer of confidence - confidence that the system is tracking the issues that matter, watching for exceptions, and bringing the right things to the user without making them do the work.
The value is not in making people spend more time in the product. The value is in making sure they do not have to.
Difficulty of outcome based pricing
Outcome-based pricing sounds elegant until you try to implement it. Especially when Agentic risk management is added to the mix.
You need instrumentation. You need agreement. You need trust. You need a metric that is fair, auditable, and hard to game. That is why many companies end up with a hybrid model first: base platform fee plus usage- or outcome-based add-ons.
Why this fits KaaS
This is where KaaS gets interesting. If the product turns knowledge into action, then pricing should reflect whether that action produced value.
A KaaS system should not just store intelligence or surface insights. It should help produce decisions that matter. If it creates better judgment, the vendor should be paid for better judgment — not for how many times the customer had to look at the interface.
The larger shift
This is bigger than pricing. It is a shift in what software thinks it is selling.
Usage pricing says: pay for access and activity.
Outcome pricing says: pay for impact.
Agentic software says: pay for confidence that the work is being handled.
That is a harder model to build, but a more honest one. And once software can reliably own part of the outcome, usage starts to look like an implementation detail, not the business model.
KaaS platforms might have to borrow from industries like insurance (for risk management), finance (for outperformance based pricing)
My sense is that over the next 24 months, we will start seeing business models evolve to fit this approach. What do you think?