How to measure the ROI of a Salesforce Agentforce implementation
ROI here is a comparison you can audit, not a deflection rate borrowed from a vendor slide. Count what stayed resolved, what the remaining work costs, whether the handoff was any good, and the meter on the contract you signed.
AI & AgentforceA return figure without a baseline is a slogan. The slide in the steering pack shows average handle time down. The same month, reopens are up, and the supervisors who used to take escalations are now sampling closes as well. The average dropped because the short status questions left the sample. The operation got more expensive, and the slide cannot see it.
Before you add Agentforce to a business case, write down the queue as it is. Volume, by topic and by channel. Reopen behaviour, using the window the service team already uses. Time spent on the contacts a person still has to finish, kept separate from the contacts that never needed one. The implementation is allowed to change those numbers. It is not allowed to replace them with a percentage published for someone else's mix of topics, channels, and willingness to hand work over.
Salesforce states that pricing options include Flex Credits, Resolutions, or per-user licensing. Those are different units. Pick the one on your order form and keep every later report in that unit. Do not convert it into a deflection rate and call the result a return. A credit, a resolution, and a seat do not become comparable by dividing them into a percentage.
What you are comparing
A return here is a comparison you can audit. Four numbers, taken the same way before and after, on the same topics.
Containment that stayed resolved. Handle time on the work that remains with a person. The quality of the escalations, which is a sample rather than a rate. And the meter on the contract you signed, sitting beside the hours of supervision the meter does not include.
Leave out any number you cannot reconstruct from the org. A conversation count from a vendor console, defined their way, is not a substitute for a Case that stayed closed in your window. If the before column is empty, you have a pilot and a bill. Say that. A pilot can still be worth running. It is not yet a return.
The temptation is to borrow a deflection figure because the business case has a blank cell and a meeting on Thursday. Deflection that does not cost you the customer sets out why that single rate moves the wrong way when the agent stops handing work over. This page will not repeat that argument. Use it as the check on the rate, then come back to the four numbers here. The cost side of the same comparison, including supervision as a roster line, is how call centre cost actually moves.
Containment that stayed resolved
Containment is the work the agent finished that did not come back. A Case set to Closed is not enough. If Status returns to a working value, or the same person opens a new Case for the same question, the first close did not hold. You paid for an attempt, and then you paid a person to do the contact, often with a customer who is now repeating themselves.
Choose the window your service team already uses for reopens. If that window is the one the weekly pack already argues about, keep it. Do not change it after launch because the chart looked better on a shorter one. A shorter window is a different metric. It will manufacture an improvement on the day you adopt it, and the manufacturing will be invisible to anyone who was not in the room.
Split the count by topic. A status question that stays closed is not evidence that a complaint did. A topic you listed as out of scope should not appear in the contained column at all. If it does, the close is a failure of the boundary, and it does not belong in the numerator of a return.
The trap is treating every conversation that never reached a person as contained. Some of those conversations ended because the person gave up. They come back on the phone, or they do not come back at all, and neither outcome is stored on the Case you closed. Where you can see a second contact from the same person on the same question, count it against the first close. Where you cannot see it, say so. Do not describe the unseen residue as success.
Handle time on what remains
The contacts that still need a person are the cost you did not remove. Measure handle time on that remainder, not on a blend that hides it inside volume the agent touched. Blended average handle time falls when the easy contacts leave, even if every remaining contact takes longer than it used to. The blend is a flattering average. It is the wrong number to put in front of a steering group.
Handle time falls when the person starts from a payload. Which Account. Which Case. What was asked, in the customer's words rather than a rewritten summary that has already decided the topic. Which action already ran. What the agent refused to do, and why. A person who can see those five things does not repeat the identification, and does not apologise for an answer they have not heard.
Handle time rises when the payload is missing. The person asks for the order number the previous automation used to collect, and then hears that the customer was already told something. That second conversation is part of the implementation's cost even though the agent is no longer in it. If you only time the agent's turn, you will report a saving the floor is currently paying for.
Keep the before and after on the same kind of contact. Status questions that a person used to finish quickly are not the right baseline for the complaints that remain. If you compare a mixed historical average with a post-launch average of hard cases, you will conclude that the agent made the work slower. It may have. You cannot tell from that comparison. Split the topics first, then compare.
Escalation quality
Salesforce's line is that agents escalate when the issue is beyond their scope. Quality is whether that happened for the right records, and whether the person received enough to start work.
Sample two piles, and write down the size of each sample so the next month can be compared with it. Pile one is escalations. Did a person actually need to take them, and did the note carry the facts? An escalation that arrives as "please assist" is a transfer of the conversation, not of the work. Count it as a weak handoff even when the topic was genuinely out of scope. Pile two is closes. Did any of them concern money, a complaint, or a topic you had listed as out of scope? A falling escalation count is not a win if pile two is full of cases a person should have seen.
Write the out-of-scope list before launch, in words a reviewer can apply to a Case without asking the model how confident it felt. At least one entry should be a business rule. Any mention of a regulator. A hardship request. A sum above a threshold you already use for a supervisor. A confidence score is a poor substitute, because a confident wrong answer is the case a score will not catch. The score describes the plan's manner. The list describes the organisation's boundary.
Review the two piles on a cadence you will actually keep. Twenty escalations and twenty closes, once a week in the first month, is enough to see a topic going bad. A dashboard of rates without a read of the notes will tell you the volume moved. It will not tell you whether the move was the one you wanted. Count the handoff, not the transcript. A transcript can be polite while the note the next person received is empty.
The meter you bought
Read the contract before you design the report. If you bought Flex Credits, report credits consumed against work that stayed resolved, and against work that came back. A credit spent on a close that reopened is not a credit spent on a contained contact. Putting both in one consumption bar hides the waste in the total.
If you bought Resolutions, report resolutions against the same resolved work, and define a resolution the way the contract does, not the way a dashboard shortcut does. If the contract counts a conversation that ended without a person, and your operation counts a Case that stayed closed, those are different events. Use the contract's unit for the bill, and your unit for the claim that the work stayed finished. Show them side by side. Do not average them.
If you bought per-user licensing, the variable story is different. A seat does not tell you whether the work stayed finished. You still need containment, handle time on the remainder, and supervision hours, because the seat is a cost you carry whether the topic is behaving or not. A quiet seat and a busy seat can look identical on the order form.
Do not quote a vendor deflection percentage as your number. Their traffic, their topics, and their willingness to escalate are not yours. A percentage without the topic mix, the reopen window, and the escalation rule cannot be subtracted from anything you measure. A deployment story that offers you a percentage is subject to the same test. If you cannot see their before column, you cannot import their delta.
What the comparison looks like when it is finished
This is the sheet. Four rows, a before, an after, and a note on what would make the row dishonest. If a cell is blank, the return is not ready to be claimed. The blank is the finding.
| Measure | Before | After | Dishonest if |
|---|---|---|---|
| Containment | Closes that stayed closed, by topic, in the existing window | The same window and the same topics | The window was shortened, or out-of-scope topics sit in the numerator |
| Handle time | Time on contacts a person finished, split by topic | Time on the contacts a person still takes | The figure is a blend that includes work no person touched |
| Escalation quality | A sample, not a rate, of who needed a person | The same sample size, with the payload present or absent | The count fell and nobody read the closes |
| Meter | The unit on the order form | Credits, resolutions, or seats, beside supervisor hours | The unit was converted into a deflection percentage |
Read the last column in the steering meeting. Almost every flattering chart fails one of those four tests. The chart can still be shown. It cannot be the business case.
Where the claim goes wrong
Three shapes, and each is recognisable before the quarter closes.
The missing baseline. The agent is live, the pack needs a number, and someone divides contained conversations by total conversations. There is no before. The percentage cannot be a change. Call it a pilot measurement and reconstruct the queue from the Cases you already have. A rough before, labelled as rough, is more honest than a precise after with nothing beside it.
The shortened window. Reopens are counted inside a tighter period because the original figure was uncomfortable. The metric improves on a Tuesday with no change to the agent. Put the window back. If the longer window is the one the operation already manages to, it is the one the agent has to survive.
The supervised average. Handle time is reported for the agent, and the hours spent sampling closes are left in a different budget. Supervision is a roster line. It is part of the cost of the topic. A topic that needs a person reading every close has not removed that person from the work. It has moved them from the contact to the review.
If the four rows are filled in the same units as last month, you have a comparison. If the meter is known, reopens are not up, and handle time on the remainder is down because the payload is present, you can describe that without borrowing anyone else's percentage. If any row is missing, you have an incomplete account. Incomplete is a fine status for a pilot. It is a poor status for a claim.



