Price AI products around work customers can verify.

Adding AI changes what a product can do and what each completed task costs. It does not automatically make seat pricing obsolete or make “ARR per agent” the right measure. Start with the work customers value, the part your product controls and a billing unit both sides can verify.

An agent is an implementation choice. A customer could run several agents to complete one task or use one agent across many tasks. Counting agents without a consistent definition can obscure usage, value and margin. Keep recurring revenue measures clear, and evaluate the economics of the work underneath them.

Define what counts as completed work

Choose a recognizable task: an accepted intake, a reviewed document or a resolved support request. State the completion rule before attaching a price. Distinguish a suggestion, an attempted action and a confirmed result.

For a hypothetical support product, define whether a reopened conversation counts as the same case, when a resolution becomes billable and how the customer disputes an incorrect charge. If the product cannot reliably observe resolution, usage pricing may be more defensible than calling the charge outcome-based.

Compare pricing models against the same workflow

• Seat pricing: useful when continuing access, collaboration and human work carry much of the value. Examine what happens if automation reduces the number of active users.
• Usage pricing: ties charges to a measurable unit such as processed documents. Define treatment of retries, duplicate submissions and failed processing so customers can forecast the bill.
• Outcome pricing: can fit work with an agreed, observable completion rule. Account for corrections and outcomes that depend on actions outside the product's control.
• Hybrid pricing: can combine platform access with a usage allowance and overage. Explain what each component pays for and avoid charging twice for the same value.

Test the options with representative accounts, including a heavy user and a customer with complex exceptions. Compare the customer's expected bill with the work received and your cost to serve. A tidy pricing page is not enough if a normal month's usage produces an unexpected invoice.

Count the cost of accepted work

Model inference, retrieval, storage, third-party services, retries and required human review. Include support and the cost of correcting failures. Separate initial implementation from recurring delivery so the team can see which costs change with volume.

For each customer group, compare revenue from accepted work with those delivery costs. Examine variation across simple and difficult tasks. An average can conceal a workload that consumes substantially more resources than its price covers.

Include the evaluation and monitoring needed to keep the product useful as inputs or connected systems change. Reducing those costs by skipping necessary checks does not demonstrate healthier economics.

Make limits and permissions part of the product

Customers need visibility into usage, remaining allowance and projected charges. Give administrators a way to set spending limits and decide what happens when they are reached. A paused workflow, a reduced service and an automatic overage create different operating consequences.

Keep authorization separate from pricing. Paying for more usage should not give an assistant broader permission to change customer records. Expansion may require a new approval rule, an additional integration or a different review process, even when the commercial plan already allows it.

Test the commercial model before migrating accounts

Calculate a trial bill from representative historical usage while leaving existing customer charges unchanged. Inspect disputed completion cases and compare cost by workload. Explain the proposed model to customers and test whether they can predict and reconcile the bill.

Use the results to decide whether to retain seat pricing, introduce a bounded add-on or migrate part of the product to a different unit. Set the transition, allowance and correction rules before expanding. The objective is a commercial model that funds reliable delivery and gives customers a clear reason to use more of the product.