Agentforce Flex Credits vs Conversations: Cost Controls for SDRs
Compare Agentforce billing units, test real workflow consumption, and separate list-rate arithmetic from a usable SDR budget.
Agentforce Flex Credits price metered work; Conversations price a different unit of usage. Choosing between them starts with the work your sales agent will perform and the terms your Salesforce organization can buy. A lower headline number is not enough to show which model controls the cost of an SDR workflow.
The arithmetic below uses public list rates checked on October 26, 2026. Your contracted rates and coverage can differ. Before changing a contract, confirm the applicable agent, rate card, and billable events with Salesforce. The interesting comparison is between the same supported workflow under different commercial terms.
What does each Agentforce pricing unit buy?
The current pricing page lists Flex Credits at $500 per 100,000 credits and Conversations at $2 per conversation. It lists a standard Agentforce action at 20 credits and Voice actions at 30. The same page says the two models cannot operate together in one organization. Confirm eligibility and your contracted rate before comparing totals.
For this illustration, $500 divided by 100,000 gives $0.005 per credit. A 20-credit standard action therefore costs $0.10 at list rate. Twenty such actions total $2. That is an arithmetic equality between selected units. It is not evidence that every conversation contains twenty actions or that the two purchases cover identical features.
The distinction matters because a sales development workflow contains several kinds of work. Researching an account, composing a message, responding to a lead, and updating a record are useful descriptions for an operator. They are not automatically the billable events Salesforce will put on an invoice. Map each part of your actual configuration to the commercial definition before assigning it a price.
The purchasing review needs a practical step: somebody has to reconcile the usage definition with the workflow before the pilot becomes a purchasing argument. A working demo proves that a path can run. It does not yet show what that path costs when leads ask extra questions, records need correction, or the team changes the instructions.
When is the twenty-action comparison useful?
The comparison is useful as a sensitivity check. Suppose, purely for illustration, a repeatable task uses five standard billable actions. At the list rate used above, those actions cost $0.50. A task using thirty such actions costs $3. Neither example describes a measured deployment. The point is to expose how strongly an action-based estimate depends on the path the agent follows.
For an SDR evaluation, I would sketch the straightforward path and then several ordinary exceptions. A lead may reply with a question instead of booking. A record may lack a required field. A seller may need to intervene. Give each path a clear business outcome and record the events the platform actually meters when that path runs.
Do not assign every path the average before you understand the spread. A small number of complicated cases can matter to a budget even if most leads follow a short path. Keep counts for the common route and the exceptions. Once you have observations, calculate the weighted total from those counts instead of pricing every lead as though it behaved identically.
Conversation pricing deserves the same discipline. Get the billable conversation definition in writing and check what starts, ends, or restarts the unit for your use case. A familiar word can hide a specific commercial definition. You cannot compare a cost per lead in one proposal with a cost per conversation in another unless the relationship between those denominators is known.
Our coverage of Agentforce SDR reply failures is relevant here. A workflow that stops responding may produce little useful evidence about the cost of a complete interaction. Diagnose that behavior before using its low consumption as proof that the planned production workflow will be inexpensive.
Work the budget from a distribution of paths
Assume a hypothetical month contains 1,000 completed work items: 700 short paths using six standard actions each, 200 paths using 18 actions, and 100 longer paths using 30. These are invented planning inputs, not measured Agentforce SDR consumption. The action count is 4,200 + 3,600 + 3,000 = 10,800. At the list-rate illustration above, that is 216,000 Flex Credits and $1,080 of standard-action consumption.
| Illustrative path | Items x actions | Action cost |
|---|---|---|
| Short | 700 x 6 = 4,200 | $420 |
| Question/exception | 200 x 18 = 3,600 | $360 |
| Long | 100 x 30 = 3,000 | $300 |
| Total | 10,800 actions | $1,080 |
Pricing every item as the six-action path would predict $600, missing $480 in this scenario. That error comes from the workload assumption, not from multiplication. When a pilot log shows an extra lookup or retry, assign its observed consumption to the relevant path. Do not guess that every visible tool call maps to exactly one standard action; use the actual metering definition.
If, separately, the same eligible work produced exactly 1,000 billable Conversations under an applicable contract, the $2 list-rate illustration would total $2,000. That conditional comparison is useful only after Salesforce confirms equivalent coverage and the conversation definition. Employee-facing work cannot simply be priced as customer-facing conversations because the arithmetic looks attractive.
The line chart shows an arithmetic crossing at 20 standard actions. It excludes Voice, other usage types, Data 360, licensing, discounts, taxes, and contractual commitments. It is a sensitivity chart, not a purchasing recommendation. Ask for an estimate using the actual mix rather than treating the crossing as a universal switch point.
In a budget sheet, keep columns for observed work items, metered actions, contracted unit rate, other consumption, and accepted outcomes. A failed attempt belongs in consumption even when it contributes zero accepted handoffs. For example, $1,080 divided by 900 accepted outcomes is $1.20 of this action component per accepted outcome; dividing by all 1,000 attempts would answer a different question.
How should a sales team run a cost pilot?
Start with one supported use case and a written completion condition. For example, your team might define completion as a qualified handoff accepted by a seller. That is a proposed business measure, not Salesforce's billing definition. Keep the operational and billing measures side by side so the purchase can be evaluated against both.
For every pilot item, record the path, outcome, and usage you can observe. Separate failed attempts from successful handoffs, and keep a note when the same lead needs another attempt. Otherwise a rerun can add consumption while disappearing from the success spreadsheet. That is a reporting choice your team controls even when the platform controls the meter.
Salesforce's ROI calculator documentation separates Flex Credits from Data 360 Credits and notes that employee usage can have different licensing treatment. Use that distinction when gathering a complete estimate. The calculator can help frame assumptions; its output is not a replacement for observing your configuration and checking the applicable contract.
In a research workflow, this is also where Leadex's plan approval provides a useful comparison. The user reviews the research plan before execution. That makes the proposed work visible, but it does not turn provider consumption into a fixed Salesforce price. For either product, scope approval and spending control are related decisions with different mechanisms.
I would put the pilot owner and the budget owner in the same review. The operator can explain why an exception path exists; finance can ask whether the commercial commitment fits the observed demand. Neither person should have to reverse-engineer the other's spreadsheet. A shared record also makes it easier to see when a prompt change has altered the work being priced.
Include human review effort in the purchase discussion. An apparently cheaper automated path might require a seller to repair records or rewrite replies afterward. That effort does not need to be converted into an impressive savings percentage. Record what people actually had to do, then decide whether the workflow is useful enough to expand.
What controls should be in place before expansion?
Set an owner for usage review, decide who can change the workflow, and write down what should happen when consumption departs from the pilot. Monitoring is only useful when someone can act on it. Ask Salesforce which alerts and controls apply to your purchase, then verify their behavior rather than assuming a notification is a hard spending cap.
Salesforce's pricing FAQ describes Digital Wallet monitoring and threshold alerts. It also says unused credits do not roll into later subscription terms. Those are reasons to examine commitment size and review consumption regularly. An upfront allocation that looks economical on paper can be poor value if the team never deploys enough useful work to consume it.
Before scaling, rerun the cost review after any material workflow change. Our Agentforce lead nurturing checklist covers another reason to keep configuration and operating behavior together. The next estimate should describe the workflow the team is actually running, including its exceptions, rather than the shorter path shown in the original demonstration.