Pricing is still the single most popular topic I discuss with founders, as it has been for more than a year. For those selling to enterprise buyers, there are two primary tensions that make AI-native pricing much more difficult compared to traditional SaaS pricing: 1) cost structures are highly variable, with there often being a (material) marginal cost to serve, and 2) product value and ROI are harder to quantify given how early we are in AI’s journey broadly. My team is constantly pulsing both builders and enterprise exec buyers to understand how pricing dynamics are evolving real-time. The unsatisfying truth is there’s no ‘silver bullet’ or one-size-fits-all AI-native pricing model that works for everyone – but there are observable patterns that can help you fine-tune your pricing.

The Builder POV

Builders within and outside of the BCV portfolio almost universally express that their pricing models have changed significantly over the past six months, and will evolve again in the near future. Many founders come to us looking for a pricing model playbook, when in reality pricing should be quite bespoke to your product, the industry and segment you sell into, prospect budgets, and your company stage (e.g. how much credibility you have). We’ve outlined guiding principles across three core elements of pricing to help: product pricing models, POCs and implementations, and contract terms.

Pricing models:

Pricing models can be broken down into three main components: fixed pricing (e.g., fixed annual fees), variable pricing (e.g., token consumption), and services / labor (e.g., project-based FDEs). The majority of successful enterprise pricing uses a hybrid model: a combination of two or more of these components.

Hybrid (fixed and variable) model

• True about your product: Marginal cost to serve is material and variable, but bounded enough that a base fee can absorb the floor. There's enough usage data to eventually price toward value.
• True about your buyer: Wants some predictability, but will tolerate a variable layer if it's transparent and tied to something they both control and see as valuable.
• Strategic considerations: There must be sufficient value built into the core product to justify a base platform fee – i.e., features and capabilities beyond agent runs. As the product continues to develop, platform ‘tiers’ with appropriate feature-gating can be introduced. Most companies we spoke with are actively shifting the mix of fixed vs. variable over time, typically moving revenue from the variable component toward the fixed component as the product matures and telemetry gets better.

Example: An AI support company sells to a large enterprise on a mid-six-figure annual contract with two parts. The first is a fixed platform fee that gives the customer access to the full product, not just agent runs. The second is a variable layer tied to something the customer already sees as valuable, such as conversations handled or resolutions completed. The platform fee is the smaller share of the bill, but it gives the company a predictable base so they aren’t relying on usage alone. Usage makes up the larger share and grows as the customer rolls the product out more widely. As the company builds out the product, they are able to charge a higher fixed component.

Pair predictability with upside: a committed base gives customers certainty while variable pricing lets vendors participate in growth.

Pure fixed model

• True about your product: Marginal cost to serve is low or stable, or the product is early enough (e.g., still meaningfully human-in-the-loop) that usage isn't yet a credible proxy for value.
• True about your buyer: Strong preference for budget certainty — especially pronounced when selling into finance/back-office buyers, who plan in fixed annual increments.
• Strategic considerations: Risk of margin erosion if adoption scales faster than the fee. Several companies build in structured repricing triggers tied to significant account growth rather than raw consumption, so the fee can flex without becoming a usage meter in disguise.

Example: A cybersecurity company sets a flat annual fee based on the number of assets (servers, cloud infrastructure, code repos, web apps) scoped during a POV. The buyer gets one predictable number with no usage meter, and large customers get meaningfully lower per-asset rates. Short-lived assets like containers aren't billed, which keeps the count simple and removes a long-standing complaint with legacy vendors. The fee re-prices only if the asset base grows meaningfully beyond an agreed band (e.g., +/-10%) vs. being dependent on how heavily the product is used. That protects the company from margin erosion as the account scales, but usage broadly isn’t discouraged by increasing costs.

Usage should inform the bill, not make it unpredictable—the best models put guardrails around variable spend.

Pure variable model

• True about your product: Cost to serve maps directly to usage (token- or compute-heavy inference). The vendor ideally has some sort of infrastructure competitive edge – e.g., cheap inference costs as a hyperscaler. Otherwise, pricing effectively turns into a “cost plus” model, where another entity (e.g., frontier lab) controls margins.
• True about your buyer: Typically skews to one of two extremes: 1) familiar with how AI products work and confident in the value the product will deliver, and therefore willing to pay for it, or 2) AI skeptic who doesn’t want to commit to any spend before seeing how it translates to their business environment.
• Strategic considerations: Most doing pure variable pricing has translated raw usage into a business-legible unit (e.g., a compute credit) rather than billing on tokens directly. Ideally, usage is being sold in larger usage ‘packages’ – e.g., 5K credit increments – that roughly translate to volumes of work. A thoughtful POC or scoping process should be used to determine the minimum usage billed for via an annual contract, with additional usage/credits/compute available for purchase ad hoc if needed.

Example: An AI audit automation company sells purely usage-based contracts to large enterprises. The variable component is “per audit control”: an abstracted unit of work the buyer understands, vs. compute or credits. There is no “platform fee”. The vendor runs a free POC (which is industry standard) to scope work, but the customer pre-commits to a minimum annual spend to align incentives. This minimum sets the floor on the contract and gives the prospect a reason to take the POC seriously; it automatically converts unless they opt out at the POC’s end. Once the customer is live, the account can expand quickly as more controls go live.

Pricing should move up the value curve as the product matures—from access, to usage, to workflows and ultimately outcomes.

POCs and implementation:

Product trials and implementation plans can feel like afterthoughts, but intentionally designed POC/implementation motions can be extremely effective commercial tools.

POCs/POVs/Pilots: Enterprise buyers almost always want to try before they buy, particularly with new AI tech. This is the best mechanism to scope both cost and impact, which should inform your full-term contract pricing. Successful POVs should:

• Start with pain. Prospects may instinctively want to start with something low-risk or low-impact; push them to start where there is acute pain so they can really feel the impact of your solution. Start with a specific use case, team, geography, or otherwise confining variable. Limiting scope makes it much easier to wrangle stakeholders and evaluate success.
• Be timeboxed. Come to the table with scheduled milestones to keep everybody on track and accountable. You don’t want prospect-caused slippage to fall back on you. Have clear go/no-go decision dates and objective success criteria.
• Require a dollar exchange for cost of labor. Paid trials are a great way to ensure a prospect is serious, align key stakeholders, and get through procurement red tape before the final contract is issued. Paid POCs are rarely margin-accretive. They should roughly cover the cost of trial labor, but otherwise be nonprohibitive. If free POCs are standard for your industry (e.g. Audit), this does not apply.

As your company scales, your POC-to-contract conversion rate may actually decrease. Many founders share that earlier conversion rates were inflated by high-touch, founder-led selling into warm relationships. As go-to-market broadens, conversion normalizes toward a less favorable (but more sustainable) baseline.

Implementations: These will generally not be huge moneymakers (compared to legacy SI implementation, where fees are substantial). They are frequently treated as a loss leader or an easy concession that is useful for closing deals, especially with more process-heavy or PE-backed buyers. If implementation of your product requires multiple months and several expensive resources, that is another story; it’s worth trying to at least recoup costs.

Contract terms:

Founders selling to enterprise buyers ask about two things related to contracts: enterprise minimum enforcement, and accommodation of bizarre SLA requests. Fortunately, there is much more consistency here:

1. Have an enterprise minimum and enforce it. Because enterprise scoping is resource-intensive, you need to have internal guardrails on the threshold that makes that investment worth it. Where you set that enterprise minimum depends on your ACV and prospect budgets.
2. Strike custom SLAs around anything too far out of your control. Common SLAs that founders usually agree to include latency (though rarely enforced) and model routing (i.e., maintaining a certain quality level in models used, or avoiding open-source / foreign models entirely). Less common SLAs that should be avoided are requests around hallucination rates, which are controlled by the model builder versus you (the vendor). If you don’t control it, don’t guarantee it.
3. Use account health signals to trigger expansion conversations, versus waiting for renewal. Many vendors ride positive momentum into proactively proposing expansion versus waiting until the formal renewal period. Annual contracts are helpful for establishing minimums, but shouldn’t limit upside.

The Buyer POV

Let’s complement the above with intel from enterprise buyers. We maintain extensive executive networks through our Advisory Boards and industry partners to get direct pricing feedback from the folks who own the budgets. We host private executive dinners, curate large CTO/CIO tech summits, and field surveys to get their unvarnished thoughts on pricing. Through it all, three pricing-related themes have been shockingly consistent across industries, tech vs. non-tech companies, and late-stage private and public companies:

Enterprise buyers don’t like usage-based pricing.

This is a really tough one for founders to come to terms with. Usage-based pricing is the cleanest map to a startup’s variable costs. Usage also, in a perfect world, feels directly tied to value (i.e., the more you use a product, the more value you get out of it). Enterprise buyers have two big qualms with usage-based pricing: the lack of bill predictability, and the non-linear relationship between usage and value. CFOs tend to be planners (so quarterly bills that swing by seven figures don’t usually fly), and you can burn a lot of tokens generating bad code that never makes it to production. The resistance is understandable.

The workaround: if your product necessitates charging for token consumption:

• Pair it with a fixed platform fee so the entire bill isn’t driven by variable spending.
• Charge for consumption in chunkier ‘units of work’ (e.g., increments of $X-XXXK) so the buyer isn’t hyperaware of every agent run. Thoughtfully estimate how many units of work they’ll go through during the contract term and bake in up front. True up periodically.
• When possible, add a high-level ‘value guarantee’ – here’s a great example from Cognition

Simple pricing is best.

Related to the above, the dream state for most enterprise buyers is one fixed annual contract fee. Platform fee + a la carte feature add-ons + usage + seats + services/labor + in-year volume adjustments is too much. Too many dynamic pricing dimensions creates confusion and fatigue for buyers. When possible, try to limit your pricing model to 2-3 major components, e.g., a fixed platform fee and a variable component tied to value.

The workaround: ‘simple’ pricing is rarely derived easily at the enterprise level. Front-load the complexity through a thoughtful POC process that allows you to scope full-term contracts in a more accurate, straightforward way (while aligning stakeholders).

Buying decisions rarely come down to cost..

BCV recently fielded a proprietary AI in the Enterprise survey to ~50 enterprise CTOs and CIOs. The survey covered a range of topics, including AI maturity & governance models, AI budgets & ROI, specific AI tooling, and agentic AI & future investment areas. One theme came through clearly: buying decisions depend on a lot more than the dollar cost.

When ranking the importance of key purchasing criteria, ‘security, privacy, and data handling’ and ‘quality and reliability of outputs’ ranked most important. ‘Total cost’ was ranked 7th.

The success of AI investments is still predominantly assessed via productivity gains, not direct monetary ROI (through revenue growth or cost reduction) on AI spend.