Price an AI SaaS product from customer value, but design the package inside a cost envelope that survives real usage. Measure variable cost at the account and workflow level, model light and heavy customers separately, and choose a billing unit the buyer can understand before setting included usage or overages.
A flat monthly fee can look attractive until one customer runs ten times the expected workload. Pure usage pricing can protect margin while making the buyer afraid to adopt the product. Per-seat pricing can be simple even when seats have little relationship to model consumption.
There is no universal answer. I would build the usage economics first, select a pricing architecture second, and test willingness to pay third. The numbers below are entirely hypothetical—not a benchmark, client result, or description of an existing product.
At Stackmatix, the growth agency I co-founded, the commercial context is acquisition that produces worthwhile customers. For an AI company, that means campaign and sales decisions need to account for what customers cost to operate after they buy, not just what it costs to acquire them.
Start With the Value Unit and the Cost Unit
The customer should pay for access to valuable work, not for your internal technical architecture. But the event that creates value and the event that creates cost may be different.
Consider a product that reviews documents. The buyer may value completed, usable reviews. Your costs may be driven by input length, model calls, retrieval, third-party data, storage, and human exceptions. Charging directly for tokens would expose your cost unit without necessarily reflecting the buyer's value unit.
Write both definitions before discussing price:
| Definition | Question | Hypothetical answer |
|---|---|---|
| Value unit | What completed work does the customer recognize? | An approved document review |
| Usage unit | What event can the customer forecast and audit? | A review submitted for processing |
| Cost unit | What actually changes delivery cost? | Model work, data calls, compute, and review time |
| Account value | What ongoing access or capability exists before usage? | Workflow configuration, controls, and team access |
The billing unit can be the usage unit even when the underlying cost model is more detailed. The job is to make sure a billed review has a defensible value and a measured cost distribution.
The AI software GTM guide helps define the workflow and buyer before pricing it. If the team cannot describe the valuable job, metering it will not create a strong offer.
Build the Full Variable-Cost Formula
Do not stop at the headline model rate. Use a cost record that includes every component that increases when customers use the product more.
Variable cost per usage unit = model cost + retrieval and storage + third-party data and tools + workflow infrastructure + expected human review and recovery.
Calculate expected human cost instead of hiding it inside support:
Expected review cost per unit = share of units requiring review × average cost of one review.
If 2% of completed units need a $6 intervention, the expected review cost is $0.12 per unit. That does not mean every unit costs $0.12 in labor. It means the account economics must fund the exceptions created across the full population.
Keep one-time implementation separate from recurring usage unless implementation repeats as the account expands. Keep product development and general overhead outside direct cost of revenue when that matches the company's accounting policy. The boundary should be documented and applied consistently; ask the finance owner to approve it.
The cost-to-serve analysis covers onboarding, support, and ongoing delivery beyond the meter. Use both views so the usage model does not make high-touch customers look artificially profitable.
Model the Distribution, Not the Average Customer
An average can conceal the customer that breaks the package. Group recent or pilot accounts into meaningful usage bands and inspect the actual cost per unit inside each band.
At minimum, report:
- Median account usage and cost.
- A heavy but legitimate usage case, such as the 90th or 95th percentile when the sample supports it.
- The most expensive normal workflow and why it costs more.
- Exception and human-review rates by customer segment.
- Cost movement after model, prompt, retrieval, or vendor changes.
- Accounts whose usage or cost cannot be explained.
Percentiles are descriptive, not guarantees. A small or hand-selected pilot cannot establish a stable tail. Label the sample period and account population, then stress-test conditions beyond what you have observed.
Use the cohort-analysis guide to keep account age and observation windows comparable. New accounts may have unusually high setup work or unusually low adoption.
Compare the Main Pricing Architectures
Stripe's current subscription documentation describes flat-rate, per-seat, tiered, and usage-based models; its usage-based examples include fixed fee plus overage, pay as you go, and credit burndown. Those are billing capabilities, not evidence that one model is right for your product. Stripe: recurring pricing models.
| Architecture | Works best when | Main risk to test |
|---|---|---|
| Flat subscription | Usage varies modestly and ongoing access creates clear value | Heavy accounts compress margin |
| Per seat | More enabled users usually create more value and cost | Shared or automated use disconnects seats from workload |
| Pure usage | Each unit has visible value and customers can forecast demand | Spend uncertainty discourages adoption |
| Base fee plus included usage | The platform has ongoing value and cost increases after a normal allowance | Included volume is guessed too generously |
| Prepaid credits | Several workflows consume different underlying resources | Buyers cannot understand or audit conversion rates |
| Tiered usage | Larger commitments justify different unit economics | Billing cliffs or discounts outrun cost improvement |
| Outcome based | The outcome is unambiguous and attributable | Disputes over quality, causality, or completion |
For many B2B AI products, a base fee with included usage and an explicit overage is a useful starting hypothesis. It gives the seller minimum recurring revenue, gives the buyer a predictable normal bill, and exposes exceptional usage before it becomes an unlimited obligation. It is not automatically the right final model.
Make the included allowance match a customer workflow, not a round number chosen for the pricing page. If a typical team completes a weekly process, the allowance should be explainable in those terms.
Work Through a Hypothetical Account Model
Assume a fictional AI workflow product charges $2,000 per account per month. The subscription includes 2,000 completed tasks, with additional tasks priced at $0.65 each.
The hypothetical expected variable cost per task is:
| Cost component | Cost per completed task |
|---|---|
| Model inference | $0.03 |
| Retrieval and storage | $0.01 |
| Third-party data and tools | $0.03 |
| Workflow infrastructure | $0.01 |
| Expected human exception work | $0.12 |
| Total expected variable cost | $0.20 |
Now compare three account types. Allocated support includes recurring account work outside per-task exceptions.
| Hypothetical account | Monthly tasks | Revenue | Usage cost | Allocated support | Gross profit | Gross margin |
|---|---|---|---|---|---|---|
| Light | 500 | $2,000 | $100 | $150 | $1,750 | 87.5% |
| Typical | 2,000 | $2,000 | $400 | $200 | $1,400 | 70.0% |
| Heavy | 6,000 | $4,600 | $1,200 | $350 | $3,050 | 66.3% |
For the heavy account, revenue is $2,000 plus 4,000 overage tasks at $0.65, or $2,600 in overages. Gross profit is $4,600 minus $1,200 of usage cost and $350 of allocated support: $3,050. Gross margin is $3,050 divided by $4,600, or about 66.3%.
Those percentages are arithmetic from hypothetical inputs, not target margins. The company must choose its own required margin based on implementation, support, sales model, product maturity, cash needs, and what costs the accounting model includes.
The table exposes two decisions. Light accounts create high percentage margin but may not experience enough value to retain. Heavy accounts produce more gross profit dollars but a lower margin percentage. The right package has to support adoption, retention, and sustainable delivery—not optimize one column in isolation.
Calculate the Overage Floor
If the expected direct cost of an additional task is $0.20 and the company chooses a hypothetical 70% gross-margin requirement on incremental usage, the minimum price implied by that assumption is:
Required unit revenue = direct unit cost ÷ (1 − target gross margin).
$0.20 ÷ (1 − 0.70) = about $0.67 per task.
An overage price of $0.65 would miss that narrow incremental target before any additional support. That does not automatically make the overall package unprofitable because the base fee contributes revenue. It does show that the discount should be deliberate rather than accidental.
Recalculate the floor under at least three cost cases: expected, expensive workflow, and vendor or model price increase. Also test a lower exception rate after product improvements. Pricing should reward genuine cost efficiency without assuming the improvement before it exists.
Avoid Volume-Pricing Cliffs
“Volume pricing” can mean different math. Stripe distinguishes volume-based pricing, where one tier's rate applies to all usage, from graduated pricing, where each tier applies only to usage inside that band. Stripe: tiered pricing.
That distinction matters. A volume threshold can create a point where one additional unit changes the rate applied to every unit. Graduated tiers generally create a smoother bill, although the right structure depends on the commercial agreement.
Show buyers a worked invoice at the boundary. If neither sales nor finance can explain the bill without a spreadsheet, the customer is unlikely to trust it.
Make the Meter Auditable
A billable event needs a stable definition, account identifier, timestamp, quantity, deduplication rule, adjustment process, and customer-visible record. Stripe's billing meters track usage events that can be attached to a price and subscription. That solves part of billing implementation; your product still needs business rules for what counts and how disputes are resolved. Stripe API: billing meters.
Define whether retries, failed tasks, canceled work, test events, duplicate submissions, and reprocessed outputs are billable. Decide what happens when a task starts in one billing period and completes in another. Reconcile product telemetry, invoice quantities, and customer-visible usage before expanding the plan.
Credits require extra clarity. State how many credits each action consumes, when credits expire, whether unused balances carry over, and how a customer can estimate the next bill. Abstraction is useful only when it makes several workflows easier to understand.
Test the Package Before Changing the Price
Pricing interviews should test comprehension and tradeoffs, not ask prospects to invent your number. Show a concrete package and ask the buyer to model a normal month, an unusually busy month, and a low-usage month.
Listen for four different problems:
- The buyer does not see enough value.
- The billing unit does not match how the team plans work.
- The bill is too difficult to predict or verify.
- The total price is outside the feasible budget.
Those problems need different responses. A discount does not repair an incomprehensible meter. More included usage does not create value for an account that cannot adopt the workflow. Use the pricing-conversation playbook to diagnose the objection before changing terms.
Run new packaging beside the existing offer when practical. Track activation, usage distribution, expansion, gross profit, support burden, and retention by package. A higher signup or close rate does not settle the decision if customers later avoid usage or create negative delivery economics.
Use This Monthly AI Pricing Review
| Review field | Decision it supports |
|---|---|
| Active accounts by package and cohort | Whether the comparison population is valid |
| Usage per account: median and heavy case | Whether included volume matches reality |
| Direct cost per usage unit and component | What changed in delivery economics |
| Exception rate and human effort | Whether automation is reducing real work |
| Revenue, gross profit, and gross margin by account | Which segments and packages sustain the business |
| Unused allowance and low-value accounts | Whether customers are adopting and likely to retain |
| Overage frequency and customer disputes | Whether the meter is predictable and trusted |
| Expansion, contraction, and churn reason | Whether pricing supports continuing value |
| Model, vendor, or workflow changes | Whether old assumptions remain current |
| Proposed change and guardrail | What to test next and what must not worsen |
The CAC payback framework connects the resulting gross profit to acquisition economics. Revenue growth can hide a package that takes too long to repay sales and marketing investment.
The goal is not to pass every infrastructure cost directly to the customer. It is to sell a valuable, understandable product without creating an unlimited delivery obligation. Make the unit useful to the buyer, make the cost visible to the company, and make the package survive the customers you most want to grow.
Co-founder and CEO of Stackmatix, startup advisor, and former Head of Sales at MightyHive. Connect with Matt on LinkedIn ↗ · More about Matt →