How to Get Agentforce Right: Use Cases, Costs, and What Drives ROI

A practitioner’s guide to the three use cases that deliver ROI, what they cost, and how to avoid the two mistakes that stall most builds.

Agentforce works exceptionally well in 3 places: high-volume service deflection (Wiley hit 40%+ resolution lift, Fisher & Paykel went from 40% to 70% self-service), inbound lead qualification at scale (Salesforce’s own SDR agent generated $1.7M from dormant leads in year one), and internal IT ticketing in Slack. It breaks predictably in two: when the data layer can’t carry the use case, and when governance gets retrofitted instead of designed. Skip the four-layer explainer. Read the scenarios.

TL;DR

• Agentforce has crossed $100M+ in reported annualized customer cost savings, 18,000+ deployments, and shipped real metrics. This is not a science project anymore.
  
  
• It earns its license cost in three patterns today: tier-1 service deflection, inbound sales qualification, and Slack-native IT support. Outside those, evidence is thinner.
  
  
• Wiley got a 213% ROI and onboarded seasonal agents 50% faster. Fisher & Paykel lifted self-service from 40% to 70%. Salesforce’s own SDR agent generated $1.7M from dormant leads.
  
  
• It still breaks in two predictable places: weak data foundations producing confident hallucinations, and Trust Layer config treated as a launch-week checkbox instead of a week-one workstream.
  
  
• The cost question most teams get wrong: licenses are roughly 30% of total first-year spend. Data work and implementation are the other 70%, and that’s where budgets quietly collapse.

I spent the better part of my professional journey as a CRM developer before finding my north star in the marketing side of the table.

Which means I have, at various points, been the person who built the pipeline that broke, the person who explained why it broke, and now the person who writes about why it keeps breaking for everyone else.

I bring this up because most Agentforce articles you’ll read are written from one of those three vantage points. You can usually tell which.

This one is written from all three. So when I tell you Salesforce’s Agentforce wins in three specific patterns and breaks in two specific places, I’m not borrowing the framework from a Gartner slide. I’m telling you what the data, the customer stories, and frankly my own buyer conversations all point to once you strip away the conference-keynote tone.

There are a hundred explainers on the internet that will walk you through the Atlas Reasoning Engine, the four product layers, and Salesforce’s "agentic enterprise" vocabulary. Salesforce’s own site does that well, and frankly with better screenshots than I can produce.

What this blog does instead is tell you the three things Agentforce is genuinely good at, give you the named cases and the hard numbers behind each and a lot more. 

What is Agentforce?
(in plain terms)

Agentforce is Salesforce’s autonomous AI agent platform.

The technical anatomy (Atlas Reasoning Engine for orchestration, Data Cloud for grounding, MuleSoft Agent Fabric for cross-system actions, Einstein Trust Layer for governance) is documented exhaustively elsewhere.

Three things you actually need to know:

How is Agentforce different from a chatbot?

First, this is not a chatbot. Chatbots respond. Agents take actions. The difference is not conversational polish, it is action authority. 

Salesforce’s own customer service team, running Agentforce as "Customer Zero," handled 1.5 million+ support requests in year one, "the majority of cases without humans," per their own internal write-up. 

Second, the quality of the agent is the quality of your data. SharkNinja, after 250,000 customer conversations through their personal shopper agent, summed up their biggest lesson in one line: "the agent is only as good as the data behind it."

This is the unsexy truth nobody puts on a Dreamforce slide.

Third, governance gets designed in, not bolted on. Salesforce’s own team famously launched their agent with a "competitor block list" that included Microsoft. Then a customer asked about integrating Microsoft Teams with Salesforce, and the agent politely refused to help.

They had to rip out the rigid rule and replace it with "act in the customer’s best interest." If Salesforce, with the entire product team in the building, learned this the hard way, you can assume you will too unless you design for it.

That’s the shape. Now let’s talk about where it actually earns its license cost.

Where Agentforce actually earns its license cost

Across 18,000+ deployments and the public case studies Salesforce has put on record, three use cases recur. These are the places Agentforce produces measurable ROI today, with named customers and verifiable numbers. I’ll take each use case one at a time.

Agentforce for customer service: where the wins are clearest

This is Agentforce’s strongest published use case, by a wide margin, and the one with the most defensible ROI.

The pattern is consistent: high-volume, repetitive service requests with predictable resolution paths, grounded in a structured knowledge base, with the agent empowered to actually complete the action (reset a password, triage a payment issue, resolve an account lockout) rather than just describe it.
Wiley, the academic publisher, is the cleanest published example.

Their problem was seasonal: every new semester surge produced service-call spikes that crushed their human team. They deployed Agentforce on top of their Salesforce Service Cloud, grounded it in their existing knowledge base, and instrumented it to handle account access, password resets, and registration triage autonomously.

Fisher & Paykel ran the same play in appliance support and lifted self-service from 40% to 70%, grounded on thousands of existing knowledge articles.
Grupo Falabella moved 71% of customer service interactions in their Colombia operation onto WhatsApp via Agentforce in three weeks.
The pattern repeats: clean knowledge base, well-defined action paths, measurable deflection, money saved.
The thing nobody says out loud is that Agentforce wins here partly because the bar is low. Most enterprise service chatbots are bad. They route, they FAQ, they apologize. Agentforce, when grounded properly, completes the task. The delta isn’t marginal, it’s categorical.
When to bet on this scenario: you have a Service Cloud, a knowledge base that someone has bothered to maintain, and at least one resolution flow that’s currently consuming human time you wish it weren’t.
When not to bet on it: your knowledge base is a graveyard of outdated PDFs. The agent will reflect that, confidently. Garbage in, hallucinated answers out.

Agentforce for sales: the SDR you don’t have to manage

This is the second use case with hard, published ROI behind it. Salesforce’s own Customer Zero data is the most compelling, partly because they’ve been brutally transparent about both the wins and the early failures.

After one year of running their own SDR agent in production, the published numbers:

the agent worked over 43,000 leads, generated USD 1.7 million from previously unattended leads, and performed high-volume follow-up no human SDR team could deliver on a 2AM Sunday.

The "Jacuzzi" case is the cleaner mid-market analog.

Jacuzzi shifted from a manual lead intake process for hot tub quotes to Agentforce-driven qualification, with the agent walking prospects through detailed qualifying questions and routing accordingly. Reported lift: improved lead quality, better routing, higher conversion.
CentralSquare uses Agentforce to "autonomously answer inquiries, qualify and triage leads, and schedule follow-ups for sales reps," which is roughly the textbook definition of an SDR’s job description, minus the dental insurance.
The reason this scenario works is that inbound qualification has a structural advantage over outbound: the prospect has self-selected as interested, the context is available (form fill, behavioral signal, CRM history), and the action paths are narrow (qualify, route, schedule, or disqualify). It’s a good fit for an agent because it’s a contained decision space with clear handoffs.

Where this scenario quietly breaks: outbound prospecting at scale.

Salesforce’s own writeup admitted their early SDR agent felt "too transactional" to customers, and they had to retune the experience. Cold outreach via agent, in my view, is still a year early. Inbound qualification, today, is the workable pattern.

Agentforce for internal IT: the quiet ServiceNow killer

This is the use case that gets the least Dreamforce stage time and produces some of the cleanest ROI.

Internal IT support: password resets, access provisioning, ticket triage, basic troubleshooting, all running natively inside Slack or Teams.

Accenture deploys it across 76,000 employees this way. Salesforce’s own internal Slack deployment freed up "500,000 hours back this year by handling routine tasks," per their own published metrics.

The reason this scenario is structurally so strong: the user is already where the agent lives (Slack), the request types are highly repetitive, the action paths are bounded (reset, provision, escalate), and the alternative is a legacy ITSM platform that everyone hates renewing.

I’ve seen three serious ServiceNow displacement conversations triggered by Agentforce IT Service in the last twelve months. The deployment time is measured in weeks. The renewal sticker is measured in seven figures. The math, frankly, is not subtle.

A practitioner observation: this is the scenario I’d recommend most companies start with if they want a low-stakes, high-confidence first build.
The data foundation is small (your IT knowledge base and access management system), the audience is internal (so failure modes are forgiving), and the win is measurable (tickets deflected, hours saved). It’s the most underrated entry point in the entire Agentforce product line.

If one of these three patterns maps cleanly onto something your business does today, you have a use case worth scoping. If none of them do, you probably don’t have an Agentforce use case yet, you have an Agentforce aspiration. Those are different things, and conflating them is how 90 days disappear.

How to keep your Agentforce build from stalling

Now the honest part.

The platform is good. The customer stories are real. The ROI numbers stand up to scrutiny. None of that means a build won’t fall over in implementation.

Most of the breakage I see clusters into two patterns. Not five. Two.

Get your data foundation right first

Every single customer in the published case studies that worked, worked because the underlying data was clean enough to ground the agent.
Wiley had a real knowledge base. Fisher & Paykel had thousands of structured product articles. Salesforce’s own deployment leans heavily on Data Cloud unification before any agent goes live.
When teams skip this, the failure is predictable and embarrassing.

SharkNinja, after 250,000 conversations in production, distilled the entire lesson into one sentence: the agent is only as good as the data behind it.

Nexo, an early adopter, faced what they publicly called "technical debt, data cleanup, and real-time troubleshooting with no playbook" before they reached 62% case resolution. Safari365 went live in six weeks, but only after confronting "hallucinations, missing guardrails, and technical gaps."

What this looks like in practice: your knowledge base is three years out of date, your CRM records have a 40% completeness gap, and your product taxonomy exists in three slightly different versions across teams.
The agent ingests all of it and produces fluent, confident, wrong answers. Hallucinations here are not a model problem. They are a hygiene problem.
The honest fix is not glamorous. Data Cloud setup, knowledge base structuring, grounding configuration, and a real audit of CRM completeness will eat four to six weeks of your timeline.
If you’re not allocating that time upfront, you will allocate it under pressure later. That math doesn’t change.

Design governance in from week one

This is the break that surprises smart teams, because the platform comes with a Trust Layer out of the box and it’s easy to assume that’s enough.
It is not. The Trust Layer is a fabric, not a configuration. It needs decisions: what data can the agent see, what actions can it take, what must it never say, who reviews its decisions, how is its activity logged for audit and compliance.
The Salesforce Customer Zero team learned this in public, which is generous of them.

They launched with a "competitor block list" that included Microsoft. A customer asked a perfectly reasonable question about integrating Microsoft Teams with Salesforce. The agent refused.
They had to rebuild the guardrail approach from rigid block lists to "act in Salesforce’s, and by extension, the customer’s, best interest." The shift was elegant. The lesson was expensive in pride.

In regulated industries (fintech, healthcare, financial services), retrofitted governance is worse than embarrassing.

It is the thing that blocks your pilot six weeks before go-live, when legal review finally arrives and discovers the agent has been quietly accessing data it has no business touching. I have seen this twice in the last eighteen months. Both times, the rescue was technically possible but politically expensive.

The pattern that works: governance becomes a real workstream in week one.

Not "we’ll figure out the Trust Layer config before launch." A named owner, a written policy, an access-review cadence, and an audit log architecture, all designed alongside the agent.

This is unglamorous, it adds two weeks to your week-one phase, and skipping it is the single most predictable way to lose a quarter.

Two breaks. That’s the honest count. If you see either of these starting to crack open in your build, the cost of intervention drops dramatically the earlier you catch it.

How much does Agentforce cost? (And where the budget really goes)

Salesforce sells Agentforce through several SKU paths: Agentforce One, conversation-based pricing, bundled Enterprise License Agreements.

List prices shift, and quoting them in a blog ages the article in roughly a quarter. Talk to Salesforce directly for current licensing.

The more useful framing, and the one I’d argue is underdiscussed in most procurement conversations, is total spend allocation. On a typical mid-market build:

• Licenses: roughly 30% of first-year cost
• Data foundation work (Data Cloud setup, knowledge structuring, grounding, integration): roughly 40%
• Implementation services, change management, post-launch tuning: roughly 30%

The implication that catches people out: if leadership has approved a license number and assumes that’s the project budget, the project is underfunded before it starts.

The right framing is total program cost. The right time to surface that is during scoping, not during build.

When it surfaces during build, someone usually loses their job. Try not to let it be yours.

Where OneMetric fits on an Agentforce build

OneMetric is a CRM consultancy, a Salesforce partner and a HubSpot Elite partner (roughly the top 2% globally). Our view: Agentforce doesn’t succeed in isolation. It succeeds based on how clean the CRM data, governance, and workflows underneath it are. That’s where we’re most useful, and most of it sits upstream of the agent itself:

• Agentforce readiness and use case scoping, so teams pick a first build that can actually ship
• CRM data foundation work (Data Cloud, knowledge base structuring, hygiene audits), the part that decides whether an agent grounds cleanly or hallucinates
• Salesforce implementation and integration for hybrid HubSpot and Salesforce stacks
• Governance and Trust Layer planning, designed in early rather than retrofitted under legal review

On the build itself, we work alongside your team rather than positioning ourselves as a high-volume development shop. The category is young, the deep-certification SIs are still finding their footing, and the part that most often decides success is the CRM and data work underneath, which is exactly where our foundation is strongest.

How to scope your first Agentforce build

If your use case maps onto one of the three patterns here (service deflection, inbound qualification, internal IT) and your data is in better shape than "PDFs in a SharePoint folder no one has opened in 18 months," you have a real build. Scope it for 10 to 14 weeks, fund it for total program cost rather than license cost, and put governance on the week-one critical path.

If it doesn’t map onto one of those, you have something more ambitious and riskier: a custom or multi-agent build. Buildable, but not your first project. Save it for build two.

If you’re scoping a build, or already underway and want a second opinion on use case fit, data readiness, or governance, our team runs free 30-minute scoping calls. No deck, no follow-up sequence. I’ll tell you whether the failure modes in this article apply to your build, and where I’d intervene first.