Pricing an AI feature is awkward because two things pull in different directions. Customers want predictable costs. The feature has unpredictable running costs, and they grow with use.
When we took Frontline to enterprise clients at WiZR, the commercial conversation came up early in almost every deal. Buyers wanted to know what they'd pay, what happened if their teams used it more than expected, and whether they'd be surprised by a bill. Those questions shaped the packaging as much as the feature set did.
I wrote about working out cost per user separately. This post is about the pricing side.
The main options
| Model | How it works | Good for | Watch out for |
|---|---|---|---|
| Bundled | AI included in existing plans | Driving adoption, simple sales | Heavy users eat the margin |
| Paid add-on | Flat extra fee per seat or account | Clear value, predictable revenue | Low uptake if the value isn't obvious |
| Usage-based | Pay per request, document or output | Matching price to cost | Buyers dislike unpredictable bills |
| Credits | Prepaid allowance, top up when used | Predictability with a usage link | Credits can feel confusing or stingy |
| Tiered limits | Plans include different usage levels | Separating light and heavy users | Hitting a limit mid-task is frustrating |
There isn't a universally right answer. It depends on how variable usage is, how clearly customers can see the value, and how much your costs depend on volume.
What I'd look at first
How spread out is usage? If most customers use roughly the same amount, bundling or a flat add-on is simpler. If a few customers use vastly more, you probably need limits or usage pricing somewhere.
Can the customer see the value? If the feature clearly saves time on a task they already pay people to do, a separate price is easier to justify. If the value is vague, bundling may be the only way to get people to try it.
Who's buying? A procurement team usually wants a fixed annual number. A team lead with a credit card may be fine with usage pricing.
What enterprise buyers push back on
In my experience, the objections are fairly consistent:
- "What if our usage spikes?" They want a cap or at least a warning.
- "What exactly counts as a unit?" If a credit or request isn't clearly defined, they assume the worst.
- "Do we pay for bad outputs?" If they have to regenerate a lot, paying per request feels unfair.
- "Can we forecast this for the year?" Finance needs a number.
Offering a committed volume with clear overage terms, or an annual plan with included usage, often answers most of these.
Define the unit carefully
If you charge per something, make it something the customer understands. "Per generated document" is easier to reason about than "per thousand tokens." The customer doesn't care about tokens. They care about the work.
That also means you take on the risk of some documents being expensive to produce. Build that into your cost model.
Start simpler than you think
Early on, I'd lean toward a simple structure, even if it leaves some money on the table. Complex pricing slows deals and makes it hard to learn what customers actually value.
Watch usage closely for the first few months. Look at who's heavy, who's light, and whether the heavy users are getting proportionally more value. Then adjust. It's much easier to add a usage tier later than to remove one customers already hate.
Whatever model you pick, check it against the cost model at least once a quarter. Usage patterns change, provider prices change, and a plan that made sense at launch can drift into losing money without anyone noticing.