Agentforce use cases that survive a business case

Ask a vendor for Agentforce use cases and you get a list of forty. It is not a dishonest list. Each item on it is genuinely something an agent can do somewhere. The problem is that it is sorted by what is possible rather than by what is ready, and those are different lists in every org we have worked in.

This is the scoring we use instead.

#Three axes, and you need all three

Score each one to five. The mistake is treating this as an average. A candidate scoring 5, 5, 1 is not a 3.7, it is a use case that will hurt you, and the third axis is a veto rather than a weight.

#Where the scoring usually surprises people

High volume is not the same as good. The highest-volume intent in a service queue is often "where is my order", which looks ideal until you find that answering it properly needs a live call into a logistics system nobody has exposed. Volume is what makes a business case look good and what makes an early deployment look bad, because volume brings variance.

The best first candidates are boring and internal. An agent that answers staff questions from policy documents has a forgiving audience, a narrow permission surface and colleagues who will tell you immediately when it is wrong. That feedback is exactly what you need to learn to operate agents before customers see one.

Some popular candidates are structurally hard. Anything requiring the agent to apply discretion your business has never documented is not a data problem you can fix in a sprint. If three experienced staff would give three different answers, the agent is not being asked to retrieve, it is being asked to decide, and you have not decided.

#A worked pass

Running this over a typical service backlog tends to produce something like:

The two "start here" rows are unglamorous and neither will headline a board pack. They are also the two most likely to still be running next year, which is the actual test.

#Sales and service pull in different directions

For service, the constraint is almost always knowledge quality, and the value is measurable in contacts. For sales, the constraint is adoption: an agent that drafts follow-ups is technically simple and commercially useless if reps do not trust it enough to use it. Salesforce positions these differently across customer service AI and its sales agent guidance, and the difference matters when you are scoring, because a sales use case needs a fourth question about whether the workflow it sits in is one reps actually follow.

#Pricing the candidate honestly

Consumption is metered per action, with buying models published on the Salesforce pricing page. Two consequences for scoring. A use case that needs six actions to answer one question costs six times one that needs one, which changes the value axis. And the dominant cost in most business cases is not consumption at all, it is the grounding and permission work that data readiness was warning you about.

#Reading the three axes against each other

The interesting information is usually in the gap between two scores rather than in either one.

High value, low data readiness is the most common and most expensive pattern. It describes a use case everybody wants and nobody can currently support, and it is the shape that produces overrunning projects, because the effort lands in remediation that was never scoped. The correct response is not to decline it. It is to re-present it as the remediation project it actually is, with the agent as the final, cheap step.

High data readiness, low value is the opposite trap and much less discussed. These are the use cases that get built because they are easy, ship successfully, and change nothing. A working agent nobody needed still costs consumption, evaluation effort and attention, and it occupies the organisational slot marked "we tried AI".

High value, high readiness, high error cost is the genuinely hard one. Everything says go except the consequence of being wrong. This is where the narrow version earns its keep: keep the retrieval and the preparation, move the decision to a human, and you capture most of the handling time with none of the exposure.

#Where use cases come from

A backlog assembled by asking stakeholders what they want produces a list sorted by enthusiasm. Three better sources.

Contact reason data. What people actually ask, in volume order, with the long tail visible. This is the least flattering and most useful input, because it usually shows that the intents everyone discusses are not the intents that fill the queue.

Handling time outliers. The interactions that take longest are often long because an agent is assembling context from four systems. That assembly is exactly what retrieval is good at, and it is invisible in contact volume.

Repeat contacts. Where customers come back a second time, something failed the first time. Some of those failures are knowledge gaps that an agent would surface immediately, which makes them a diagnostic as well as a candidate.

#The fourth axis, for sales only

Service use cases live or die on knowledge quality. Sales use cases live or die on whether reps use them, and that is not the same question, so sales candidates get a fourth score: workflow fit.

Ask where in a rep's actual day this sits. An agent that drafts follow-up emails scores well on the first three axes and fails here if reps write follow-ups inside their inbox rather than inside the CRM, because you have built something correct that lives in the wrong place. The fix is usually not a better agent. It is putting the capability where the work already happens, which is a design decision made before anything is built.

The pattern generalises: any use case whose value depends on a human choosing to use it needs this fourth score, and any use case that runs without a human in the loop does not.

#Two candidates worth examining closely

Case summarisation consistently scores well and is consistently underrated. It is internal, so the error cost is low. The source material is the case itself, so data readiness is high by construction. And the value is real but diffuse, which is why it rarely wins a prioritisation argument against something customer-facing.

It is also the best possible first deployment, because it teaches a team to evaluate answer quality on material where they already know the correct answer. That skill is what makes the next, riskier deployment safe.

Order and delivery status is the mirror image: the highest-volume request in most service queues, and a data readiness problem masquerading as an AI project. The answer lives in a logistics or ERP system, so the work is an integration with its own schedule, security review and failure modes.

Scoring it honestly usually reveals that the organisation has wanted that integration for years and has never funded it. An agent project is a reasonable way to finally fund it, provided everyone understands that is what is being bought.

#How often to re-score

Scores move, mostly because data readiness moves. An integration lands, a knowledge base gets cleaned up for unrelated reasons, or a policy finally gets written down, and a candidate that scored 2 becomes a 4.

We re-run the scoring quarterly and at every significant platform change. The discipline that matters is keeping the rejected candidates on the list with their scores visible, rather than deleting them. A backlog that only contains approved work loses the institutional memory of why the others were declined, and the same use case gets proposed again in six months by somebody who was not in the room.

#Sequencing the ones you approve

Order matters as much as selection, and the instinct to run approved candidates in parallel is usually wrong early on.

The first deployment should finish before the second starts, because the first one is not really about its own value. It is where the team learns to ground, evaluate, escalate and operate, and those lessons change how the second is built. The order those steps run in, and the gate between each, is set out in implementing Agentforce: the sequence, and the gate between each step. Running two in parallel means making the same mistakes twice simultaneously.

From the third onwards, parallel is fine and often sensible, because the operating machinery exists and the marginal work per intent is genuinely small. The dividing line is whether you have run a regression set through a real change yet. Until you have, you do not know whether your evaluation actually works, and adding scope on top of an unproven evaluation is how deployments become unmaintainable.

#When the business insists on a bad candidate

This happens, and refusing outright is rarely the useful response. Two things work better.

The first is to reprice it honestly. A use case scoring 2 on data readiness is not an agent project, it is a remediation project with an agent at the end. What that remediation actually involves is covered in the grounding checklist we run before an agent talks to a customer. Presenting it that way often changes the decision without anyone having to lose an argument, because the sponsor can see what they are actually buying.

The second is to propose the narrow version. If the demand is an agent that handles refunds, offer one that gathers the information, checks eligibility against written policy and prepares the case for a human decision. That captures most of the handling time, leaves the judgement where it belongs, and can be widened later once the policy is genuinely written down.

#What to do with the losers

A low score is not permanent. Most of the "after the integration exists" rows become viable once something else lands, and keeping them on the scored list means you revisit them when it does. What should not happen is the thing we see most: a use case that failed on data readiness gets built anyway because it scored well on value, and then absorbs a quarter of remediation work that nobody planned or funded. It is the most expensive of the errors in ten Agentforce mistakes and what each one looks like in production, and it is entirely avoidable at scoring time.