PYMNTS.com's latest reporting flags a structural shift in how software vendors price their products: as AI workloads become central to SaaS products, per-seat licensing is giving way to usage-based billing.

Why per-seat pricing breaks under AI

Seat-based pricing assumes a stable ratio of users to compute. A knowledge worker logs in, opens a tab, and consumes a predictable slice of capacity. AI inverts that assumption. A single user running a long-context inference against a foundation model can burn more GPU-seconds in one afternoon than a hundred passive users consume in a week. Charging that user the same as the passive user starves the vendor; charging the passive user for the heavy user's burn kills the deal.

PYMNTS.com's framing is that vendors are increasingly choosing to meter the variable cost directly rather than absorb it.

What usage-based pricing actually looks like

Usage-based pricing ties the invoice to a measured unit: API calls, tokens processed, documents ingested, or some composite "AI action" metric. The model is not new. Cloud infrastructure has billed this way since AWS launched EC2 pay-as-you-go in 2006. Stripe, Twilio, Snowflake, and Algolia built their commercial motions on metered billing long before generative AI arrived. SaaS application layers drifted toward seats because seats were easier to sell, easier to budget against, and easier for procurement teams to sign off on. AI is now pulling the application layer back toward the consumption pattern that infrastructure already follows.

The tradeoffs product managers inherit

Usage-based revenue is volatile. A product manager who built a forecast on per-seat growth can watch a quarter swing 20% in either direction when two enterprise customers change their AI usage patterns. Forecast accuracy, a discipline that finance teams reward and CFOs track quarterly, gets harder when the unit being sold is a token.

The second tradeoff is in the sales motion. Usage-based deals shift budget authority from the buyer's HR or productivity line item into engineering or operations, where spend is tracked differently and where the economic buyer may not be the same person who signed the original seat contract. Vendors that have pulled this off, Snowflake being a frequent reference point, pair usage data with credit commitments and overage alerts so customers don't get blindsided.

The third tradeoff is UX. Seat-based SaaS lets a vendor cap or expand access with a toggle. Usage-based SaaS has to expose the meter to the user, or at least to the admin, or risk the support ticket that ends the renewal. That means building a dashboard, an alert system, and a budget-cap feature that seat-based products never needed.

Where this fails

Usage-based pricing fails when the underlying unit is not what they value. If a vendor charges per token but the customer's mental model is "per document processed," every reconciliation call becomes a churn risk. Vendors that have miscounted here have had to refund or restructure, often after publishing pricing pages that they later retracted.

It also fails at the bottom of the market. Self-serve consumers and very small businesses do not want a metered bill; they want a number they can expense. Vendors targeting that segment typically pair usage-based with a small fixed tier that covers predictable work and meters only the long tail.

What product managers should change on Monday

Three moves worth queuing this week. First, audit which AI features in your product are still priced inside the seat and ask whether the cost ratio between a heavy and light seat has widened past the point your seat price can absorb. Second, instrument the meter before the pricing page, not after, so finance and customer success have usage telemetry the day the new tier goes live. Third, decide which surface the customer sees: token counts are an implementation detail, but document counts, requests, or best-dials are a product surface and need a design owner.

The wider direction is clear: as more of a SaaS product's compute becomes model-served, the per-seat abstraction will keep losing ground to the per-action abstraction. Product practice is following the same path, from selling access to selling outcomes and charging for the work the software actually did.