Usage- vs Value- vs Outcome-Based Pricing
“The Differences are Real - Especially to Buyers”
Usage- vs Value- vs Outcome-Based Pricing
“The Differences are Real - Especially to Buyers”
In today’s newsletter I share my observations on the evolution of SaaS pricing including AI empowered SaaS with a specific focus on Value-Based Pricing and Outcome-Based pricing. I will dive into detail on the below pricing topics:
Overview of the primary pricing models
Value is in the eye of the beholder (customer)
Outcomes are not the same as value
Trading off potential for certainty - the buyer’s dilemma & choice
Over the past year, I have read hundreds of LinkedIn posts, multiple articles, several newsletters and even a book on the topic to better understand pricing model trends. I have also just completed benchmarking research on pricing model trends in partnership with Maxio and Logisense. Today’s newsletter is my attempt to summarize what I have learned.
During this same time period, I have spoken with several CFOs on the topic of Usage-Based Pricing, Value-Based Pricing and Outcome-Based Pricing to gain their perspectives on which is best for their business and their budgets!
The overall theme of this newsletter is where the theory of pricing models begin and where the reality diverges…from the buyer’s perspective!
Pricing Model Evolution in the SaaS Era
Though I have a tendency to start with the long term history of a topic, I have limited myself to the beginning of the SaaS era for software pricing evolution.
Phase 1: Subscription per User (early 2000’s)
Early on, most SaaS solutions charged for access, but quickly moved to a per user, model borrowing from the on-premise software, price per seat pricing.
Salesforce was an early leader of the per user subscription model, starting with a $50 month to month subscription per user (click here the year 2000 pricing in the Wayback Machine). Salesforce then evolved to annual subscriptions as large enterprise customers did not prefer a monthly invoicing receipt and payment process.
Tiered pricing was introduced as a popular pricing construct in the mid 2000’s, where buyers could choose from various tiers based on features, user limits, or usage caps offering more flexibility. SaaS pricing was initially based upon an internal “cost-plus” model, then quickly evolved into charging for the perceived value of the software
Phase 2: Fee per Unit of Usage (mid 2000’s)
In 2006, Amazon introduced Amazon Web Services (AWS) which was the first well known example of Usage-Based Pricing. The primary “usage” variables included:
Instance-Hours: Customers were charged per hour for the type of EC2 instance they used, with different rates for various instance sizes and types
$.10 per month per small instance
Data Transfer: Costs were associated with data transferred out of AWS to the internet
$.20 per GB
Instance-Hours: Similar to EC2, relational databases were charged based on instance hours and size (small instance = 1.7 GB RAM, 1 virtual CPU, 160 GB storage)
$0.10 per compute hour
Storage Usage: Based on the size of the database
$.15 per GB of storage per month
This usage-based pricing model was groundbreaking at the time, as it introduced a pay-as-you-go approach to cloud services. This pricing model allowed businesses to avoid upfront hardware costs and scale resources as needed. Over time, AWS added more services, instance types, and pricing options, making the pricing structure more complex and able to accommodate diverse workloads.
Usage-Based Pricing increased the value alignment to the solution as customers paid for what they actually used, which correlated more directly to the perceived value they received.
Phase 3: Growth of Value-Based Pricing (2010s)
Though there are multiple attributes of Value-based pricing, the core concept centers around highlighting how software features and functions directly create value for the customer. Another core attribute for value-based pricing is that it could use customer data to personalize pricing that was specific to how they would be using the software and the perceived or specific value they receive from the software.
Companies began recognizing that pricing should reflect the perceived value customers derive from the product. This led to more sophisticated pricing strategies beyond just utilization, by using a combination of users, tasks automated and value delivered. Companies also began using data to personalize pricing for different customer segments based on their willingness to pay, usage patterns, and the specific value delivered.
Dropbox pricing is a good example of early Value-Based pricing as they had three basic models:
Basic (Free): 2 GB of storage, appealing to individual users who wanted simple file synchronization
Pro Plan: $9.99/month for 1 user and 1 TB of storage. This appealed to professionals who needed significantly more space and advanced sharing features
Dropbox for Business: Pricing started at $15/user/month, offering unlimited storage and robust administrative tools, targeting organizations that needed collaboration at scale.
Phase 4: Early days of Outcome-Based Pricing (2020’s)
SaaS companies have begun to increase the focus on customer outcomes rather than value-based features and function. For instance, tools that increase revenue or reduce costs for customers can justify premium pricing for the actual outcomes versus the features being used. This concept is becoming more popular with AI Agents - where ~12% of companies are using some form of outcome-based pricing.
Below is a high level graphical overview of different pricing models being leveraged in the SaaS industry today:
Phase 5: AI Agent Pricing (2023 and beyond)
One of the concepts I have been researching as a potential model for pricing is the concept of “skill-based pay”. Skill-based pay (SBP) is a type of compensation system in which an employee is paid based on the specific skills they possess and the level of proficiency they demonstrate in those skills. Skill-based pay is a compensation system that emerged primarily as a response to evolving workplace demands, particularly in industries where flexible and versatile workers are needed. Its origins are rooted in the economic and management changes of the mid-20th century, particularly in manufacturing and other labor-intensive industries.
I recently saw an article by Kyle Poyar on the concept of SBP applied to SaaS pricing - Skill-based pricing. I will not go into detail or borrow too much from Kyle’s article which can be seen here, but Skill-based pricing may reflect the next stage of pricing evolution as we move from AI co-pilots to AI workflows to AI automation and ultimately to Agentic AI, which I discussed in the previous edition of the SaaS Barometer. Skill-based pricing suggests customers will be willing to pay more for Agentic AI based upon the experience, quality, timeliness and service level agreement/guarantee delivered by the AI alternative to human workers.
Value Delivered versus Outcomes Achieved
We recently conducted pricing benchmark research in partnership with Maxio and LogiSense which will be published in early February. As I was analyzing the early data, it became clear that there is not a standard definition or common understanding of “value-based pricing” versus “outcome-based pricing”. Below are some of the common pricing variables that I see being used, and I view as being “Value-Based” versus “Outcome-Based”:
Value-Based Pricing Variables
Contacts Stored
Emails Sent
Accounts Researched
Account Plans Generated
Designs Created
Dollars of Gross Merchandise Value Supported
Dollars of Payments - Made or Received
Outcome-Based Pricing Variables
Increased Revenue
Leads or Pipeline Generated
Deals Closed
Reduced Expenses
Support Calls Automated
Support Cases Deflected
Meetings Scheduled
FTE avoidance
Employee Productivity Increases (x output per Y employees)
Hires Made
Increased Customer or Employee Satisfaction
As you look at the above examples of “Value-Based” versus “Outcome-Based” variables, there is one required attribute of outcome based variables in my definition. Outcome-Based pricing must charge for variables that directly impact the Income Statement in the form of: 1) Increased Revenue; 2) Decreased Costs.
As I was writing this newsletter - I was looking for ways to simplify the different pricing models being used, attempt to create a standard definition and provide concrete examples of “value delivered” versus “outcomes achieved”. I must admit it is VERY HARD and probably not achievable but here goes one definition of Value-Based versus Outcome-Based pricing.
Value-Based pricing charges for those defined tasks, activities and automations that contribute to the increased productivity of employees, contractors and processes but such improvement cannot be primarily attributed to the software. The value cannot be primarily attributed to the use of the software because human participation in the task, activity and/or process is the primary input to the outcomes produced. There is typically a way to assign a “value” to the specific task, activity or process that is being automated, thus providing for the ability to calculate the ROI achieved as measured between the primary measurement(s) of the current way of doing the work versus the new way of doing the same work.
Outcome-Based pricing charges for the outcomes of those tasks, activities, processes and automations that are primarily executed and managed by the software. The outcomes can easily be attributed to the function of the software and requires minimal to no human intervention in the process beyond initial set-up and possibly the initiation of the intelligent agent.
What pricing model is preferred by economic decision makers?
Almost every article I read, LinkedIn post that I peruse and conversation I have regarding pricing is from the “vendors” perspective. Since 75% of our audience are senior executives who have the primary responsibility for their company’s financial performance, including owning the reporting of the Revenue and Expense components on the Income Statement, I thought it would be good to also discuss pricing models from a BUYER’s perspective.
Usage-Based pricing provides the initial buyer benefit of not coming with a large up-front fixed expense before knowing the software is being used as expected, performing as advertised and delivering the value promised.
One of the risks of Usage-Based pricing is that it can be hard to predict the level of usage and thus costs until it has been fully deployed, adopted and ultimately used to develop usage trends and the associated costs. Though the unit of work being charged for may be a good indicator of how much the software is being used, the value of the work unit may not be commensurate with the perceived value delivered at much higher volumes.
Usage-Based pricing is “good until it’s not” is a quote that one CFO provided, saying that it was very attractive in the first year as the company initially deployed the solution and determined all the transactional systems that would use the tool to send external messages.
As the number of use cases increased across multiple functions, the costs became so high that the CFO mandated that each function include the expense within their respective budgets and the vendor was required to provide a “not to exceed” cost cap on the contract before it would be renewed for a second year.
Value-Based pricing may provide an enhanced way to align and attach specific value to each “task or activity” managed by the software. At the same time, it may be difficult to extrapolate and/or allocate a specific value to the task or activity being assisted or automated by the software, especially if the associated process(es) primarily rely upon human intervention for completion.
At the same time, if the buying company can fully allocate costs to a process, activity or tasks and has the ability to measure the increase in productivity primarily enabled by the software, paying on a task/activity/process basis that easy to track and measure the value versus the cost would be of high interest to the financial, economic buyers. A caveat to this is being able to predictably, and accurately forecast the number of tasks/activities/processes to be managed by the software will be critical to get the economic buyer to sign an agreement that does not cap the upside exposure - even WHEN the ROI is easy to calculate on a value received basis that is more than one step removed from revenue produced or expense eliminated by the software.
Outcome-Based pricing that aligns the software functionality to the direct reduction or elimination of expenses or has direct, easily measured impact on revenue generation will be an easy decision for an economic decision maker. Consider the joy and value in knowing that a software based solution that you contract for will only be charged for when it directly generates revenue or reduces an expense!
Very few CFOs would have a difficult time approving an agreement that included a term such as “for every dollar of new revenue that is directly produced using our software you will pay $.10” or “for every dollar of expense that our software eliminates you will pay $.10”. Signing that agreement like this would be an easy decision for most CFOs!
ROI models do not guarantee returns
A common practice which I strongly encourage is for vendors to develop a robust Return on Investment model, conduct deep discovery and diligence on a potential customer's existing process/activity/resources and the associated costs. Then once they have fully documented the current state and associated costs, they use the ROI model to calculate and highlight the POTENTIAL ROI of the future state using their software to justify the investment.
The challenge with this Value-Based sales process is that the ROI is typically only projected, and almost no vendor will guarantee the ROI under the auspice that they cannot control how the buyer uses the software and thus cannot take responsibility for the outcomes 😥
In fact, one CFO told me they challenged a vendor who was certain that their solution could increase the revenue associated with existing customer maintenance renewals by $5M. He asked the vendor if they would do an agreement that paid them $.50 on every dollar of increased maintenance renewals above the current renewal percentage.
When this offer was presented to the vendor’s CFO, he responded that since not all aspects of the maintenance renewal process was under their control, they could not accept this pricing structure. This was even in light of their ROI assessment which highlighted the prospect would increase their maintenance revenue by $5M, resulting in $2.5M additional annual revenue to the vendor versus the $1M subscription they were trying to sell.
In Usage-based and Value-based pricing, vendors are often asking buyers to assume the majority of the risks associated with uncapped pricing models, with no certainty that the value anticipated and/or sold will actually be realized.
This is one reason why I am excited about the potential of Agentic AI and the ability to price it based upon the outcomes delivered. Approximately ~12% of native AI solutions are being priced using an outcome-based model, and that is something that the majority of CFOs can get behind!
Summary
B2B software pricing will experience a level of experimentation and new approaches over the next 12-24 months that is hard to quantify, especially during the early days of Agentic AI. Based upon the research we have conducted and the pricing model benchmarks we will be publishing in early February, we are confident that the level of pricing innovation will reflect the rapidly evolving world of AI.
At the same time, we are confident that economic buyers, especially CFOs will gravitate to those solutions which align costs with direct outcomes that can be measured easily in dollars and sense!!!
If you would like to receive early access to the latest Billing Model and Pricing Process Benchmarks Research Report based upon our original research conducted with Maxio and LogiSense - click here to reserve your early access to the findings, the report and the interactive portal where the findings are being published