Agentforce looks compelling in the demo. Here's what the sales conversation isn't telling you.
Most ANZ organisations first encounter Agentforce the way Salesforce intends: a polished demonstration, a credible use case, and an account executive who is clearly being measured on whether this conversation goes somewhere. The demo is usually good. The use case — typically something in customer service — is usually real. The question most customers leave the room asking is not "could this work?" but "what would it actually cost us, and are we ready for it?"
The honest answer to that second question is more complicated than the first conversation tends to suggest.
The cost question is harder than the pricing page implies
Salesforce publishes Agentforce pricing. The numbers look manageable in isolation — roughly $2 USD per conversation in the standard model, with enterprise volume pricing available. But the pricing page includes a quiet disclaimer that most customers don't notice until they've started modelling: the published rates exclude Data Cloud credits and other consumption services that Agentforce depends on in production.
This matters because Agentforce in a meaningful deployment is not a standalone product. It runs on Data Cloud. Data Cloud unifies your Salesforce data, grounds the agent's responses in accurate context, and handles the identity resolution that lets the agent know who it's actually talking to. Without Data Cloud doing that work, the agent operates with degraded context — and a customer service agent with degraded context is a liability, not an asset.
So the real cost comparison is not "Agentforce versus a human agent at $X per hour." It's Agentforce — at whichever pricing model applies to your use case — plus Data Cloud, plus whatever implementation and change management effort gets the system to a point where it's trustworthy. For mid-market ANZ organisations that don't already have Data Cloud in production, that's a meaningful additional investment to scope before any business case gets written.
Three pricing models, each with different trade-offs
Agentforce pricing has evolved since launch and now offers three distinct models. Understanding which one you're being sold — and why — is worth doing before any commercial conversation gets serious. Verify current rates with Salesforce directly, as this is an area of active change.
The original conversation model priced every agent interaction at a flat $2 USD regardless of complexity. A simple query about store hours cost the same as a multi-step troubleshooting workflow. That simplicity made it easy to forecast for well-defined, repeatable use cases, but it penalised straightforward interactions and rewarded complexity — which is the wrong incentive structure for most buyers.
Flex Credits are Salesforce's newer model, priced per action rather than per conversation. Actions are the individual functions the agent executes — retrieving information, updating a record, escalating a case. At $0.10 per action (verify current rates), simple interactions can be significantly cheaper than the conversation model: a basic query resolved in three to six actions costs $0.30–$0.60. Complex, multi-step interactions cost more. For organisations with a clear picture of what their agents will actually do, this model can be more economical and more precisely aligned to value delivered.
The trade-off is that per-action billing is harder to forecast than per-conversation billing. You need to model not just how many interactions the agent handles, but how many actions each interaction typically requires — and that number varies by use case, by agent design, and by how often interactions escalate or branch. Organisations that go into Flex Credits without that modelling done tend to find the billing less predictable than they expected.
The unmetered per-user licence is the newest addition and the most significant signal about where Salesforce sees adoption resistance. For Sales, Customer Service, and Industries users, Salesforce now offers uncapped Agentforce use at a fixed monthly per-user rate — the same commercial logic as a seat licence. The existence of this option is an acknowledgement by Salesforce that consumption anxiety is a genuine barrier for many buyers. If your team cannot reliably forecast agent usage volumes, a per-user model removes the budget unpredictability problem entirely.
The practical question for any ANZ buyer is which model fits the use case, not which model sounds most appealing in a presentation. High-volume, well-understood service workflows with consistent interaction patterns are candidates for Flex Credits once you've done the modelling. Broader deployments across variable user populations are likely better suited to the unmetered model. Highly repeatable, simple use cases may still be worth evaluating against the original conversation rate.
None of this makes Agentforce a bad commercial proposition. But it does make it one where the pricing model choice carries real financial consequences — and where a buyer who understands the options is in a meaningfully better position than one who accepts whatever the account executive recommends first.
The data problem is the one nobody talks about clearly enough
This is where most Agentforce conversations in ANZ fall short of what a prepared buyer needs to hear.
Agentforce's performance is directly determined by the quality of the data it works with. In customer service — the most common and most defensible starting point — the agent needs access to accurate case history, well-structured knowledge articles, clean contact and account records, and reliable product information. Where that data exists, in good shape, an Agentforce deployment has a real foundation. Where it doesn't, no amount of prompt engineering or configuration work fixes the underlying problem.
In mid-market ANZ Salesforce orgs, the data picture is rarely uniformly good. The specific problems vary in how much they matter:
Knowledge articles are the most common and most solvable problem. Most service organisations have knowledge content — but it was written for human agents who can interpret ambiguity, exercise judgement, and ask follow-up questions. An AI agent cannot do those things the same way. Articles need to be precise, structured, and unambiguous. Retrofitting an existing knowledge base to meet that standard is real work, but it's scoped and manageable.
Case history is more variable. A well-maintained Salesforce Service Cloud org with consistent case resolution patterns gives an agent useful training signal. An org where case notes are inconsistent, where resolution steps weren't captured, or where different agents handled similar cases in completely different ways gives the agent much less to work with. The problem isn't that the data is absent — it's that it doesn't encode what the agent needs to learn from it.
Contact and account data duplication is a material issue at scale. If the agent can't reliably identify who it's talking to — because contact records are duplicated, outdated, or inconsistently maintained — the personalisation that makes Agentforce more than a generic chatbot breaks down. This is a foundational Data Cloud responsibility, which is another reason the Data Cloud dependency is not incidental to the Agentforce proposition.
The governance problem is the deepest one. Data quality can be improved, but someone has to own the improvement programme. In many ANZ mid-market organisations, there is no named data governance owner with the mandate, the resources, and the executive support to systematically address data quality across the Salesforce footprint. Agentforce implementations that run into trouble often trace back to this gap: the data problems were identifiable in advance, but there was no organisational structure to fix them before the deployment went live.
What ready actually looks like
The ANZ organisations that are getting genuine value from Agentforce share a recognisable set of traits. They have structured knowledge, defined service workflows, clean enough data to make personalisation work, and a use case with measurable volume. What they don't have in common is size, industry, or how long they've been on Salesforce. Readiness is not primarily about Salesforce technical maturity. It's about operational maturity:
- One or two high-volume service workflows where the resolution pattern is consistent enough to codify
- Knowledge content that is accurate, current, and structured for retrieval rather than human interpretation
- Contact and account data that is clean enough for the agent to reliably identify who it's dealing with
- A named owner for the data quality improvement work that will be required
- A sponsor who accepts that the first deployment is a controlled pilot with defined success criteria — not a universal rollout
Most ANZ mid-market Salesforce customers are not all the way there yet. That's not a reason to dismiss Agentforce — it's a reason to be clear-eyed about what the pre-work looks like before the commercial commitment is made.
The sales motion shapes the conversation
Agentforce is entering ANZ customer conversations in different ways — at renewal, in separate AI discovery workshops, and as part of new platform or cloud deals. The consultative framing Salesforce is using is appropriate given the complexity. But the incentive structure that shapes any AE's conversation is worth understanding.
Salesforce AEs are measured on adoption and expansion, not just initial sale. Agentforce is a significant strategic priority for Salesforce at a corporate level. That combination means there is genuine enthusiasm in the sales organisation for moving customers toward Agentforce — and that enthusiasm is not always calibrated to where the individual customer actually sits on the readiness curve.
This is not a criticism of individual account executives, most of whom are genuinely trying to help customers get value. It's a structural observation: the commercial conversation tends to lead with what Agentforce can do, and follow with what you need to have in place to make it work. A prepared buyer reverses that sequence. Before getting into pricing, use case demonstrations, or ROI modelling, the foundational questions are: What does our data actually look like? Who owns data quality? Do we have the governance to make this work?
Where to start if you're genuinely interested
The strongest Agentforce starting point for an ANZ organisation that wants to move carefully is high-volume customer service deflection — specifically, a defined set of repeating query types where the resolution is consistent and the knowledge already exists in reasonable shape.
The reason this use case works is that it is bounded and measurable. You can define what success looks like before you start (deflection rate, handle time, first-contact resolution), you can run a limited pilot before committing to broader deployment, and you can assess data readiness against a specific and concrete set of requirements rather than in the abstract.
If a pilot in that context produces the numbers, expansion to adjacent use cases can be scoped with evidence rather than assumptions. If it doesn't, you've learned something valuable and contained the cost of learning it.
The organisations that get the most from Agentforce will be the ones that treated the first deployment as a structured experiment, not a statement of intent.
Mike Roberts spent over eight years at Salesforce, including time as a Strategic Account Director, before founding Aequus Consulting. He works with New Zealand organisations on Salesforce licence optimisation and renewal preparation, with no vendor affiliations.