A quote for 50,000 credits gives a buyer nothing to reason about. They cannot tell what it gets them, how long it lasts, or what happens when it runs out. The translation work gets pushed onto the person paying, and most of them will not do it.
Tokens, credits, and API calls are infrastructure units. The people signing the contract think in leads routed, contracts reviewed, and reports generated. When the two do not line up, the buyer either undervalues the product or walks away.
This is a metering problem before it is a sales problem. If your event stream only carries token counts, nobody downstream can price an outcome, because the outcome was never recorded.
What is use case based sales?
Use case based sales means pricing the outcome the customer is trying to achieve rather than the package or the compute that produces it. Credits and tokens still exist underneath. They stop being the thing on the quote.
Simon Ooley, CEO of Veles, frames the shift like this:
"5,000 tokens or 5 million tokens means nothing to a buyer, but the outcome they get with those tokens means everything."
The conversation starts from the job instead of the tier list. A buyer says they want to route inbound leads more effectively because they are losing some and leaving money on the table. That job becomes the unit the model is built around. As Ooley puts it, "The tokens are just an ancillary currency. It's not something that is our core package deliverable."
Why does packaging break for AI products?
Traditional SaaS packaging assumed a stable relationship between the product and the use case. You buy an HRIS to run payroll. The features are defined, the value is understood, and the price reflects it.
That assumption does not hold for products that can automate almost anything. Ooley describes the effect on positioning:
"It's almost impossible to tell one person what that product does for them because it could do anything."
The downstream symptom is familiar. Sales teams improvise, build one-off models per deal, and describe the product differently to every prospect. Not out of strategy. The packaging gave them nothing to anchor on.
Why outcome pricing is harder to game
Every pricing model has a workaround. Seat licenses get shared, and five seats become fifteen people behind one password. Credit systems get hoarded. Flat fees get arbitraged by heavy users.
Outcome pricing narrows the gap because spend and value move together. Ooley uses cloud compute as the reference:
"You're not going in there looking to spend $50,000. You're not setting a budget to say, okay, I'm only going to spend $50,000. If you need to compute more to deliver for your customers, you're going to spend more because that's the desired outcome."
There is no arbitrage when more spend produces more of the thing the buyer came for. Expansion stops being a negotiation and starts being a reorder. Ooley is direct that gaming never disappears entirely: "Whatever pricing model you have, you can gamify it. But I think the closer you get to the desired outcome, the harder it's going to be to gamify."
What changes in packaging, pricing, and comp
Packaging becomes use case driven
Feature flags and caps stop being the organizing idea. Ooley: "The packages are not about the feature flags and the predefined outcomes. It's more about, hey, this is why people buy it here are the use cases they look to accomplish."
On a pricing page that reads closer to a statement about what companies at a given size actually accomplish, and what that takes, rather than a column of included features.
Pricing moves off cost-plus
Tying price to model cost means every upstream price change lands on you. Ooley's advice: "Focus on the value you're providing. Make sure your margin for cost is aligning with your financial model. But essentially, don't do cost-plus." Price the outcome and a model getting cheaper improves margin rather than compressing revenue.
There is a second layer. Not every token is worth the same. "Every token spent on inbound is drastically more valuable than every token spent on outbound." Two use cases can burn identical compute and carry very different prices.
Comp rewards growth, not just the logo
Traditional comp pays on new logos. Ooley is blunt about the failure mode: "Traditional SaaS is new logo. Bang. I'm just going to throw this deal in, throw the grenade over the fence to customer success. That pays out the individual contributor, but it doesn't pay out the business in the long term."
Under use case based selling, the reps who model out five use cases and land the two most urgent have mapped the expansion path themselves. "Any use cases that you've modeled out with them that they want to accomplish that aren't top of mind right now is the clearest path to white space upsell." Tying compensation to consumption growth inside the account is what keeps that path worth walking.
What this demands from the billing layer
The framework collapses if the billing system cannot represent it. Ooley describes the fallback most teams land in:
"We were just rebuilding all that logic in a Google spreadsheet or an Excel spreadsheet and doing all pricing and packaging outside of the CPQ which of course leads to discrepancies between the spreadsheet and the source of truth."
Reps quote one number, finance sees another, and nobody trusts either. Onboarding gets worse: "here's this spreadsheet and please don't click any cells but the ones that are highlighted in yellow or else you're going to break it."
Four requirements fall out of this.
Hybrid pricing as a first-class model. Almost nobody goes pure consumption in one step. Ooley: "What's working the best today is package plus consumption or package plus usage. Hey, you're going to buy X number of seats plus you get this limit of credits, you can always buy more." A system that models seats and a credit allowance and overage as one subscription handles this. A system that needs two products stitched together does not. Flexprice documents this shape under hybrid pricing.
Real-time usage tracking. Scoping deals against credit estimates only works if both sides can see consumption as it happens. Batch metering means every expansion conversation runs on stale numbers. The event ingestion overview covers how events land and get attributed.
Flexible entitlements. Different customers buy different bundles of use cases. Each new configuration should not require an engineering ticket. Entitlement grants are the primitive that keeps access rules out of application code.
Room to change your mind. AI pricing is not settled. Testing a credit tier or an outcome metric should not mean a billing migration.
The instrumentation consequence is worth stating plainly. If you want to price a resolved ticket, your product has to emit a resolved-ticket event, not just the token count that produced it. Illustratively, that is the difference between:
{
"event_name": "llm.call",
"external_customer_id": "cust_4471",
"properties": {
"model": "gpt-4o",
"tokens_in": 4120,
"tokens_out": 880
}
}
and:
{
"event_name": "ticket.resolved",
"external_customer_id": "cust_4471",
"properties": {
"ticket_id": "t_88213",
"use_case": "inbound_support",
"tokens_in": 4120,
"tokens_out": 880
}
}
The second carries the billable outcome and keeps the compute detail for margin analysis. The first can never be priced as an outcome, no matter what the contract says, because the outcome was never recorded. Custom units of this kind are defined through metered features.
Subscription-era billing tools were built around fixed seats, annual terms, and predictable revenue. Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.
Where AI pricing is going
Ooley's advice to founders is short:
"Simplicity is key. Number one. Number two, focus on the desired outcome that you're looking to solve for your customer and have candid conversations about how much that use case is worth."
That is the whole framework. Not clever packaging, not deeper credit tiers. A clear answer to what you are solving and how you price against it. Teams that get there early end up with a revenue model that grows with customer value and does not break when foundation model costs move.
The advantage is not in the tokens. It is in what the tokens accomplish, and in whether your event stream is recording it.
Read the event ingestion docs if you want to see what metering an outcome looks like end to end.
