Price the robot, the software, and theoutcome

We want to monitor discounting % per package, usage of features within the packages, upsell rate of features to see whether we have a good pricing motion or whether it needs adjusting.

Package AI agents by mapping each tier to a distinct customer segment's needs - not by arbitrarily gating features into good-better-best. The packaging should reflect what each segment values, their deployment complexity, and their willingness to pay.

‍

The most common mistake companies make is creating three tiers and slotting features based on engineering effort rather than customer value. You end up with enterprise customers shoehorned into a top-tier plan stuffed with features they don't use, which leads to heavy discounting, shelfware, and ultimately churn. Or mid-market customers forced into plans that are too restrictive, slowing their sales cycle.

‍

Start by identifying your segments clearly and building an Ideal Customer Profile (ICP) for each. Common segments for AI agent products include: SMB/self-service companies with straightforward use cases and smaller budgets; mid-market companies with moderate complexity that need faster deployment; and enterprise companies with complex integrations, compliance requirements, and high willingness to pay for customization.

‍

For each segment, build a package that matches their buyer persona and deployment model. A mid-market package might include standard AI models, pre-built workflow templates, self-service deployment, and standard support. An enterprise package adds custom AI model fine-tuning, bespoke integrations, dedicated customer success management, advanced analytics, and premium SLAs.

‍

The usage allocation in each tier should scale with the segment's typical consumption. Use a bundled-credit model where each tier includes a set amount of AI agent usage (resolutions, workflows, transactions), with overage rates that create a natural upgrade path to the next tier.

‍

Critically, consider whether your AI capabilities should be an add-on versus included in the base tier. We use a simple rubric: If the feature has broad demand and high willingness to pay, include it in the base and monetize it across tiers. If demand is niche but willingness to pay is high, offer it as an add-on. If it's table stakes, include it everywhere. 

‍

Salesforce, for example, offers Agentforce as tiered add-ons at $125-$150/user/month for unlimited internal agent usage, while also providing consumption-based Flex Credits for companies that want to scale more gradually. Intercom includes its Fin AI Agent in all plans with a simple $0.99-per-outcome model because broad adoption is more important than per-feature monetization. Nullify, in the security space, charges $800 per agent per year - treating the AI agent as a licensed "employee" - because the target segment is narrow but has very high willingness to pay.

‍

For enterprise deals with highly variable requirements, consider a modular, a-la-carte packaging approach similar to ServiceNow - where deals are custom-scoped based on specific modules, usage levels, and professional services. This allows you to maximize deal value from high-willingness-to-pay segments rather than capping revenue with fixed tiers.

‍

Segmentation for a seat-to-usage transition uses two axes the seat-pricing world ignores: consumption readiness and cannibalization exposure.

Consumption readiness. How prepared each segment is to absorb the new pricing model. Power users on heavy workflows are usually consumption-ready. Light users on broad-access bundles are not. Self-serve segments adopt faster than procurement-heavy enterprise.

Cannibalization exposure. What share of current ARR drops under each scenario. Shelfware accounts (paying for seats they do not use) and light users on heavy bundles are highest risk. Power users on light bundles are lowest risk and often expand under consumption.

The segmentation drives migration sequencing: highest-readiness, lowest-cannibalization-risk segments migrate first. Highest-cannibalization-risk segments either get grandfathered, restructured at renewal, or moved last with bespoke handling. The segmentation model is built before the rate card is set.

‍

A unified token currency translates heterogeneous events (API calls, AI actions, data lookups, model inferences, UI interactions) into a single billable unit the customer understands and can budget against.

Five design decisions: - Token-to-event mapping. What costs one token, what costs ten, what costs a hundred. The mapping should reflect underlying cost and customer-perceived value, not just technical cost. - List token pricing. Dollar-per-token at list, with volume discounts for committed bundles. - Bundle structures. Pre-purchased token packs with rollover rules and expiration policies. - Cross-product fungibility. Whether tokens spent on Product A can also pay for Product B. Fungibility increases customer flexibility and complicates revenue recognition. - Customer education. A clear mental model of what one token does. ZoomInfo, OpenAI, Salesforce Agentforce have all iterated multiple times on token communication.

The token design must be aligned with metering, CPQ, and billing specifications. Designing the token model and the systems separately is the most common reason consumption launches confuse customers.

‍