Charge for the resolution, not the credit. But how much?
HubSpot's AI agents were resolving thousands of conversations a day. The question wasn't whether to charge for that. It was how to price it without quietly pricing customers out of the product that was making them stickier.
What HubSpot actually reported
The simulation had to sit on top of real numbers, not invented ones. In Q2 2026, HubSpot's AI push was already showing up in the business.
That last row matters most: HubSpot had already moved Customer Agent from charging per conversation to charging per successfully resolved conversation. The simulation picks up from there.
Two kinds of customer, one pricing decision
The exercise split a sample of 10,000 Breeze customers into light and heavy AI users, then handed over the economics for both. Flip the card.
Heavy users paid HubSpot ten times more for AI. They also cost more to serve, at a worse margin percentage, while churning less than half as often. No single number settles what to do with that.
The first call: charge for usage
The instinct was credit / consumption pricing. HubSpot had a growing base, heavier users would burn more credits, and more credits meant more AI revenue. Simple, and it prioritized AI revenue over adoption or retention.
Where the reasoning broke
Three separate cracks opened up once the consumption logic was pressure-tested against the simulation data.
| Crack | What the data showed |
|---|---|
| Usage vs. value | "Resolved 14,000 conversations" sells. "Consumed 700,000 credits" doesn't. |
| Revenue vs. margin | Heavy users: $1,000 gross profit at ~20% margin. Light users: $150 profit at ~30% margin. |
| Retention vs. revenue | Heavy users churned at 5% vs. 12%. Squeezing them on price risks the retention gain. |
Revised architecture: pay for the outcome
The pricing logic flipped to outcome-based pricing: customer receives a measurable result, HubSpot charges for that result. It also matched the direction HubSpot's real Customer Agent pricing was already moving.
Running the price-to-value math on the heavy-user segment:
Live price console
A resolution-pricing curve modeled for this exercise, built as a control. Drag it and watch adoption trade off against gross profit in real time. Delivery cost holds steady at $0.29 per successful resolution.
$0.75
72%
Interpolated between four modeled price points: $0.50, $0.75, $1.00 and $1.50 per resolution.
The final call: $0.75
Not the price with the highest adoption. Not the price with the highest margin. $0.75 kept roughly 72% expected adoption while nearly doubling gross profit per customer versus the $0.50 option.
Maximize customer lifetime value while preserving strong AI adoption.
The recommendation wasn't to freeze the price there. Test upward if adoption holds, heavy users keep churning less, and resolution quality stays high — that's price elasticity doing the talking, not a target on a spreadsheet.
Reflection
The reasoning moved from "more usage → more credits → more revenue" to "customer value → willingness to pay → adoption → retention → margin → lifetime value." The low 5% value-capture ratio also didn't trigger an automatic price hike — the question became whether a higher price would suppress the adoption that was driving retention.
Three gaps. First, assuming heavier revenue meant better economics, when heavy users actually ran a worse gross-margin percentage. Second, treating the $98K of customer value as capturable, when pricing power depends on willingness to pay, alternatives, switching costs and proof of value, not on the value delivered alone. Third, not naming the objective early: optimizing for adoption alone points to $0.50; optimizing for lifetime economics points to $0.75.
The highest price you can charge is rarely the price you should charge.
Value created, price charged, revenue captured and profit generated are four different things. Pricing has to hold all four at once.