Case studies of successful enterprise Agentforce deployments

A keynote slide has a logo, a percentage, and a sentence about autonomous service. The percentage has no before column, no topic list, and no mention of a case the agent was told to refuse. Someone in the room writes the percentage into a forecast. Six months later the forecast is missed, and the slide is still being quoted, because nobody can point at the cell that was empty.

This page does not present invented customers, invented logos, or invented results. A story that cannot show its working is not made true by a brand name in the corner. If you want deployment write-ups you can read against the tests below, start at case studies. Apply the same tests to any other story, including one from a vendor keynote and including one from a firm you otherwise trust. Trust is not a method. The four tests are.

Salesforce describes Agentforce as autonomous support at enterprise scale. Scale is not a result. A result is a change against a baseline, inside a scope, produced by named roles, with a list of work the agent was told to refuse. Salesforce also says agents escalate when the issue is beyond their scope. A deployment story that never mentions an escalation has left out the boundary that makes the rest believable. The boundary is not a footnote. It is how you tell a narrow success from a story that edited the hard cases out.

#The baseline

The baseline is the queue, the cycle, or the backlog before the agent, measured the way you will measure it after. Same channel. Same topics. Same reopen window. "We improved containment" without those three is not a baseline. It is a direction, and a direction cannot be subtracted from your numbers.

Demand the before number and the after number side by side, in the same unit. If the story switched from calls offered to conversations deflected halfway through, you cannot subtract them. They are different events. A call offered is something your telephony counted. A conversation deflected is something the agent's report counted, often including contacts that never became a Case, and sometimes including contacts that came back the next day under a different name. Put them in two columns if you must show both. Do not subtract one from the other and call the remainder a change.

If the window for a reopen was shortened after go-live, the improvement is partly the window. A close that used to be checked over the period your operation already manages to, and is now checked over a shorter one, will look more contained on the day the definition changes. Ask whether the window moved. If the story does not say, assume you cannot tell, and do not import the delta.

A story with no before column cannot support a business case. You may still learn how they staffed the work, which topics they refused, and which channel they were willing to leave on the old bot. You may not import their delta. The way to build the before column for your own queue, rather than borrowing one, is the return comparison. A case study can show you the shape of that sheet. It cannot fill the cells.

#The scope

Scope is what was turned on, and what was not. Which channel. Which objects, such as Case and Knowledge, and which fields. Which topics. What stayed on the old bot. What went straight to a person from the first day. A story that cannot answer those is a description of a product, not of a deployment.

A story that says the agent "handles service" has not stated a scope. Service includes refunds, complaints, and status questions. Those are different risk levels, and they fail in different ways. Status questions can stay resolved and still tell you nothing about a complaint. If the write-up cannot tell you which of them was in the first release, assume the impressive number is the easy subset, and that the subset is unnamed. The unnamed subset is the one that will not match your queue.

Out of scope is part of scope. A serious story says which requests the agent must not finish. Money. A regulator. A hardship request. A topic the old bot already escalated. If the story's scope is only a list of what the agent can do, the list of what it must not do is either missing or was never written. You will discover it in production, which is an expensive place to write a refusal.

Ask what happened to the paths that were already correct. A dialog that collected a case number and called a Flow is a scope decision too. If the story retired it in the name of one front door, the result includes whatever guessing replaced the slot. If the story does not mention the old bot at all, ask whether it was still there. Silence usually means it was turned off, not that it was never needed.

#Who staffed it

Someone reconciled the articles, chose the running user, wrote the stop rules, and sampled the closes. A story that credits only "the business" or only "the partner" has not told you the work. Look for roles. A service owner who can say whether two replies are the same question. A Salesforce admin who can see the Flow the agent must not reimplement. The person responsible for the source articles, by name of the role even if the story omits the person. The supervisor who can pull a topic when reopens move.

If those roles are absent from the story, you do not know whether you have them. Copying the agent design without the staffing is how the same build fails in a second organisation. The design was never the whole cost. The article owner is the cost people forget, because the agent will quote a stale article faithfully and the failure will be filed under the model. The supervisor is the cost people forget because their hours sit in a team leader's day rather than in a handle-time code. Call centre cost moves into that supervision, whether or not the story mentioned it.

Ask how much of the work was still going on after go-live. A story that ends at launch has not staffed the operating cadence. Sources change. A policy article is edited. A new subagent gets added because a stakeholder liked the demo. Someone has to re-run the traces. If the story has no named owner for the month after launch, the result you are looking at may be a pilot week, described as a deployment.

#What was refused

Ask for the refusal list. Subagents that always escalate. Actions the library does not contain. The rule that sends money, hardship, or a legal mention to a person. A list that lives only in a slide, and not in the instruction the plan sees, is not yet a refusal. Ask where it was enforced. An action that is simply absent from the library is a stronger answer than a paragraph that says the agent should be careful.

Then ask what happened when the agent met one of those cases. A real deployment has at least a sentence on escalations that were right, escalations that arrived empty, and closes that should not have happened. Empty is the interesting one. It means the boundary fired and the payload did not, so the person inherited a conversation rather than a piece of work. If the story is only successes, it has not been near a hard case, or it has edited the hard case out. Either way you cannot copy the design and expect the hard case to go well for you.

Ignore any percentage you cannot place in that table. Do not paste it into your forecast. Your meter, your topics, and your reopen rule are the only numbers you can defend. A percentage from another organisation, on another mix, with another escalation rule, is a description of their queue. It is not a property of the product.

#How to read one without wasting the meeting

Read in this order, and stop when a test fails. Baseline first, because a missing before column ends the numeric conversation immediately, and you can spend the rest of the meeting on staffing. Scope second, so you know whether the number, if it survived, describes a status topic or a complaint topic. Staffing third, so you can compare the roles with the people you actually have. Refusals last, because a story that has passed the first three and still never escalates is telling you something specific: the scope was easy, or the failures were cut.

What you may copy is concrete and small. The shape of the refusal list. The decision to leave a narrow dialog on the old bot. The role that owns the articles. The habit of sampling closes rather than trusting the board. What you may not copy is the delta, the timeline, or the implication that your topics are as easy as the ones a story was willing to write down. If the story took a quarter and names four roles, that is a hint about duration and staffing, not a promise. Your articles may be in worse shape. Your running user may be wider. Your reopen window may be longer. Each of those makes the same design slower, and none of them appears in a percentage.

Then ask one question the story will often fumble. What did they turn off, or pull, after launch? A deployment that never pulled a topic has either been very narrow or very lucky, and luck is not a design you can copy. The rollout habits that keep a topic pullable, including a trace you can actually read, are in what separates an Agentforce rollout that is still running in six months. Bring that standard to the story. A write-up that cannot bear it is a brochure, and a brochure is allowed to exist. It is not allowed to become your forecast.