AI Apps Deliver Outcomes — So Why Are They Still Charging Like Old School SaaS?”

It is now well understood that software is evolving from a tool that enhances human productivity to one that autonomously delivers outputs previously generated by humans — more on this theme here. However, this evolution’s impact on software pricing — from users or seats to outcome or deliverables — is evolving more gradually.

(Very) Quick Primer on Pre-AI Software Pricing:

When software migrated from on premise to the cloud, pricing accordingly evolved from perpetual to subscription based, often priced in the form of users or seats. Seat, or user-based, pricing was a natural structure for SaaS offerings for both buyers and sellers. For buyers, seat-based pricing was easily understandable and simple to buy and budget for. For sellers, it offered predictable revenue that often grew in line with customer headcount. For sellers with more complex functionality and modules, tiered pricing became common, but still with an underlying per-user, per-month structure in many cases.

More recently, usage-based pricing emerged as an alternative pricing structure, particularly for infrastructure and data platforms. Amazon Web Services (AWS) is a notable pioneer, offering a pay-as-you-go pricing option from inception. Similarly, Snowflake, a data warehousing platform, prices based on storage and compute, providing flexibility and scalability tailored to each customer’s data needs. Application companies like MailChimp also enable companies to pay based on emails sent.

Ultimately, while many application software companies have experimented with usage-based pricing, perhaps in conjunction with a seat based model, it has yet to become the norm (some surveys suggest ~40% of software companies haven’t tried it).

Post-AI Pricing:

There is a lot of talk that AI will enable companies to sell “work” versus “software to augment” human work, but the reality of pricing and selling finished “outcomes” is complex. First, what exactly does it mean to sell “outcomes”? In the case of an AI-enabled sales enablement platform, for example, it could mean that customers of that product only pay once a human employee verifies that an AI-generated lead is qualified, or once a meeting is successfully set with a prospect. As illustrated by this example, for “full stack” or multi-product offerings, AI-enabled tools may need to price multiple, different deliverables.

As evidenced by the fact that, in my hundreds of conversations with AI application startups over the last two years, the vast majority are deferring to traditional SaaS pricing, selling “outcomes” is complex.

There are many reasons for this, a few of which include:

1. Subjectivity around the definition and parameters of an “outcome”. To use the AI-enabled sales tool example again, what happens if a tool auto-sets 100 qualified prospect meetings, but none convert to customers? What if those prospects don’t convert because of an ineffective sale and close motion? It may be in the buyer’s court to re-adjust what parameters deem a customer qualified, but they’d likely be left dissatisfied with the product regardless. This could lead to expectations around servicing and re-adjusting outcome parameters that suck up valuable time for the AI-enabled sales enablement provider. (As such, selling outcomes may be best suited initially for products where the validity of the final deliverable is less disputable, such as a piece of marketing copy or image.)
2. Anchoring pricing too low, relative to ROI, if AI-generated outputs far outperform those historically generated by humans. If AI outputs outperform human outputs, AI companies may anchor initial pricing too low. An example of this could be an AI-generated advertisement that has a 10x ROI as compared to ad copy and images traditionally generated by a marketing team or agency. Will the software provider have visibility into this step change increase in ROI? How can it measure ROI across a multitude of customers and use cases to ensure pricing remains in line with delivered value?
3. Potentially more complex sales cycles (as opposed to traditional SaaS products) due to different decision makers and budgets at play. As buyers increasingly think about buying work, not tools to augment work, they will also reconsider budgeting (e.g. spend on software vs headcount vs outsourced services) and budget allocation across teams. Moreover, many enterprises considering buying AI-products today are on completely different points of the AI adoption curve. Companies are already overwhelmed trying to wrap their heads around AI, and what functions and use cases to focus on first, that adding the additional complexity of new pricing may be too much at once. These factors collectively lead to less predictable, uniform and repeatable sales motions.
4. Potentially excessive or unpredictable variable costs. Traditional SaaS products generally get increasingly profitable with scale, as the costs of issuing an additional seat or license are minimal. AI companies, in contrast, incur inference costs associated with each customer interaction, meaning customer growth may not unlock better profit margins. Moreover, while traditional SaaS companies strive to create products that customers want to “live in” and use all day, AI companies must balance and carefully consider optimal pricing strategies for these super “sticky” customers given the associated costs of incremental usage, until inference costs come down.
5. Non-seat based pricing infrastructure may be complex to implement initially. It will likely require mechanisms for measuring usage, output, ROI, etc. which is obviously more complex than charging a flat monthly rate. Many startups won’t have the infrastructure in place to do so. Output based revenue will also likely be lumpier, or more unpredictable (e.g. an ecom company doing a product recall generating a massive spike in CX needs).

Ultimately, we’re still in the early days of AI application development, but I think the transition away from predictable pricing will take time to evolve (if it ever does completely). A few final thoughts for startups building in this space.

1. Business model innovation could be a wedge for startups going up against incumbents, especially in competitive markets. As incumbents figure out how to price AI offerings, without cannibalizing existing product lines, new entrants can position pricing more aligned with ultimate end customer value. This could shorten sales cycles for offerings that are easily implemented and have clear ROI. Flybridge portfolio company MelodyArc, which provides AI-assisted customer support and charges “per resolution” is a good example of this pricing archetype. (I believe this business model innovation is likely more of a “head start” vs a sustainable competitive moat, but could provide a real advantage in locking in customers and displacing slower moving legacy players).
2. AI applications providing a net new deliverable (that wasn’t possible pre genAI) may command more pricing power, as they have fewer comps for buyers to anchor pricing on. This is somewhat counter intuitive as these startups aren’t straightforwardly displacing an existing, budgeted line item. But, if the product is truly “needle moving” re: ROI, they’ll have pricing leverage.
3. Some AI applications may need to combine different pricing models within the same accounts (e.g. a co-pilot product that augments human work, in addition to an autonomous agent that does its own completed work). Many AI startups today, at least at the seed and Series A stage, have bespoke agreements with customers in cases like this. But, at scale, these “tiered” pricing models, that incorporate seats as well as delivered work, may become more common.
4. Startups will need to carefully balance incentivizing usage with potentially lower entry prices, while also creating leeway to experiment and adjust pricing as they collect on appropriate pricing.
5. Experiment with offering a free “tier”, or one with limited usage or functionality, especially for products that lend themselves well to bottoms-up, PLG sales motions. Perplexity is a great example of this — their free product utilizes GPT 3.5, while their paid subscription product uses more advanced models, including GPT-4 Turbo, Claude 3, and Perplexity’s own experimental model. Of course, the balance here is ensuring the free, cheaper to operate product is good enough (in a sea of competition) to convert users to paid.

If you’re an early stage startup or existing operating thinking about pricing AI-applications, I’d love to connect — julia@flybridge.com.