Twilio recently changed the pricing for its Video product.

The free 5,000 hours are gone. So is the $150-per-seat license.

Now it's simple: $0.004 per participant-minute, billed based on actual usage.

No seats. No license. No free tier.

That's clearly usage-based pricing.

But is it value-based pricing?

Not really.

There are two separate questions every pricing model needs to answer:

1. How do customers pay?

With a license, the customer pays upfront and takes the risk that they won't use everything they bought.

With usage pricing, they pay afterward based on what they consumed. The vendor takes more of the risk.

Credits sit somewhere in between.

That's the payment model. It changes how risk and cash flow are distributed between the customer and vendor.

But it doesn't tell you what you should charge for.

That's the second question.

2. What do customers pay for?

This is your pricing metric.

And the best metrics tend to move with the value customers receive.

Twilio changed the first part of the equation, but not really the second.

A telehealth company doesn't buy Twilio because it wants more participant-minutes. It wants to deliver consultations.

Participant-minutes are simply a convenient way to measure the infrastructure Twilio provides.

So Twilio went from charging customers upfront for access to charging them afterward for consumption.

Different payment model. Same basic pricing metric.

And for Twilio, that makes sense.

Its buyers are developers who already think in minutes, calls, messages, and API requests. When you sell infrastructure, charging for infrastructure usage can be perfectly reasonable.

The mistake is assuming that moving from seats to consumption automatically means moving closer to value.

It doesn't.

Think about pricing as a simple 2x2.

Image shows: Rows are the payment model: license or usage. Columns are the metric: priced on cost or priced on value.

Twilio moved from one row to another.

The bigger opportunity for most SaaS companies is moving from one column to another.

We've seen clients do exactly that: replace a flat per-seat fee with a charge tied to delivered results.

Interestingly, the immediate deal size often doesn't change much.

But the sales conversation gets a lot easier.

Customers understand what they're paying for because the bill moves with something they actually care about.

So why don't more companies price this way?

Because cost is much easier to measure than value.

You can count minutes, API calls, tokens, or compute this afternoon.

Charging per resolved claim, completed workflow, qualified lead, or successful outcome is harder. First you have to agree with the customer on what "resolved," "completed," or "successful" actually means.

So companies gravitate toward the thing they can easily measure.

Then they call it value-based pricing.

Two years later, NRR is flat and the sales team is still explaining why the bill went up.

A better way to approach it:

1. Place your current model in the 2x2. Are customers paying upfront or based on usage? Are you charging for your costs or their value?
2. Map the customer's value chain. Start with what your product does and work toward the outcome the customer actually wants. Where does your current metric sit?
3. Move one step closer to value. Don't jump straight to the ultimate business outcome. Find the closest metric to value that you can reliably measure and invoice.
4. Ask customers if it feels fair. Not whether they "like" it. Ask whether paying for that unit makes sense. Pay attention to where they hesitate.
5. Then choose the payment model. Seats, usage, credits, prepaid, or postpaid is a separate question. Don't let it dictate your pricing metric.
6. Test it with new customers first. If it works, figure out how to migrate the existing base.

The distinction is simple:

How you charge determines who carries the risk.

What you charge for determines how closely your revenue follows customer value.

Don't confuse the two.

One Idea...

SaaS vendors are reducing included capacity while keeping list prices unchanged

This week alone, Deno, Apify, and Shapr3D all trimmed included capacity without touching the sticker price.

Storage caps trimmed. Seat allowances cut. Included volumes reduced. A free tier removed entirely. (Twilio's free hours, above, is one instance of this.)

Is that a price increase?

Functionally, yes.

It just doesn't show up as one on the pricing page, which is exactly why teams reach for it instead of raising the number itself.

It also lands on the right customers first. The heaviest users hit the new capacity ceiling before anyone else notices, and heavy users are usually where you were underpriced to begin with.

So what's the actual failure mode here?

Nobody told them.

A customer who hits an unannounced capacity cut doesn't experience a pricing decision. They experience the product getting worse.

They open a support ticket instead of a negotiation. That costs you goodwill, and goodwill doesn't come back with a discount.

If you're cutting capacity, run it like a price increase. Announce it. Give a window. Let existing customers buy their way back to where they were.

A capacity cut is a price increase. Treat it like one.

Willingness to Pay News

The Pricing Metrics guide is live

The four parameters of a good metric, the grid above, and worked examples. If today's newsletter made you want to re-grid your own model, this is the document to do it with.

Podcast: Pricing Page unPacked - new teardowns keep coming

New teardowns keep landing on Pricing Page unPacked.

Catch the latest here.

PS: Take your main pricing metric and ask whether it's something the customer wants more of, or something they want less of. If it's the second one, you're not underpriced. You're mis-metered.