Deciding to use an AI credit model is only the starting point. Designing one that works is the real challenge. Our Simon
A flexible credit model turns you into something you may not have planned to become: the central bank of your own product economy. The first article in this series separated tokens, the currency in which model providers charge you, from credits, the currency in which you charge your customers.
The catch: the moment you decide to go for a credit-based model, the central banker's job begins in earnest. You now decide how many credits each customer holds, under which rules they circulate, which AI-powered actions they can be spent on – and, above all: what is a credit worth? Not as a fixed markup on your costs, but as a reflection of the value each action creates.
Define a credit's buying power carelessly, and the effects are immediate, if quiet. Let’s go through a practical example here to assess what this means for most companies:
Picture a legal research platform that charges one credit for each query and interaction with its software: a simple legal question and a full case-law search both cost one credit – and may well consume a similar amount of tokens – yet one saves the lawyer an hour and the other a full day. The issue is not just that someone might complain. Litigation lawyers running case-law research all day get a remarkable deal; advisory lawyers who briefly double-check before calling a client back see a high price per query. The real damage is quieter: you are leaving a lot of money on the table on exactly the actions that create the most value – and it shows up nowhere except in your usage data and, eventually, in your renewal calls.
This article covers how to get out of the intrinsic complexity of AI credit pricing. Learn how to build a credit model: the two decisions that come before any price setting for a credit, and the seven design questions that define your option space. The stakes are simple to state and hard to balance. Over-monetization kills adoption; over-complexity kills the deal.
Decision one: what should a credit buy?
Not every capability belongs in the credit model. Deciding the right scope from the start sorts your portfolio into what sits in the base offering and what consumes credits, and in our engagements three criteria do most of the work here:
• Perceived value: Be cautious about monetizing commoditized actions. Simple AI queries (in a chatbot), for example, increasingly feel like standard functionality to customers, even though they still carry a cost for the vendor. Charging for them too visibly can encourage customers to ration usage, which is the opposite of what you want.
• Volume predictability: Monetize what customers can roughly anticipate. Actions with wildly unpredictable volumes turn every invoice into a surprise.
• Customer control: Users need a minimum level of control over what consumes credits. Consumption they can neither see nor steer feels like a tax, not a purchase.
One more thing about the scope: it ages and changes in the current software market. What justified a premium credit price at launch becomes table stakes eighteen months later, as competitors ship comparable capabilities and customer expectations move. Treat the sorting as a decision you revisit, not a line you draw once.
And how does this play out in practice? At Simon-Kucher, we’ve recently supported an enterprise software vendor moving from a pure per-employee model to a hybrid one. The central exercise was precisely this sorting: which of its AI agents count as table stakes, included in the base fee, and which are monetized on top once usage becomes heavy. Added value and the expected breadth of users decided the split – not the technical cost.
Decision two: what is a credit worth?
Once the scope is set, each action needs a credit price, and here the most common design error usually appears: pricing credits off your own cost base. Your inference bill, the tokens you pay for the large language models behind your product and agents, is a guardrail. It tells you where prices must not fall. It tells you nothing about where they should sit, because customers do not buy your costs – they buy their own outcomes.
Value-based credit prices start from the relative value each action creates. Customer feedback gives you a first read. A structured ROI analysis gives a harder one: time and FTE savings, incremental revenue from higher conversion – and last but not least: financial risk avoided through better security and compliance.
Let’s go back to the legal platform from the opening, because it is drawn from a real Simon-Kucher project: working with a LegalTech vendor, we replaced per-query pricing with actions that make professional sense to lawyers and are easy for the vendor to track, from simple legal questions to full case-law research.
Credit consumption was then set to reflect the difference in value between queries, so the task that saves a day consumes more credits than the one that saves an hour. The customer now pays for hours saved, not tokens burned. We did not exactly translate our estimate of hours saved into the number of credits burned, though, as some of those hours would just not have been invested by the legal team.
A practical way to run this calibration: pick your most common action as the index, then weight every other action relative to it. Customers can sanity-check a relative scale far more easily than a list of absolute prices, and your own teams can defend it in negotiations without a spreadsheet.
One honest exception you should keep in mind: for extremely cost-intensive solutions, a deliberate pass-through model that separates inference costs from platform value can make sense. That is a strategic choice, not a default.
The option space: seven design questions for your credit-pricing model
With scope and value set, the work moves to structure. There is no single dominant design for credit-based pricing models. There is a broader option space, and every cell in it has commercial consequences.
So when designing the model in more detail, ask yourself the following questions:
Design questions I: the revenue architecture
First, take a look at the shape of the revenue itself: what you meter, and how the price curve behaves.
• Price metrics: credits only, or hybrid ‘seats plus credits’? A hybrid model balances predictability for customers with a secured revenue base for you, and suits copilot-style products especially well. Pure credits maximize value alignment.
• Price formula: tiered credit packs, linear, or with volume discounts? Tiers give buyers visibility and simplify procurement, but beware of customers feeling they pay for volume they never use.
Design questions II: the pricing mechanics
Second comes the machinery of payment: when money flows, and what happens at the edges of a commitment.
• Payment structure: pre-paid, post-paid, or both? Post-paid consumption gives you more leeway for pricing adjustments, but tends to fit transactional SaaS better than enterprise accounts. Enterprise buyers usually need a committed number their CFO can plan around.
• Overage policy: charge at a discount, at parity, or at a premium? The most underestimated lever in the model. Your overage price is how you steer customers toward higher upfront commitments.
• Term commitment: monthly, annual, or multi-year? Follow your market. Transactional B2B, enterprise B2B, and B2G run on different commitment logics, and forcing one onto another rarely survives negotiation. Longer commitments buy you predictability, but may also hamper your ability to evolve monetization levels.
Design questions III: the consumption rules
Third, take a closer look at the rules of your credit consumption: who shares the pool, and what happens to credits nobody spends.
• Credit pooling: user-based or company-based? A user-based pool monetizes more precisely – a shared credit pool across the company reassures buyers when usage varies strongly across user types. The right answer often differs between your SMB and enterprise tiers.
• Rollover policy: use it or lose it, partial, or full? ‘Use it or lose it’ incentivizes usage, but acceptance depends on the price formula and rollover rules working together, so test them as a pair.
Of course, each of these questions can be answered in isolation. The craft lies in the combination, because the dimensions interact across all three groups. Which combination holds is a function of your strategy and your customer structure, not of a benchmark table.
Crawl, walk, run: sequencing the rollout
However strong the initial design, a credit model should not aim for perfect monetization from day one. Moving from user-based to credit-based pricing requires new data, telemetry, systems, and customer behaviors that take time to build and understand. The most effective transitions therefore mature progressively across three phases.
Crawl. Start with a hybrid model that preserves the existing user-based structure while introducing credits gradually. Keep credit allowances generous and consumption rates simple to avoid constraining adoption too early. The priority at this stage is learning to understand usage patterns, validating telemetry, identifying the relative value of different actions, and building the data needed to refine credit allocation over time.
Walk. As usage patterns become clearer, refine how credits are allocated and consumed. Differentiate credit consumption according to the value of each action, adjust allowances, and introduce clearer overage and commitment rules. At the same time, strengthen the operational backbone through reliable telemetry, billing, usage visibility, and sales enablement.
Run. Once usage, value, and customer behavior are well understood, the credit model becomes a core monetization engine. Optimize credit allocation, commitments, overages, and pricing based on observed usage and willingness to pay. As the model matures, credits can take a larger role relative to the user-based component, while new capabilities flow directly into the established credit structure.
And plan for iteration across the whole life cycle of the model. Among fast-moving customers, we see credit structures revisited every six months. That is not a sign of failure – in 2026, it is simply how these models are designed and work.
Connecting all the pricing dots: creating a model that really works
Two decisions, seven questions, and one sequencing logic: put these together and you get a credit model that fuels expansion instead of quietly killing adoption.
Want to learn more? Reach out to our Simon-Kucher software pricing experts today to pressure-test your credit model design before your customers do.
Next in this series: Why execution matters – the winners of the credit model shift build the whole operating model, not just the pricing.
