Manish ChoudharyHubSpot's Pricing Says "Pay When It Works." The Hard Part is Defining "Works."
HubSpot's Pricing Says "Pay When It Works." The Hard Part is Defining "Works."
HubSpot's Pricing Says "Pay When It Works." The Hard Part is Defining "Works."
HubSpot's Pricing Says "Pay When It Works." The Hard Part is Defining "Works."
• 9 min read
• 9 min read

Manish Choudhary
CEO & Co-founder, Flexprice

Last week HubSpot put out a pricing change on their Breeze AI agents. Customer Agent goes from $1 per conversation to $0.50 per resolved conversation.
Prospecting Agent goes from a flat monthly fee per enrolled contact to $1 per qualified lead recommended for outreach. Both on Pro and Enterprise tiers. Starts from April 14.

Cool. But this isn't new.
Intercom got here first with Fin. $0.99 per resolution. They spent months figuring out what "resolution" even means before shipping the pricing.
Zendesk tried something in the same direction and quietly walked it back. So the real question isn't whether HubSpot is being bold.
It's why Intercom made this work, why Zendesk couldn't, and what HubSpot's entry actually says about where all of this is going.
I'll get to that. But first, the thing that caught my attention.
Most AI products charge per token, per seat, per month. They do this because they can't promise outcomes. They're selling access to a capability and hoping you figure out the value on your own. If your AI gets it wrong a third of the time, you really can't afford to only collect revenue when it gets it right.
So when a company says "we'll only charge you when it actually works," that's not a pricing change. That's them telling you they trust their own product.
HubSpot's Customer Agent has a 65% resolution rate across 8,000+ customers.
Their Prospecting Agent is driving 10% higher close rates on 10,000+ deployments. They looked at the numbers and decided they'd rather eat the cost of failures than keep charging for attempts.
That takes conviction. Or good math.Or probably both.
I've been studying what Intercom did differently, and I think three things stand out
They didn't obsess over when to charge but when not to charge. The definition of "resolution" went through months of iteration before it ever went live on a pricing page.
What counts, what doesn't, when the AI gets credit, when it doesn't. That work happened before the model shipped. Most companies do it backwards. They announce the pricing and then scramble to define the terms.
They also didn't bolt outcome pricing onto a broken foundation. Intercom had been iterating on their pricing regularly. Their customers expected pricing to evolve. That matters. If your current pricing is already a mess, layering outcome-based logic on top just makes the mess more expensive to maintain.
And they embedded the first X resolutions into every plan. Let customers experience the value before asking them to pay for it.
Then they unbundled it so Fin could work standalone. That turned an AI feature into a product with its own monetization. Pretty clever, actually.
Now here's where I keep getting stuck
Aisling O'Reilly runs Product & Pricing at Intercom. She posted something 2 months ago that I can't stop thinking about: "A competitor with a lower 'per resolution' price looks cheaper when they might actually be more expensive and deliver less value."

She's right, and this is the part nobody wants to deal with.
With seat-based pricing, a seat was a seat. You could compare across vendors without a decoder ring.
Now every vendor defines "resolution" differently. Some charge even when the agent doesn't do anything useful. Others count resolutions where AI wasn't involved at all.
A lower per-resolution price can actually mean worse economics if the definition is loose enough.
This never used to be a problem. Now procurement teams need to decode competitors' fine print just to compare apples to apples.
They're drowning in incomparable metrics.
For outcome-based pricing to not eat itself, outcomes need to be explicit (defined upfront, no fine print), verifiable (customers can audit what happened), and comparable (means roughly the same thing across vendors).
Right now, we don't have any of that. And I'm not sure who builds it. The vendors? An industry body? Procurement teams just getting smarter over time? I don't know, I don’t have all the answers right now!
Take HubSpot's "resolved conversation." 65% resolution rate means 35% don't get resolved.
What happens to those? Free? Someone absorbs the cost? Right now they're using a credits model, which is fine.
But I keep imagining this in an enterprise deal. Procurement on one side. Custom SLAs. A VP who wants to negotiate what "resolved" means for their specific use case.
"Qualified lead recommended for outreach" at $1 per lead has the same problem.
Qualification is subjective. What's qualified at a 50-person startup is noise at a Fortune 500.
The definition of "done" is going to be where the fights happen. Not the pricing model.
The 28-day free trial is a detail that's easy to skip past
Both Breeze agents come with a trial before pricing kicks in.
If you actually believe customers should pay for results, you should also believe in letting them see results before they commit.
Intercom did something similar by embedding resolutions into every plan. HubSpot is doing their version with the trial window. It's the pricing philosophy applied to the sales motion.
Most companies can't pull this off because the people designing pricing and the people designing the GTM aren't working from the same playbook.
When they are, you get this kind of consistency. It's rare.
Okay. This is the part I really want to get into
Everyone is writing about what HubSpot announced or arguing about whose definition of "resolved" is better. Almost nobody is talking about what it takes to actually run outcome-based pricing on the backend.
This is not a go-to-market issue. It's a billing infrastructure problem.
Think about what the system has to do. Not "charge $0.50 when a conversation happens."
It has to:
ingest an event
figure out whether the defined outcome was actually achieved (using whatever definition the customer agreed to, which might be different from the next customer's definition),
apply conditional pricing logic based on that evaluation,
handle credits
and give the customer enough visibility that they can audit the bill.
That's not $X/seat/month. I mean to be fair it’'s not even regular usage-based billing, which at least has a clean line between event and charge.
Outcome-based billing puts a judgment layer between the event and the invoice. Did the outcome happen? By whose definition? Under what terms?
And the definitions will keep moving. Today it's resolved conversations and qualified leads.
In six months it might be pipeline generated, churn prevented, deals closed. Each new outcome means new metering, pricing logic, and brand new billing workflows.
The companies making these pricing moves need their billing infrastructure to change as fast as their pricing does. If updating a rate card requires an engineering sprint and a deploy, you're already behind.
This is what we spend our time on at Flexprice. The gap between what pricing pages promise and what billing systems can execute just keeps getting wider.
HubSpot has the engineering depth to build custom billing for two agents. Most Series A and B companies experimenting with this stuff don't. They need pricing model changes to be configuration, not code.
Get started with your billing today.
Get started with your billing today.
I don't have a clean framework for any of this
Outcome-based pricing is clearly directional. Intercom proved the model. Zendesk proved that half-committing to it doesn't work. HubSpot is the biggest CRM to jump in, and they're doing it across support and sales, which is new.
But for every company that's made this move, there are hundreds stuck with some mix of seats, usage, credits, a platform fee, and custom deal logic held together with spreadsheets. That's where most growing companies actually are.
And it's where the tooling fails hardest.
The promise of outcome-based pricing is real alignment between what a vendor delivers and what a customer pays for. That's too good to let bad definitions or rigid billing systems break it.
I guess we'll see.
Frequently Asked Questions
Frequently Asked Questions
What is outcome-based pricing and how is it different from usage-based pricing?
Why did HubSpot switch Breeze agents to outcome-based pricing?
Why did Intercom's Fin pricing work when Zendesk's didn't?
What's the hardest part of running outcome-based pricing?
How should buyers compare outcome-based pricing across vendors?

Manish Choudhary
Manish Choudhary
Manish Choudhary is the CEO and Co-founder of Flexprice, the open-source billing engine helping AI and SaaS companies monetize faster. He writes about pricing, product-led growth, and the future of usage-based billing.
Manish Choudhary is the CEO and Co-founder of Flexprice, the open-source billing engine helping AI and SaaS companies monetize faster. He writes about pricing, product-led growth, and the future of usage-based billing.
Share it on:



























