Six drivers decide the credit burn, and the order form prices only the pool
The credit pool is one line on the order form. What draws it down is six independent variables, none of which appear on that line, and five of which are decided by engineering choices made after the contract is signed.
Prepared by Redress Compliance · August 16, 2026 · Salesforce advisory.
Executive summary
Six drivers decide the burn down, input tokens, output tokens, model class, retrieval calls, action calls, and concurrency. The order form prices the pool and describes none of them.
Overage runs at a premium against the committed pool, so the cost of forecasting badly is asymmetric: unused credits are wasted and excess consumption is charged above the committed rate.
The price per credit varies by tier, with strategic accounts moving below the public catalogue and smaller estates paying closer to list. Without a benchmark the rate cannot be evaluated.
Score every workflow under both pricing shapes. Run each use case against the per credit and the per use case price, and let the lower number set the negotiating posture rather than the vendor's preferred model.
The six drivers, and who controls each
Each generative call burns credits, and the amount burned is a function of six variables. The commercial team negotiates the pool. Five of the six drivers are set by people who were not in that negotiation.
| Driver | What moves it | Who decides it |
|---|---|---|
| Input tokens | Prompt length, context injected, record size | Solution design |
| Output tokens | Response length and verbosity | Solution design |
| Model class | Which model the workflow calls | Platform configuration |
| Retrieval calls | Grounding against Data Cloud and knowledge sources | Architecture |
| Action calls | How many system actions an agent takes per task | Agent design |
| Concurrency | Parallel execution at peak | Adoption and traffic |
This is the governance gap in one table. The order form carries a pooled credit line and a rate. It does not carry prompt length, model class, grounding depth, or actions per task, and those are the variables that decide how fast the pool empties. A commitment negotiated by procurement is therefore consumed by decisions made in design reviews nobody invited procurement to, which is why the line looks small at signing and much larger after twelve months of production traffic.
The pool is negotiated once and consumed continuously
Credit models invert the usual relationship between a contract and its cost. On a seat based line, the commercial decision and the cost are the same decision: you agree a number of seats and that is what you pay. On a credit line, the commercial team agrees a pool and a rate, and then the cost is determined afterwards by six independent variables, five of which sit with engineering. The contract does not describe them, cannot constrain them, and in most estates nobody has connected the two.
The practical consequence is that a credit pool is a budget nobody owns. A solution architect who injects a larger context window to improve answer quality is making a cost decision. So is a designer who lets an agent take six actions rather than three to complete a task, or a platform lead who routes a workflow to a heavier model class because the output reads better. Each of those is a reasonable engineering judgement made for a good reason, and each moves the burn rate on a line the engineer never sees. Twelve months later the pool is short and the conversation is about an overage invoice rather than about design.
The asymmetry in the pricing makes that outcome expensive in both directions. Unused credits are generally wasted, so over committing loses money outright. Overage is charged at a premium against the committed rate, so under committing loses money too, and at a worse rate than the one you negotiated. A forecast that is wrong in either direction costs, which means the accuracy of the estimate matters more here than the size of the discount attached to it, and estimating accurately requires modelling the six drivers rather than projecting a headcount.
There is one clean structural lever available before signature. Salesforce prices some capability per credit and some per use case, and the two produce materially different numbers for the same workflow depending on its shape. Scoring every workflow under both, and letting the lower figure set the posture, converts a vendor led pricing choice into a buyer led one. Do it before the pool is sized, because the model you choose changes the pool you need. The pooled commitment mechanics sit in the AELA brief, the per conversation economics in the Agentforce benchmark, and the wider library in the Salesforce practice.
- Your quote benchmarked against 500,000+ real closed deals, adjusted for size, region, and industry
- Consumption modelled per workflow, with overage exposure priced separately from the pool
- Every risky clause flagged with the exact quote, the page, and the replacement language
The burn down math, and the posture it sets
- Run the burn down before the renewal opens, not after the overage invoice lands, because after it lands the only available conversation is about paying it.
- Score every workflow under both the per credit and the per use case price, and let the lower number set the negotiating posture rather than accepting the model the account team leads with.
- Model the six drivers per workflow, since a single high volume, heavily grounded, multi action agent can outweigh dozens of light interactive calls.
- Benchmark the credit rate, because it varies by tier with strategic accounts moving below the public catalogue and smaller estates paying closer to list.
- Negotiate the overage rate separately from the pool rate, given that overage carries a premium and is the price you pay precisely when the forecast was wrong.
- Put design changes that move burn under change control, connecting model class, grounding depth, and actions per task back to the line that funds them.
How the model behaves in production
The pattern is consistent across estates running Einstein and Agentforce at scale:
Input tokens, output tokens, model class, retrieval calls, action calls, and concurrency, none of which appear on the order form line.
A pooled credit balance and a rate, agreed by a commercial team with no visibility of the five design decisions that consume it.
The line item looks small at signing and much larger after twelve months of production traffic. That is not a pricing surprise, it is a measurement gap: the pool was sized against an assumption about volume rather than a model of consumption.
Overage runs on a higher rate than the committed pool, which makes the cost of a bad forecast asymmetric. Unused credits are wasted and excess consumption is charged at a premium, so the estimate matters more than the discount negotiated against it.
Watch the briefing · 4:51Estimating Agentforce Before You SignConversations, Flex Credits, and per user editions priced side by side, and the actions per conversation that decide the model.
Your first five moves
- List every live and planned workflow and score each against the six drivers rather than against expected user counts.
- Price each workflow under both the per credit and the per use case model, and take the lower of the two as your posture before the pool is sized.
- Benchmark the credit rate independently, since it varies by tier and is not published, so a presented discount cannot otherwise be evaluated.
- Negotiate the overage rate as its own term, because it carries a premium and applies exactly when the forecast proves wrong.
- Put burn moving design decisions under change control, connecting model class, grounding depth, and actions per task to the budget line. The Salesforce practice runs the burn down with you.
Frequently asked questions
How does the Salesforce AI credit model work?
Each Einstein or Agentforce call consumes credits drawn from a pool that sits as a line on the order form. The pool and the rate are negotiated commercially, while the rate of consumption is determined afterwards by how the workflows are built.
What actually drives the credit burn?
Six things: input tokens, output tokens, model class, retrieval calls, action calls, and concurrency. None of them appear on the order form, and five of the six are set by design and architecture decisions rather than by the commercial agreement.
Why does the line look small at signing?
Because it is sized against an assumption about volume rather than a model of consumption. Twelve months of production traffic exercises all six drivers, and the pool empties faster than a headcount based estimate predicted.
How is overage charged?
At a premium against the committed pool rate. That makes the cost of a bad forecast asymmetric in both directions: unused credits are generally wasted, and excess consumption is billed above the rate you negotiated.
Does the credit rate vary?
Yes, by tier. Strategic accounts move below the public catalogue and smaller estates pay closer to list. Because it is not published, a buyer without an independent benchmark cannot tell a real discount from a presented one.
What is the per use case alternative?
Salesforce prices some capability per credit and some per use case, and the two produce materially different numbers for the same workflow depending on its shape. Scoring every workflow under both and taking the lower figure turns a vendor led pricing choice into a buyer led one.
When should the burn down math be run?
Before the renewal opens. After an overage invoice lands, the only conversation available is about paying it. Before, the model choice, the pool size, and the overage rate are all still open.
Why is a credit pool a budget nobody owns?
Because the people who consume it are not the people who agreed it. An architect widening a context window, a designer adding agent actions, or a platform lead routing to a heavier model are all making cost decisions on a line they never see.
Should design changes be governed?
Yes. Model class, grounding depth, and actions per task move the burn rate materially, so connecting those decisions back to the funding line through change control is what stops a pool emptying without anyone noticing until the true up.
What matters more, the rate or the estimate?
The estimate. Because unused credits are wasted and overage carries a premium, a forecast that is wrong in either direction costs money. Accuracy on volume is worth more than a few points on a rate applied to the wrong volume.
The Order Form Is the Contract
Session 3 of the Salesforce Negotiation Series. The MSA, the order form and the Product Terms: which document binds you, how to read a Salesforce quote, and the five checks to run before any signature. Nothing said on a call survives unless it is typed on the order form.
