Field Notes
Elasticity Is a RevOps Problem
Every AI pricing strategy, seat, usage, outcome, hybrid, makes the same promise: align price to value. Only one of them tells you, twelve months out, what you're actually going to collect. Model the other three below.
Run the model
Same underlying business, four pricing strategies. Each slider is a plain-language scenario, not just a number. The line under it tells you what the current value actually represents. Adjust the assumptions and watch what happens to revenue, forecast variance, and margin, not just topline growth.
| Model | Year-1 revenue | Forecast variance | Growth, M1→M12 | Est. gross margin |
|---|
Elasticity (ε) below: how much each model's revenue reacts to the price shock slider above. Economists use the Greek letter epsilon, ε, as shorthand for elasticity. A number closer to zero means the model is less sensitive to a price change.
Methodology & assumptions
This is an illustrative model, not one fitted to a specific company's data. The point is to show how elasticity, volatility, and pricing structure interact, using assumptions you can inspect and disagree with. Fixed inputs: 3% monthly logo growth; seat price $149 per seat; usage priced at $0.14 per unit off a 1,200-unit baseline growing 1.5% monthly; outcomes priced at $4 per result off a 40-per-month baseline, compounding at the flywheel rate you set; an 8% attribution-friction haircut on outcome revenue for disputed or unbillable results; hybrid splits 50/50 between a seat-like base and a usage-like variable component.
Gross margin by model, 82% seat, 76% hybrid, 73% usage, 65% outcome, is a directional assumption reflecting servicing and measurement overhead, not a computed figure. Outcome pricing costs more to run because proving the outcome happened is itself a cost center.
Forecast variance is the coefficient of variation (month-to-month standard deviation divided by mean) across the 12-month run. The closer to zero, the easier the number is to forecast and staff a comp plan against.
On the research. No one has published rigorous elasticity coefficients for outcome-based AI pricing yet. The category is too new, and even the industry's own usage-based pricing benchmarks don't measure it: Metronome's 2025 State of Usage-Based Pricing report tracks adoption (85% of surveyed companies had implemented some form of it) without touching price sensitivity at all. The direction of the assumptions above does track what practitioners report. Bessemer Venture Partners' AI Pricing and Monetization Playbook describes outcome-based pricing (their example: Intercom charging $0.99 per ticket its Fin agent resolves) as capturing expansion with little price resistance once ROI is proven, and usage-based pricing as running into real adoption friction from bill unpredictability (their example: Leena AI's early consumption-based pricing made customers wary of using the product at all). That's qualitative evidence from real deployments, not a fitted coefficient, which is exactly why the numbers above are labeled assumptions and not findings.
The RevOps scorecard
The pricing team picks the model. Packaging decides who gets it. RevOps inherits what both do to forecasting, quota-setting, and expansion planning.
| Model | Forecastability | Quota-setting | Expansion ceiling | Typical packaging | Where it breaks |
|---|---|---|---|---|---|
| Seat-based | , about 10% forecast variance in the model above. Bookings track revenue almost 1:1. | Straightforward. Quota tracks bookings. | Capped by headcount | Good/Better/Best by feature depth, more capability unlocked per seat at each tier. | AI's marginal cost isn't zero. Flat seats quietly subsidize your heaviest users and overcharge your lightest ones. |
| Usage-based | , about 15% forecast variance in the model above. Revenue moves with the customer's activity, not yours. | Hard. Reps are paid on a number their own effort barely influences. | High, uncapped | Tiers gate which meters you're allowed to consume, not how much. | Finance can't build a durable forecast on it, and customers start optimizing the meter down the moment the bill gets big. |
| Outcome-based | , about 22% forecast variance in the model above. Improves once you have a base rate. | Hardest. Outcomes depend on customer process and data quality too. | Highest. Price scales with proven value. | Tiers package the certainty around the result (self-managed, supported, guaranteed with an SLA), not feature count. | Sells beautifully in the deck. Expensive to operationalize. Most teams underprice the cost of proving the result happened. |
| Hybrid | , about 13% forecast variance in the model above. Base fee anchors it, variable piece swings. | Workable. Split into a booked-ARR component and a usage or expansion component. | Moderate to high | Two dimensions at once: a feature tier, plus an included usage or outcome allotment before overage. | Requires discipline to keep the variable piece variable. Sales will fight to fold it into base ARR the moment a renewal gets tense. |
Forecast-variance figures shown at the simulator's default settings above. Drag the sliders to see how each one moves.
The common packaging mistake mirrors the pricing mistake. Stranding a must-have feature in a seat tier nobody buys. Gating the capability someone needs just to evaluate a usage-based product behind a tier they haven't purchased yet. Forcing a feature-based Good/Better/Best onto an outcome-priced product, when buyers there are pricing confidence, not capability. Or setting a hybrid tier's included usage allotment too generously and eating the expansion economics it exists to capture.
The demand-gen motion you didn't choose
Whoever picks the pricing model also picks the funnel shape. Demand gen just finds out about it when they try to hit quota.
Seat-based is the only one of the four that's genuinely self-serve-compatible. Price is a number a buyer can model alone, with no call required, so marketing can run a classic PLG motion: free trial, transparent per-seat pricing, in-product upgrade prompts. Demand gen's job stays what it's always been: campaigns, content, MQLs.
Usage-based breaks that trust the moment the buyer can't predict their own bill. "I don't know what this will cost me" is the standing objection to metered pricing, so demand gen has to manufacture certainty before a lead will even start a trial: usage calculators, consumption estimators, capped free tiers. That's data and product work, not campaign work, which is exactly why it keeps landing on RevOps instead of classic marketing ops.
Outcome-based kills self-serve outright, and this is where account-based marketing takes over. You can't self-serve a model that requires a baseline measurement period and mutual agreement on what counts as "the outcome" before anyone can price it, so the motion shifts to a short list of named accounts, multiple stakeholders, and a pilot built around a measurable starting point. Demand gen's job changes shape entirely: not generating MQLs, but generating qualified pilot candidates with a baseline already in hand. The funnel gets smaller and slower, and the main demand-gen asset becomes the case study proving the outcome was real and repeats, the exact proof an ABM buying committee asks for before it signs.
Hybrid is the pragmatic answer most companies converge on: self-serve entry on the base fee, usage or outcome captures the expansion. One funnel serves two economics: a low-friction top of funnel for smaller accounts, and an ABM motion layered on top for the enterprise tier once the variable piece is big enough to justify a multi-threaded sell.
None of this is a demand-gen decision. It's decided upstream, by whoever picks the pricing model, and demand gen finds out which funnel it's running, self-serve, calculator-led, or ABM, by trying to hit quota with it.
Why this is RevOps's problem, not just Finance's
Pricing conversations tend to collapse two different kinds of elasticity into one word. Price elasticity is how much volume moves when price moves, the thing economists mean by the term. Value elasticity is how much adoption expands when a customer becomes convinced the product is actually working, a flywheel effect with no classical equivalent, and the entire premise of outcome-based pricing. Most pricing decks are arguing about the first while actually betting on the second.
Each model routes that elasticity somewhere different, and it doesn't disappear, it moves. Seat-based pricing suppresses price elasticity almost entirely: contracts, procurement cycles, and switching costs make demand sticky, which is exactly why it's so forecastable and exactly why it caps out. Usage-based pricing hands the elasticity straight to the customer's own operating rhythm, so your revenue line now carries their seasonality. Outcome-based pricing is the least price-elastic of all (customers rarely balk at a fair price for a proven result), but it trades demand risk for measurement risk: the volatility shows up in attribution disputes and "what counts as a result" negotiations instead of in the topline.
None of that is a pricing-team problem once the contract is signed. It's a forecasting problem, a quota-design problem, and a comp-plan problem, three things that live in RevOps. A CRO who signs a marquee outcome-based enterprise deal has, without necessarily meaning to, handed RevOps a forecasting mandate the existing process was never built to carry.
Two symptoms show up downstream of the same root cause. FP&A keeps saying RevOps doesn't give them what they need, usually because the forecast-variance number in the table above is exactly what FP&A needs before a pricing model launches, and instead they get it a quarter later, embedded in a guidance miss. Sales keeps asking to be in the pricing room too, not out of turf-guarding, but because nobody wants to carry a quota built on a number their own effort barely moves. Both are asking for the same seat at the same table, just earlier.
The operators getting this right aren't the ones who picked the theoretically "best" model. They're the ones who matched the pricing model to how confidently they could measure the thing they were charging for, and built the forecasting cadence, quota structure, and comp plan to match before the first outcome-based contract was signed, not six months into cleaning up after it.
I build the operating layer pricing strategy needs to survive.
Forecasting models, quota design, comp plans: the RevOps infrastructure that makes a usage- or outcome-based pricing bet actually operable. Scaling toward a pricing shift, or hiring for a RevOps leadership seat to build it? Let's talk.