How to Price Your New AI Features (Without Guessing)

A member of our SaasRise mastermind stood up recently with a good problem to have. His company, which builds enterprise data management software for large, conservative customers, had just shipped the first version of a new AI assistant. It answers product questions, explains best practices, and pulls from years of internal documentation the company had never made easy to search before. The next version will look at a customer's actual data and flag what is wrong with it. The version after that will start fixing the errors itself. Two thirds of the way through that roadmap, he still had not figured out how to charge for any of it.

That is not a niche problem right now. A lot of us are shipping AI features faster than we are figuring out how to price them, because the pricing question is genuinely harder than the engineering question. Traditional SaaS pricing assumes your costs are basically fixed per seat. AI breaks that assumption, since every query costs real money in compute, and one customer running a heavy workload can cost more than a whole tier of ordinary users. Get the model wrong and you either bleed margin on your heaviest users or you throttle the feature so hard nobody bothers using it, which defeats the point of building it.

• It's not seat-based anymore. Usage swings wildly between customers doing the same job, so a flat per-seat price stops matching your actual cost to serve.
• Costs are variable and real. Every AI query burns compute you are paying for directly, unlike a feature that just sits in your codebase.
• Underpricing is dangerous. A single heavy user can quietly cost you more than an entire tier of normal customers if you are not tracking it.
• Overpricing kills adoption. If the feature is capped so tightly that people hit the wall constantly, they stop using it, and you lose the feedback loop you need to improve it.

Why Your Enterprise Customers Can't Handle Dynamic Pricing

The first instinct a lot of founders have is to price AI the way the AI labs price it: pay for what you use, billed by the token. It is clean, it is fair, and it matches cost to revenue almost perfectly. But it only works if your customers can actually absorb a bill that moves every month, and a lot of B2B customers simply cannot. The founder presenting his topic put it plainly: his customers are large, process-heavy organizations that take a long time just to generate a P&L internally. Handing them a different invoice every single month was never going to fly, no matter how fair the math was on the back end.

This is where a lot of founders miss the actual lesson from token-based pricing. Usage-based billing isn't wrong, but your customer's ability to budget matters as much as your ability to measure cost. If procurement needs a fixed number for finance, a variable invoice creates friction before the product even gets used. The fix several members converged on was tiered pricing with usage caps: set a token allowance per tier, customers know exactly what they're paying, and when they consistently hit the ceiling, that becomes your natural signal to move them up rather than a pitch you have to make cold.

• Match the model to the buyer, not just the cost. If your customer needs a predictable number for their budget process, token-metered billing fights against how they actually operate.
• Set a cap, not a meter. A fixed monthly token allowance per tier gives customers price certainty while still keeping your cost exposure bounded.
• Let the ceiling do the selling. When a customer keeps hitting their cap, that usage pattern is a far stronger upgrade conversation than any sales pitch.
• Expect the complaint, and use it. When usage hits zero because the cap is reached, the resulting support ticket is actually a qualified expansion lead if you treat it that way.

That last point is worth sitting with, because it flips how you should feel about a customer maxing out their tier. Most founders treat hitting a usage cap as a failure state, something to apologize for. Treat it instead as the data point that tells you a customer wants more of the feature, which is a healthier place to start a pricing conversation than a cold upsell call.

Split Your Tiers by Token Intensity, Not Just Volume

Once you have accepted that tiers with caps beat a raw usage meter, the next question is how you draw the lines between tiers. The temptation is to just pick round numbers, tier one gets X tokens, tier two gets 2X, and call it done. One member offered a sharper version of this in the discussion: sort what the AI does into cheap operations and expensive ones before you ever draw a tier line, then gate the expensive capabilities, things like generation or deep analysis, behind a specific tier instead of trying to meter and explain them after the fact. Do that up front and you skip the token negotiation entirely, because you never have to argue token counts customer by customer.

Generating a video, for instance, burns far more compute than answering a text question, and the founder presenting his own roadmap picked up on this immediately, because his AI assistant has a similar split hiding inside it already. A lot of what it does is simple lookups against a knowledge base, which is cheap enough to include broadly in the base plan without hurting margin. But the more advanced version, the one that reasons over what's actually happening in a customer's live data, requires meaningfully more processing per query, which makes that split a natural tier boundary, and it belongs in the tier built to carry that cost. The practical move is to start tracking usage by feature type early, well before you set pricing, so the split you draw is based on real data instead of a guess.

Decide What You're Actually Charging For

This is where the conversation got genuinely useful, because it surfaced a distinction that is easy to miss when you're excited about a new AI feature. Another founder in the room raised a version he'd wrestled with himself: if your AI produces something concrete, a generated video, a written report, a finished asset, you can reasonably charge per deliverable, because the customer is clearly getting something new. The gray area is everything else, the answers rather than the outputs. A lot of what these assistants do isn't a new deliverable at all, it's just answering a question the customer already had, and that's a riskier thing to charge for, because if the answer only exists because your product is hard to use, billing for it runs into a much stickier problem.

A third founder made the point directly: if customers are asking basic questions because the software is confusing, and you start charging to answer those questions, you've just monetized your own onboarding gap. That's not a good trade. The founder presenting his roadmap landed on the right instinct on his own, reasoning that AI is going to stress-test documentation nobody reads, and that the resulting usage is valuable feedback whether or not it generates revenue. The line he drew: answering "how do I do this" stays free, while proactive best-practice guidance and packaged expertise, the stuff beyond just explaining your own product, is worth charging for.

• Don't charge to explain your own product. If AI is answering questions your documentation should have answered, charging for that just monetizes a gap you should be closing instead.
• Treat basic Q&A as a feedback channel. Every question the AI answers is a signal about where your product or docs are confusing, and that signal is worth more free than gated.
• Reserve paid tiers for expertise, not explanation. Best-practice guidance, proactive recommendations, and packaged know-how are a different product from support, and that's what customers will actually pay for.

Once you separate those two things, the pricing conversation gets a lot cleaner. You are no longer trying to price "the AI feature" as one blob. You're pricing a support layer that should stay close to free because it protects retention, next to a genuine expertise layer that customers will pay a premium for because it does something they could not easily do themselves.

Drive Usage Before You Finalize the Price

The founder who brought this topic to the group made one more decision that is worth calling out on its own, because it runs against the instinct a lot of us have to lock in pricing early. He has deliberately not started pricing conversations with customers yet, even though he is two thirds of the way through the product roadmap. His reasoning is that he needs every customer actually using the feature and giving feedback before he commits to a price, because pricing a feature nobody has really used yet is just guessing with extra steps. Getting usage first means the eventual tiers get built around real behavior instead of a hunch about what customers might do.

• Delay the price, not the launch. Ship the feature and get it in front of every customer before you lock in what it costs.
• Let real usage set your tier boundaries. A usage dashboard tells you where customers naturally cluster and hit limits, which is far more reliable than a guess made before launch.
• Use the free period to fix the product. Early feedback while the feature is free is cheaper to act on than feedback that arrives after customers already feel like they overpaid.
• Set the tier one cap deliberately low. A tight initial limit creates the natural upgrade moment once customers are already hooked on the feature.

What Getting This Right Is Actually Worth

It's worth remembering why this is worth getting right. Ryan shared an example from another member of our mastermind who'd gone through this exact exercise with a different product, a real estate CRM tool. As Ryan put it, "One of our members rolled out new AI functionality inside his product, and he was able to add several million dollars in additional annual recurring revenue, over roughly a three- to four-month period, just from getting the pricing right." That's not a small line item. It came from treating AI pricing as its own strategic decision instead of an afterthought bolted onto the existing plan.

The pattern across every example here points the same direction. Tier by cost, cap instead of meter, separate support from expertise, and get real usage data before you finalize a number. None of that is complicated once it's laid out, but almost nobody does it by default, because the instinct is to copy the token-metered model everyone talks about, or just pick a number and hope. If you're sitting on a new AI feature right now, the real work isn't the pricing spreadsheet. It's getting the usage data that makes the spreadsheet obvious.