How to Price AI Features Without Pulling Customers Down From Your Higher Tiers

Most software companies are placing AI capabilities into an existing price list that was designed before those capabilities existed. The decision looks small. It is usually made by whoever is closest to the launch, under time pressure, and it is one of the few pricing decisions that can reduce revenue immediately.

The failure mode is specific. An AI feature lands in a mid tier. Customers on the tier above look at what they are paying for and find that the main reason they upgraded is now available one level down. They do not churn. They downgrade at renewal, quietly, and the loss shows up as a weak expansion number rather than as a pricing problem.

Almost nobody feels confident here

The uncertainty is close to universal. Of 175 signups to the AI pricing tool Paid in 2025, 130 of them, or 75%, said they were not sure how to price their AI features.

That number is worth holding onto, because the temptation when making this decision is to assume everyone else has worked it out. They have not. Three quarters of a self-selected group of companies actively looking for help with AI pricing said they did not know where to start.

In text: 130 of 175 signups to the AI pricing tool Paid said they were not sure how to price AI features. 75% of that group, in 2025.

Two inputs decide the placement

The decision needs two numbers before it needs an opinion.

What it costs to serve. AI features have a marginal cost that moves with use. That cost determines whether the feature can sit in a plan at all without a usage limit, and it sets the floor under any price you charge.

What customers would otherwise pay for the same result. Not what they say they would pay for the feature. What the outcome currently costs them in staff time, in another vendor, or in work not getting done.

ICONIQ's January 2026 State of AI snapshot, as reported by SaaStr, found that AI product gross margins are projected to rise to 52% in 2026 from 41% in 2024. Those are not the margins software companies are used to, and they are the reason cost to serve has stopped being an afterthought in pricing decisions.

Three placements and what each one assumes

In an existing plan. Appropriate when the cost to serve is low and predictable, and when the capability is becoming table stakes. The assumption you are making is that the feature's value is defensive: it protects renewals rather than earning new revenue. If that assumption is wrong you have given away a monetizable capability.

The critical check is which tier. Putting it in the lowest tier that can support the cost is usually wrong. Put it in the tier where it reinforces the reason customers chose that tier, not the tier that undercuts the one above.

As a paid add-on. Appropriate when only a subset of customers want it, when the cost to serve is material, or when you do not yet know the demand. This is the reversible option. An add-on that sells well can be folded into a tier later. A capability given away in core cannot be pulled back out.

As a usage or credit allowance. Appropriate when consumption varies widely between customers and the cost scales with it. This aligns revenue with cost, and it moves the forecasting burden onto you and the budgeting burden onto the customer.

In text: 1. Measure cost to serve per unit of use 2. Estimate what the result is worth to the customer today 3. Check which tier the feature would undercut 4. Place in tier, add-on or credit allowance

The tier erosion check

Before launch, there is one test worth running explicitly.

Take the tier directly above where you plan to put the AI feature. List the reasons a customer currently pays for that tier instead of the one below. If the AI feature is on that list, or displaces something on it, you have created a downgrade path.

The fix is usually not to move the feature up. It is to recognise that the upper tier's value proposition has become thin and needs something added to it, which is a packaging problem rather than an AI problem.

Decide the limit at the same time

Any AI capability placed inside a plan needs a boundary. Unlimited use of something with a real marginal cost is a bet that your heaviest customers will behave like your average ones.

The boundary can be a monthly allowance, a rate limit, or a fair use policy with a defined response when it is exceeded. What it cannot be is nothing, because the alternative is discovering your worst-case cost in production.

Setting that limit at launch is far easier than introducing one later, when customers have already built workflows on the assumption that the capability is unmetered.

If you are deciding where an AI capability belongs in your price list, our pricing and packaging work covers exactly this.

Related reading: Why AI Gross Margins Sit Near 50% and Using the Product Roadmap to Decide What Creates Value and How to Charge for It.