Emerging patterns in credit based pricing design
Dependent choices
A three piece series to help you make key design decisions on credit based pricing.
Emerging patterns in credit based pricing design (this post)
A decision tree and checklist for credit based pricing design
Credit based pricing design tradeoffs (in preparation)
TL;DR
Credit-based pricing is moving from fringe to mainstream in B2B AI/SaaS and is becoming the default grammar for agentic AI. The added complexity of these models is not always justified—design must be strategy-led, not fashion-led.
A credit system is a mechanism that converts value into a proprietary unit and then governs how those credits are bought, burned, rolled, shared, refunded, and surfaced to customers and Go-to-Market (GTM) teams.
Design of credit based pricing is based on a series of cascading and interdependent choices. Choice of the unit of value, the granularity of the credit, conditions all of the other choices.
Foundation choices (unit, trigger (what causes a credit to be consumed), period, price) are the economic grammar; once set, every lifecycle, governance, and GTM decision is downstream and cannot repair a weak unit definition or trigger.
The Design Structure Matrix (DSM) shows the dependencies in the system: Foundation Choices × Lifecycle Core Choices are the critical path, resist the urge to skip ahead to packaging or GTM.
Lifecycle Core—overage, rollover, pooling, on‑demand, and incentives—are how buyers experience fairness, flexibility, and expansion, not “edge” policies.
Lifecycle Satellites handle edge cases—refunds, draw order, transfer, trading—and should be designed only after the core lifecycle is clear.
Governance, packaging, change, and GTM control execution: if dashboards, incentives, and narratives don’t match the credit model, sales will quietly reintroduce seats and undermine the design.
The most effecitve implementation sequence is:
() 1build a segment‑specific value model as the foundation;
(2) co‑design Lifecycle Core;
(3) add Satellites;
(4) implement Governance;
(5) only then go on to Packaging, Change, and GTM.Action: start by building an internal “credit playbook” that your value, pricing, and product teams share—define the value model, the credit weight register for key actions, the core policies on overages, rollover, pooling, etc. Set out the KPIs. Use this playbook as the single source of truth for any future experiments in packaging or GTM. The playbook can also be used as a context document when vibe coding the credit calculator, credit wallet and credit predictor.
There is still a lot of debate about credit based pricing and whether it is the right way to go. I am currently working with a European software vendor with a complex set of offers. Credit based pricing makes sense for them at an abstract level, but we have decided against it and are using a more conventional platform+extensions approach. We have not convinced ourselves that the added complexity of credit based pricing is justified for buyers, sales or for the product marketing team.
That said, credit based pricing is growing rapidly. In The state of B2B monetization in 2026 from Kyle Poyar, Kyle found that credit-based pricing is moving from fringe to mainstream in B2B AI/SaaS, and that it will be the next major wave of monetization. Credits are the dominant approach for agentic AI and AI Native companies. These companies are likely to dominate the software market over the coming years and credit based pricing will become the dominant pricing model.
We have enough experience now to look for design patterns and to continue to develop the work of developing design processes for credit based pricing. This post continues the work highlighted in Emerging Frameworks for the Design of Credit-Based Pricing.
It begins by going deeper into the design process and then uses a DSM (Design Structure Matrix) to identify dependencies in the design process and how one choice can impact other choices.
This whole post can be provided to Claude as a context document when using vibe coding to help design pricing or to build credit calculators and credit wallets.
The Design Process
A credit‑based pricing system for AI agents is a designed mechanism that converts economic value delivered by into a proprietary unit, “credits”, and then governs how those credits are purchased, consumed, expired, shared, and surfaced to customers and GTM teams. What follows is a blueprint that walks step‑by‑step through the choices you must make, in the order that keeps dependencies clean.
Phase 1 – Value and model foundations
1. Segment and use‑case definition
Choices
Which customer segments are you designing for (defined using job‑to‑be‑done and not just industry)?
Which core use cases does each segment actually run with agents (not features, but workflows/outcomes)?
What is the unit of business value for each use case (tickets resolved, leads qualified, documents reviewed, hours saved, risk events avoided, revenue booked, etc.)?
These choices determine the economic lens through which every later decision (unit, trigger, period, price) must be evaluated.
2. Action‑level value modelling (EVE)
Choices
For each high‑volume action or outcome, what is the alternative (in value modelling terms, the ‘next best competitive alternative’): manual work, incumbent SaaS, outsourcing, “do nothing”?
What is the positive differentiation value versus that alternative (value driver types):
Increased revenue?
Cost savings?
Reduced operating capital requirement?
Reduced or deferred capital investment?
Reduced risk?
Increased optionality, adaptation?
What are the negative differentiation components:
Integration effort?
Reliability / failure rate and rework?
Behaviour change and training?
Lock‑in or switching risk?
Design options
Which value driver types do you focus on?
Do you model value per action or per workflow (this can be a process or a value path) then normalise back to the action level?
Outcome: a value per action distribution by segment and use case. This is the theoretical upper bound on what a single “unit” can fairly command. It is the core input into pricing credits.
3. Unit design – defining a credit
Core question: “One credit represents what, exactly?”
Choices
Unit type
Input‑based: per 1,000 tokens, per API call, per compute unit.
Easy to meter, but decoupled from customer value; best only for deeply technical buyer segments.
Activity‑based: per discrete step (classification, extraction, route, call).
Good when steps are legible and value is somewhat uniform per step.
Capacity-based (access to compute, access to bandwidth, priority in queue)
Important when access to resources is limited
Output‑based: per completed output (draft, summary, report, ticket resolution).
Often the best compromise in agentic AI: legible to buyers and closely tied to value.
Outcome‑based: per verified business outcome (qualified meeting, closed‑won deal, SLA breach prevented).
Ultimate alignment, but feasible only when attribution, measurement and prediction are robust.
Granularity (Lowest Common Denominator)
Very granular unit (small sub‑steps):
Pros: smooth usage curves, fine control over economics.
Cons: low legibility, high cognitive load, complex communication.
Coarser unit (full workflows/outcomes):
Pros: strongly value‑legible, easy sales stories, fewer edge‑cases.
Cons: big jumps in charge, can feel “lumpy” or unfair for partial or failed attempts.
Value anchoring
Value‑anchored design: credits are sized so that one unit’s value (from the EVE or value model) is several times the intended price per credit, allowing room for cost and margin.
Cost‑anchored design (anti‑pattern): credits sized around underlying LLM or infrastructure costs; value is whatever falls out. This usually underprices high‑value actions and forces complex packaging later.
Implications
Once you commit to a unit, you implicitly constrain:
Which triggers make sense (C2).
How big overage and rollover events feel (a single credit vs many small ones).
How clear your ROI story will be in sales conversations.
4. Consumption architecture – when credits burn
Core question: “At what point is a credit actually consumed?”
Choices
Trigger
Event‑triggered: consume credits when an agent run is initiated.
Simple technically, but you charge even on failures; worst for trust.
Output‑triggered: consume credits when an output is successfully produced.
Strongly aligned with EVE; recommended default.
Outcome‑triggered: consume when a business outcome is verified.
Best alignment, but requires strong instrumentation and measurement.
Failure policy
No charge on failure: failed or aborted runs do not consume credits.
Partial charge on failure: e.g., 10–20% of normal credit cost to cover infra, full charge on success.
Full charge regardless of success (anti‑pattern): nearly always experienced as unfair.
Retries and partial success
Do retries consume fresh credits, or is there a “free retry” window?
How are partial completions handled (pro‑rated credits vs only charge above a threshold of completion)?
Implications
These choices translate your EVE model into an operational definition of “value delivered” at the per‑action level. They also heavily shape later overage and refund behaviour.
5. Subscription architecture – time and commitment
Core questions
“Over what period are credits allocated?”
“What level of pre‑commitment do we want?”
Choices
Period
Daily for incentives, heavily used agents, only rarely used agents.
Monthly credits and billing.
Quarterly accrual, monthly reporting.
Annual credit pools (often for enterprise) with monthly visibility.
Multi Year - long term commitments, still rare for agents (June 2026)
Commitment model
Pure Pay as you Go: no recurring commitment, buy credits as needed. Also referred to as Ad-Hoc and On-Demand credits.
Subscription with included credits: fixed fee per period includes a credit allowance.
Committed spend pool: commit to spend X per quarter/year on credits, with discount vs Pay as you Go.
Dual‑track: platform fee (access, shared value, commitment) + credit pool (variable usage).
Contract structure
Term length, auto‑renew rules, and how unused credits at term end are handled.
Implications
This is where you decide how value and risk are shared over time: buyers take utilisation risk in exchange for better economics; you take utilisation risk in exchange for more predictable ARR.
6. Pricing architecture – “Two Dials”
Core questions
“What is the price per credit?”
“How many credits does each action cost?”
Choices
Price per credit
Derived from:
EVE band for key actions (value ceiling).
Cost floor across token, infra, human‑in‑the‑loop.
Competitive and alternative anchors.
Options:
Uniform price per credit.
Segment‑differentiated price per credit.
Tier‑effective price per credit (same nominal price, but higher tiers include more credits).
Credit weights per action
Value‑weighted: more credits for more valuable outcomes, fewer for low‑value actions (preferred).
Cost‑weighted: more credits for compute‑heavy actions (only acceptable if cost and value correlate).
Hybrid: cost floor plus scaling by value.
Scaling structure
Volume‑based: price per credit decreases with volume (dangerous if cost is mostly variable).
Commitment‑based: lower effective rate for higher commitments/tier.
Implications
C1–C4 together convert the value model into a priced, metered, time‑bound unit of account. Only once these are coherent should you move to lifecycle rules.
Phase 2 – Lifecycle design (core and satellites)
7. Overage – when credits run out
Choices
Overage behaviour
Hard ceiling: usage stops at zero credits.
Soft ceiling: usage continues; overage billed per credit.
Degraded use: only basic actions are available once credits run out.
Auto top‑up: automatic purchase of top‑up packs when balance crosses a threshold.
Borrow from next period: temporarily dip into next period’s allowance.
Overage price
Equal to tier effective rate (trust‑maximising).
Premium over tier rate (common but can lead to buyer push back).
Discounted (rare; typically only for very strategic accounts).
Controls
Admin‑configurable overage caps or hard stops.
Alert thresholds for approaching overage.
8. Rollover – when credits go unused
Choices
Rollover policy
No rollover: all unused credits expire at period end.
Capped rollover: unused credits roll to next period up to a cap (e.g., 1× period allowance).
One‑time rollover: credits roll exactly once, then expire.
Indefinite no‑expiry (anti‑pattern from an accounting perspective).
Credit‑type differentiation
Subscription credits vs on‑demand vs incentive credits can have different rollover rules and windows.
9. Pooling – sharing credits
Choices
Scope
Account‑wide pool: all users draw from the same balance.
Team/department pools with separate budgets.
Hybrid: personal allocations plus shared pool.
Allocation rules
Percentage of each user’s allotment that is pooled vs reserved.
Whether admins can reallocate unused personal credits into pools.
Overage and rollover interactions
Whether pooling is considered before or after per‑user overage and expiry.
Pool‑level vs user‑level overage caps.
10. Pay as you Go (on‑demand credits or ad‑hoc purchase)
Choices
Eligibility
Open to non‑customers as well, or only to active subscribers?
Only admins, or any user with a payment method?
Price and size
Priced at parity, premium, or discount vs subscription rate.
Pack size (small emergency top‑ups vs larger blocks).
Lifecycle
Shorter expiry than subscription credits?
Do they participate in pooling?
Refund eligibility?
11. Engagement incentives – “free” credits
Choices
Trigger behaviours
Onboarding milestones (first agent run, first integration).
Feature exploration (trying a new agent).
Referrals and invitations.
Loyalty (renewal, usage milestones).
Economic controls
Value per incentive event (how many credits per behaviour).
Caps per period and per user.
Separate expiry (e.g., 30 days, non‑rollover).
Whether incentives are consumed first or last relative to purchased credits.
12. Refunds – unwind policies
Choices
Are unused credits refundable at all?
Never, only within X days, only above a material threshold, or only via account‑level exceptions.
At what price are they refunded?
Face value, discounted value, or only as credit (non‑cash).
Are refunds allowed for failed runs or SLA breaches (service credits vs true refunds)?
13. Draw order – which credits burn first
Choices
FIFO (first‑in, first‑out).
FEFO (first‑expiring‑first‑out) – usually the right default when rollover exists.
LIFO (last‑in, first‑out) – tends to strand older credits, considered an anti-pattern.
Per‑type order:
Incentive vs purchased vs on‑demand.
Rollover vs fresh period credits.
Draw order should make expiry behaviour transparent and optimally buyer‑friendly without creating accounting contradictions.
14. Transfer and trading
Transfer (non‑monetary)
Allowed between organisations, only within an organization, between pools, or not at all?
Limits on amount or frequency?
Admin‑only or self‑service?
Trading (monetary)
Not yet common in B2B SaaS.
If allowed in any form, must be tightly governed (price floors, vendor mediation) to avoid undermining tier pricing and channel integrity.
Is this the future of a credit driven agent economy?
Phase 3 – Governance and operationalisation
15. Entitlement and governance
Choices
Visibility
What dashboards do end‑users see (personal usage, balance, forecast)?
What dashboards do admins see (by user, team, agent, use case)?
Controls
Budget caps and per‑user limits.
Alert thresholds for low balance, looming expiry, or anomalies.
Self‑service tools: consumption simulators, forecast tools.
Audit
Granularity of logs (per action, per outcome).
Retention and export policies for enterprise.
Governance is the concrete manifestation of all lifecycle decisions; if you don’t surface them, the system feels arbitrary.
Phase 4 – Packaging, change, and GTM (Go to Market)
16. Packaging design
Choices
Packaging pattern (the standard B2B SaaS packaging patterns can be applied to credit based pricing models)
One big agent
Independent agents
Platform + agents
Orchestrated workflows (all the agents needed to complete a workflow, a user story, a job to be done)
Tiered (some version of Good Better Best)
Menu (choose one from each type)
Add‑ons
Top‑up packs, extra governance, premium support, advanced models, capacity guarantees.
Seed/free tiers
Enough credits to complete 3+ full use cases for the intended segment, or just a “toy” amount.
One time or monthly.
Packaging should follow from segmentation + value model, not the other way round.
17. Change management
Choices
Notice periods for price or credit weight changes.
Grandfathering rules (who keeps old terms and for how long).
Versioning of the credit weight register and policy documents.
How you communicate changes (channels, cadence, narrative).
Change management is where you decide how much “policy volatility” your customers will tolerate.
18. GTM (Go to Market) alignment
Choices
Sales compensation
Comp on committed credit pool ARR, not seats.
Spiffs for credit‑led expansions vs seat expansions.
Customer Success playbooks
Plays triggered by burn patterns (high burn → upsell; low burn → adoption work).
Health scoring that incorporates credit utilisation and realised value.
Finance and reporting
Credit‑native KPIs: committed pool ARR, Value‑to‑Burn ratio, credit‑based NRR.
How you explain credit economics to the board and investors.
Putting this together, a well‑designed credit‑based pricing system for agentic AI is not a single tariff, but a coherent design of interlocking choices. The safest order of operations is:
Build the value model and lock C1–C4.
Co‑design the Lifecycle Core (C5–C8, C13) as a coupled cluster.
Add Lifecycle Satellites (C9–C12) where needed.
Implement Governance (C14) as the convergence layer.
Only then crystallise Packaging, Change, and GTM (C15–C17).
Design Dependencies
The most effective way to analyse complex, interlocking systems with dependencies between designs/choices is the Design Structure Matrix or DSM. This approach was pioneered by Don Steward at General Electric to to solve large, complex systems of mathematical equations and manage information-feedback loops. The approach has been extended to the design of modular systems and to grouping functions into components. Steven Forth (the author) and Edward Wong pioneered the use of DSMs with value and pricing models while working together at Ibbaka (which has split into valueIQ.ai and GTM Pricing).
The below chart was generated from the above choices. The strength and direction of dependencies between choices was analysed and then the choices were ordered to reveal the clusters of dependencies. Four blocks of strongly interacting choices were identified.
Foundation
Lifecycle Core
Lifecycle Satellites (Edge Cases and Exceptions)
Growth and Governance
There are also many interactions between the first two blocks: Foundation and Lifecycle Core. Strategy should dictate design. The possible designs constrain strategy.
The upper-left block (Foundation × Lifecycle Core) is the densest and most colourful — the two blue Foundation rows (C1 Unit Design, C3 Subscription Arch.) cast 3s and 2s across almost the entire green Lifecycle Core cluster. This is the critical-path “cascade.”
The staircase pattern — all non-zero cells sit at or above the diagonal — confirms the system is a true DAG with no circular dependencies (with the one near-circular exception in the C5/C6/C7 sub-cluster, visible as the green 2 at C6→C7 and C7→C5).
The purple Growth/Gov. column (C14–C17) receives hits from every cluster — blue, green, and teal rows all have entries in the purple columns — making the convergence-sink nature of Governance and the terminal-sink nature of GTM Alignment immediately visible.
The lower-left triangle is entirely blank — no downstream choice constrains an upstream one, confirming the clean top-down ordering of the design sequence.
Read the matrix as a plan
Treat the upper‑left block (Foundation × Lifecycle Core) as the critical path. Those blue rows (C1, C2, C3, C4) drive almost every green lifecycle choice. Act on them first.
The “staircase” of non‑zero cells tells you this is a DAG. Move left‑to‑right, top‑to‑bottom. Don’t skip ahead.
The blank lower‑left triangle confirms there are no downstream constraints on upstream choices. Once you commit upstream, everything else has to adapt.
The purple Growth/Governance columns (C14–C17) are convergence and terminal sinks. Nearly every decision flows into Governance, Packaging, Change, and GTM. Design them last, but design them deliberately.
Foundation (C1–C4): set the grammar
Do this work in the first one or two workshops, before lifecycle or packaging.
Members
C1 Unit Design
C2 Consumption Architecture
C3 Subscription Architecture
C4 Pricing Architecture
Purpose
Define the economic grammar: what one credit means, when it is consumed, over what period, and at what price. This is the concrete version of value > price > cost: the value model feeds C1–C4; C1–C4 then feed everything else.
Internal choices
C1 ↔ C2 – Define unit and trigger together.
Answer “One credit represents what?” at the level of an action or outcome, grounded in an explicit EVE model by segment and use case.
Decide when that unit is spent: event start, successful output, or verified outcome. Prefer output/outcome triggers where you can measure success; they track delivered value and justify “no charge on failure” or partial‑charge rules.
Avoid units defined from cost or tokens; they are illegible to buyers and push you into arbitrary lifecycle rules later.
C1 ↔ C4 – Tie weights to value and margin.
Use the value model to set credits per action (weights) and derive value and cost per credit by segment.
Choose a price‑per‑credit curve that keeps value > price > cost across the relevant volume range.
When you need to move economics, decide explicitly whether you are turning the “credits per action” dial or the “price per credit” dial, and do it with reference to EVE, not just costs.
C3 ↔ C4 – Align time, risk, and price.
Use value‑over‑time patterns and usage distributions by segment to pick commitment period and structure: monthly vs annual, PAYG vs committed pools, platform‑plus‑credits, etc.
Let those choices set the reference points for discounts and effective rates, and define where overage and rollover are measured.
C2 ↔ C4 – Respect failure in both value and price.
Decide whether failed or partial actions consume credits, and at what rate.
Price with an explicit assumption about failure/partial rates; if you are generous on failure, you must reclaim margin either in weights or price‑per‑credit.
Interactions outward
Into Lifecycle Core:
Use C1 and C3 to define what “overuse” and “under‑use” mean (overage, rollover, pooling, on‑demand).
Use C2 to set where disputes will cluster: event‑triggered models increase overage and refund friction; output‑triggered models shift risk back onto you.
Into Lifecycle Satellites and Governance:
Let C4’s structure inform trading risk, refunds, and terms.
Require Governance to log and visualise units, triggers, periods, and credit types with audit‑quality accuracy.
Make Packaging the customer‑facing expression of these four primitives: credits per plan, commitment type, and headline price metrics.
Action: build and document a segment‑specific value model first; then lock C1–C4 in that order. Only then touch lifecycle or packaging.
Lifecycle Core (C5–C8, C13): design behaviour in period
This is the behavioural heart of the system. It is where you create or destroy trust, expansion, and predictability.
Members
C5 Overage
C6 Rollover
C7 Pooling
C8 On‑Demand Credits
C13 Engagement Incentives
Purpose
Decide what happens to credits during and around the billing period: too much use, too little use, shared use, ad‑hoc top‑ups, and non‑purchased credits.
Internal choices
C5 Overage ↔ C8 On‑Demand (strong)
Choose your post‑allowance behaviour: hard cap, soft cap billed as overage, or auto top‑up.
Design on‑demand credits so that “overage rate” is just one expression of the on‑demand price; auto top‑up is a UX over the same mechanism.
Do not design overage and on‑demand independently; they are the same economic lever.
C6 Rollover ↔ C7 Pooling (tight)
Decide which unspent credits roll, for how long, and at what scale (per‑user or pooled).
Use pooling to drive adoption and flexibility, but control rollover on pooled balances to avoid large deferred liabilities and reduced upgrade pressure.
C6 Rollover ↔ C8 On‑Demand
Set distinct rollover rules for subscription, on‑demand, and incentive credits.
Shorter expiry on on‑demand credits preserves commitment incentives and simplifies accounting.
C6 Rollover ↔ C13 Incentives
Treat engagement credits as behavioural nudges, not quasi‑cash.
Give them short, non‑renewing lifetimes and clear visibility; almost never let them roll indefinitely.
C7 Pooling ↔ C5 Overage
Decide whether individuals can exhaust the pool, whether they have sub‑budgets, and where hard vs soft caps apply.
Offer enterprise buyers hard budgets at the pool level plus softer, user‑level alerts for internal governance.
C7 Pooling ↔ C8 On‑Demand
Specify who can buy on‑demand top‑ups for a pool: admins only, specific roles, or all users within limits.
C7 Pooling ↔ C13 Incentives
Decide whether incentives are personal or pooled. Personal incentives drive exploration; pooled incentives drive team‑level experimentation.
Interactions outward
From Foundation:
Use C1/C2/C3 to anchor where overage and rollover boundaries sit and how smooth or spiky risk becomes. Fine‑grained, outcome‑based units usually deliver smoother curves and more defensible policies.
Into Satellites:
Use core lifecycle choices to define credit “species” (subscription, on‑demand, incentives) with distinct expiry and rollover. Satellites then define how you refund, draw, transfer, and (if at all) trade them.
Into Governance and Packaging:
Require Governance to surface pool‑ and user‑level balances, rollovers, and alerts clearly; test these flows with real customers.
Use Lifecycle Core as the main set of levers for tiering: more generous rollover, pooling, and auto‑top‑up for higher tiers; tighter, more predictable limits for entry tiers.
Action: once C1–C4 are stable, design C5–C8/C13 as a single state machine, not as separate policies.
Lifecycle Satellites (C9–C12): handle edges and flows
These are instantiated after the core lifecycle is in place, but they matter disproportionately for trust, accounting, and regulatory exposure.
Members
C9 Refunds
C10 Draw Order
C11 Transfer
C12 Trading
Purpose
Define how credits unwind, in what order they are consumed, how they move between accounts, and whether any secondary market exists.
Internal choices
C9 Refunds driven by C2, C4, C8
Make refunds an explicit response to disputes about consumption and ownership.
Use clear logs of triggers, prices, and on‑demand types to keep refund volumes manageable.
C10 Draw Order ↔ C6/C7/C8/C13
Choose a default rule; FEFO (first‑expiring‑first‑out) is usually the right baseline across credit types.
Let FEFO quietly do the work of ensuring subscription, on‑demand, and incentive credits are used before they die, without requiring the buyer to understand every rule.
C11 Transfer ↔ C12 Trading
Draw a bright line between non‑monetary transfers and monetary trades.
Common pattern: allow free transfers within an organisation or pool, disallow inter‑org transfers except via vendor‑managed refunds or buy‑backs, and disallow true trading entirely.
Interactions outward
From Lifecycle Core:
Let core rules on expiry, rollover, pooling, and incentives define the credit species. Satellites then define how those species behave when refunded, reordered, or reallocated.
Into Governance:
Require audit‑quality records: which actions consumed credits under which triggers, which bucket was drawn down for each transaction, and all transfers or trades relevant for compliance and tax.
Action: finalize C9–C12 only after the Lifecycle Core state machine is clear; then design them together with Governance.
Growth / Governance (C14–C17): turn system into business
This cluster is where the pricing system becomes a pricing business. Design it last, but design it as seriously as the Foundation.
Members
C14 Entitlement & Governance
C15 Packaging Design
C16 Change Management
C17 GTM Alignment
Purpose
Operationalise, commercialise, and evolve the design: turn policy into analytics and controls, design SKUs and tiers, manage change without breaking trust, and align GTM with the credit model.
Internal choices
C14 Governance ↔ C15 Packaging
Decide which governance capabilities live at which tiers: balances and basic alerts at the bottom; sub‑budgets, pools, anomaly detection, expiry forecasts, and simulation at the top.
Treat governance features as value drivers in their own right; they often close enterprise deals.
C14 Governance ↔ C17 GTM Alignment
Wire GTM playbooks to governance signals: low burn as churn risk, high burn as expansion opportunity, anomalous patterns as risk triggers.
Build comp plans, QBR cadences, and CS health scores around credit‑native metrics, not seat counts.
C15 Packaging ↔ C17 GTM Alignment
Encode the decision to compensate on credits, pools, or commitments in both packaging and GTM.
Remove any ambiguity that would tempt reps to sell on seats while you monetise on credits.
C16 Change Management ↔ C17 GTM Alignment
Define notice periods, grandfathering, and versioning of weights and prices.
Equip GTM to explain transitions clearly: what changes, when, for whom, and why in terms of value and risk‑sharing.
Interactions outward
Governance as convergence point
Bring all upstream decisions into a single, coherent governance and analytics layer: unit display, trigger logs, overage alerts, expiry, draw order, transfers, and credit type tagging.
Packaging and Change as late‑stage reflections
Let C15 and C16 reflect stable upstream decisions, not compensate for upstream incoherence. If you are iterating packaging rapidly, treat that as a signal that you have not finished Foundation and Lifecycle design.
GTM as true sink
Recognise that C17 has no outbound constraints but can negate the whole system if misaligned.
Train and enable GTM until they can confidently sell, defend, and adjust within the credit model rather than around it.
Action: only after Foundation and Lifecycle are coherent, design C14–C17 as an integrated GTM and governance layer, then freeze them long enough for the organisation to learn and trust the model.
Conclusion
A credit-based model is no longer an exotic experiment; it is becoming the default grammar for how agentic AI is bought, sold, and governed. The real work now is not deciding whether to use credits, but deciding how to design them so they support your strategy rather than constrain it.
What this DSM tells us
The DSM makes one point painfully clear: unit, trigger, period, and price (C1–C4) are not menu items, they are the grammar that every other decision has to speak. Once you commit upstream, nothing downstream can fix a weak unit definition, a confused consumption trigger, or a subscription architecture that moves risk to the wrong side of the table.
Lifecycle Core (C5–C8, C13) then acts as the behavioural engine of the system: overage, rollover, pooling, on‑demand, and incentives are not “add‑ons,” they are how buyers experience fairness, flexibility, and expansion paths in period. When you treat them as a single state machine rather than scattered policies, you get predictable economics and fewer policy exceptions.
Governance and GTM (C14–C17) sit at the bottom of the matrix for a reason: every upstream choice flows into entitlement, analytics, packaging, change management, and sales behaviour. Misaligned GTM can negate an otherwise elegant design faster than any modelling error, which is why governance dashboards, compensation plans, and customer‑facing narratives have to be designed as seriously as the credit wallet itself.
How to use this in practice
For an AI or SaaS leadership team, the DSM is a workshop agenda, not an academic artefact. You can walk cross‑functional teams through C1–C4 in one or two sessions, explicitly documenting “one credit represents what,” when it burns, over what period, and how the value model translates into price and weights.
From there, you design Lifecycle Core as a coupled cluster: define a single overage/on‑demand mechanism, decide where rollover really matters, and design pooling and incentives as intentional levers for adoption rather than last‑minute concessions. Then, and only then, you move to refunds, draw order, transfers, and any notion of secondary markets, treating them as edge‑handling and risk‑management rather than monetization experiments.
Finally, you convert the whole system into a business: governance dashboards and alerts wired into CS and RevOps playbooks, packaging that exposes credits, commitments, and governance features clearly, and GTM enablement that trains reps to sell on value metrics and credit pools instead of seats. This is where the model starts to show up in board packs and investor conversations as “committed credit pool ARR,” “Value‑to‑Burn ratio,” and credit‑based NRR, not just logo and seat counts.
A concrete next step
If you are serious about moving toward a credit‑first, agent‑aware architecture, do not start by tweaking tiers. Start by convening a small working group and using this blueprint and DSM as the backbone for three working sessions:
Foundation workshop – Build a segment‑specific value model and lock C1–C4 in writing, including a straw‑man credit weight table for your top 10 actions.
Lifecycle workshop – Design C5–C8/C13 as a single state machine, stress‑testing for under‑use, over‑use, and failure scenarios on your real data.
Growth and governance workshop – Define the governance layer, then crystallise packaging, change policies, and GTM compensation and messaging around the credit system.
Treat these as design sprints with explicit decisions, not open‑ended discussions. At the end you should have: a value‑anchored unit definition, a coherent lifecycle, a governance spec, and a draft price book that your teams can test with customers over the next two quarters.
Everything you'd ever want to know about credit-based pricing.