The right Agentforce use case sits where a meaningful business problem, a repeatable process, suitable data and a measurable outcome come together. Rather than asking, “Where can we use AI?”, start by identifying work that consumes significant time, delays customers or employees, creates operational friction or prevents people from focusing on higher-value activity.
Then test whether an AI agent is actually an appropriate way to improve it.
At Sweet Potato Tec, we have rolled out multiple agents across our client ecosystem, and one principle shapes how we approach new Agentforce projects: start with a clear business objective and a focused use case.
Our Agentforce Quickstart deliberately begins with needs assessment. We map use cases, workflows and constraints to identify the right starting point because not every process is suitable for an AI agent.
Choosing well at this stage matters. Your first Agentforce deployment should prove that AI can solve a real problem, not simply prove that your organisation can configure an agent.
Key takeaway: what makes a good Agentforce use case?
A strong Agentforce use case usually has six characteristics: it addresses a genuine business problem, involves repeatable work, has clear inputs and outcomes, can access reliable data, has manageable risk and can be measured after deployment.
For a first implementation, there is another important characteristic: the scope should be controlled.
Sweet Potato Tec’s approach is to identify one high-value use case, configure it properly, test it and put it into production. Once the organisation has evidence that the approach works, Agentforce can be expanded from a stronger foundation.
Should you start with Agentforce technology or a business problem?
Start with the business problem.
A common mistake with emerging technology is to decide to implement it before deciding what it needs to improve.
Agentforce should not be the objective in itself.
In Sweet Potato Tec’s experience of Agentforce initiatives, successful implementations need to be anchored in a clear strategic objective. We group those objectives into three areas:
Efficiency: reducing manual effort and operational friction.
Effectiveness: improving revenue outcomes and decision-making.
Experience: improving customer or employee interactions.
These provide a useful first filter for potential use cases.
Ask where your organisation currently loses time. Where are people repeatedly completing low-value tasks? Where do leads or customer requests wait unnecessarily? Where does poor access to information slow decisions? Where are employees constantly answering the same questions?
Those problems give you something concrete to investigate.
“Implement Agentforce for sales” is too broad.
“Reduce the time salespeople spend manually qualifying and researching inbound leads” is much closer to a usable business case.
The technology comes afterwards.
Where should you look for potential Agentforce use cases?
Look for repetitive, high-volume work where people repeatedly gather information, make relatively well-understood decisions, route requests, respond to common questions or complete predictable actions.
Sweet Potato Tec’s Agentforce proposition identifies several problems that commonly appear in sales and service teams: response delays, inconsistent messaging, repetitive low-value work, difficulty scaling workflows and poor visibility into bottlenecks.
These are useful places to investigate because they can reveal work that is consuming human capacity without necessarily requiring human judgement at every stage.
Speak to the people actually doing the work.
Ask questions such as:
- Which tasks do you repeat most frequently?
- What do customers or colleagues ask you again and again?
- Where do requests regularly wait in a queue?
- What information do you repeatedly search for?
- Which tasks require copying or summarising information from Salesforce?
- Where do leads, cases or requests need manual categorisation?
- Which activities prevent experienced staff from spending time on more valuable work?
The objective is not to produce the longest possible list of AI ideas.
It is to find a small number of processes where an agent could perform a clearly defined job.
What types of work are particularly suitable for Agentforce?
Processes with repeatable inputs, defined actions and clear boundaries are usually easier to assess as Agentforce candidates than vague or highly subjective responsibilities.
Salesforce Agentforce is built around capabilities that define what an agent can handle, instructions that guide its behaviour and actions that allow it to retrieve information or perform tasks. Salesforce documents actions as executable tasks that can, for example, call Salesforce Flow, prompt templates or Apex.
That gives organisations a practical way to think about a potential use case.
Can you describe the agent’s job clearly?
Can you define the information it needs?
Can you identify the actions it should be allowed to take?
Can you explain what it should do when the normal process does not apply?
Can you identify when a human should take over?
If the answers are clear, the process may be a useful candidate.
If the proposed role is essentially “understand everything happening in the business and decide what to do”, the scope needs more work.
What are some practical Agentforce use cases?
There is no universal best Agentforce use case, but Sweet Potato Tec currently identifies four common starting points within its Agentforce Quickstart.
Customer Support Agent
A Customer Support Agent can handle inbound enquiries, respond to common issues using an organisation’s knowledge and escalate to a person when necessary.
This may be worth investigating where support teams spend substantial time answering repetitive questions or where routine enquiries create delays for customers with more complicated problems.
The important question is whether the common enquiries are sufficiently understood and whether the agent has access to reliable information from which to respond.
Sales Development Agent
A Sales Development Agent can support early-stage sales activity such as lead qualification, initial responses, meeting booking and surfacing relevant account information.
This can be useful where salespeople spend significant time on the groundwork surrounding a sales conversation rather than the conversation itself.
Sweet Potato Tec’s wider guidance on embedding Agentforce into an organisation also identifies lead qualification as a revenue workflow where Agentforce can be applied.
The use case still needs boundaries. Organisations should define what constitutes a suitable lead, what information Agentforce can use and when a salesperson needs to become involved.
Knowledge Agent
A Knowledge Agent helps employees find information from organisational documents and knowledge sources without repeatedly raising internal queries or searching across different locations.
This can be particularly useful where experienced employees spend substantial time answering the same internal questions.
A knowledge use case may also offer a controlled way to build internal experience with Agentforce before exposing an agent directly to customers.
Case Routing Agent
A Case Routing Agent can categorise incoming cases and route them according to factors such as type, priority or customer profile.
This is a useful example of a narrowly defined operational use case.
The agent is not being asked to run the entire service function. It has a specific responsibility within a wider process.
That is often a better starting point for Agentforce than trying to automate an end-to-end workflow immediately.
Should your first Agentforce use case be internal or customer-facing?
The answer depends partly on the risk associated with the process.
Sweet Potato Tec recommends considering the blast radius when deciding between internal and external AI agents.
An internal agent works inside the organisation and supports employees. An external agent interacts directly with customers or prospects.
The consequences of an error can be different.
If an internal agent gives a salesperson an imperfect summary, an employee may be able to recognise and correct it before anything leaves the organisation. If a customer-facing agent provides incorrect information directly to a prospect, the consequences may be more significant.
That does not mean organisations should always begin internally.
It means risk should form part of the use-case decision.
Ask who will interact with the agent, what information it will handle, what actions it can take and what happens if it gets something wrong.
A high-value use case with a very large potential impact from errors may still be suitable for Agentforce, but it may not be the best first use case.
How important is data when choosing an Agentforce use case?
Data is one of the most important feasibility tests.
An attractive use case can quickly become a poor first choice if the information the agent needs is unreliable, inaccessible or spread across systems that are not yet ready to support the proposed workflow.
Sweet Potato Tec makes this explicit within its Agentforce Quickstart. Data readiness is assessed during the engagement and gaps are addressed before go-live because the reliability of the agent depends on the information behind it.
This means use-case discovery and data discovery need to happen together.
Suppose two possible use cases offer similar potential value.
Use case A depends almost entirely on well-maintained Salesforce records and an established knowledge base.
Use case B requires information from several disconnected systems, relies on inconsistent manual data and requires a new integration before the agent can complete its task.
Use case B may eventually be more valuable. But use case A may be the better first deployment because it offers a clearer route to production and learning.
The right use case is therefore not simply the process with the biggest theoretical benefit.
It needs to be feasible with the organisation’s current foundations, or valuable enough to justify improving those foundations first.
Should you choose the use case with the biggest potential return?
Not automatically.
Business value matters, but it needs to be considered alongside feasibility, risk and implementation complexity.
A useful way to compare Agentforce opportunities is to ask four questions:
Value: If this works, what meaningful business outcome improves?
Feasibility: Do we have the data, Salesforce architecture and process clarity needed to make it work?
Risk: What happens if the agent makes a mistake or encounters an exception?
Measurability: Can we tell whether the deployment has actually improved the process?
This prevents organisations from selecting a use case solely because it sounds impressive.
A relatively simple process that happens hundreds of times each month may produce more useful evidence than a sophisticated agent attempting to automate a rare, complicated decision.
Sweet Potato Tec’s Agentforce Quickstart intentionally focuses on one use case. The purpose is to get a production-ready agent handling real work before expanding into additional agents or broader coverage.
How do you know whether a use case is too broad?
If you cannot describe the agent’s responsibility in a few clear sentences, the use case may need narrowing.
Broad ambitions often contain several separate jobs.
“Automate customer service”, for example, could involve identifying customers, answering knowledge questions, retrieving account information, changing records, processing requests, routing cases, escalating complaints and communicating across multiple channels.
Those are not necessarily one use case.
Breaking a broad objective into smaller jobs makes it easier to understand the required data, actions, instructions, risks and success measures.
Salesforce’s own Agentforce architecture reflects this need for defined responsibilities. Agent capabilities are organised around specific jobs, with instructions guiding behaviour and actions providing the tools required to perform those jobs.
For a first implementation, controlled scope is valuable because it gives the organisation a clearer way to test whether the agent behaves as intended.
How should you prioritise several good Agentforce use cases?
Prioritise the use case that provides a useful combination of business value, implementation feasibility, manageable risk and measurable outcomes.
A simple prioritisation exercise can help.
For each candidate use case, document:
The problem: What is currently going wrong or consuming unnecessary time?
The user: Who would interact with or benefit from the agent?
The volume: How frequently does this work occur?
The current effort: How much human time does it consume?
The data: What information would Agentforce require and where does it live?
The action: What exactly should the agent be allowed to do?
The exceptions: When should a person take over?
The risk: What are the consequences of an incorrect response or action?
The outcome: What should improve if the agent works?
The measurement: What evidence will demonstrate that improvement?
This creates a much more useful comparison than a brainstormed list of AI opportunities.
At Sweet Potato Tec, our Agentforce Quickstart begins by mapping use cases, workflows and constraints precisely because suitability needs to be assessed before configuration begins.
How should commercial impact influence the decision?
Commercial impact should help prioritise use cases, but it needs to be tied to a real workflow.
Sweet Potato Tec’s guidance on embedding Agentforce into your organisation recommends looking at workflows with a direct connection to business performance, including lead qualification, opportunity insights and case resolution.
That approach helps prevent AI strategy becoming detached from operational reality.
For example, improving lead qualification may allow salespeople to spend more time on the opportunities most worth pursuing. Improving case resolution may reduce operational pressure while improving the experience for customers. Better access to opportunity information may help teams identify risks earlier.
The precise value will vary by organisation.
What matters is that the use case can be traced from the agent’s activity to an outcome the organisation actually cares about.
How do you define success before building the Agentforce use case?
Decide what should change if the agent works as intended.
This needs to happen before configuration.
If the objective is efficiency, the organisation might measure manual workload, handling time or the volume of repetitive tasks requiring human intervention.
If the objective is effectiveness, the measure should relate to the relevant business outcome.
If the objective is experience, identify an appropriate measure for the customer or employee interaction being improved.
Do not select metrics simply because Agentforce can report them.
Return to the original problem.
If employees are spending too much time finding internal information, measure whether that burden changes. If routine cases are creating a backlog, measure the relevant change in workload or resolution process. If slow initial lead handling is the problem, measure what happens to that process.
This makes the use case accountable to the reason it was selected in the first place.
What should you do once you have selected the first Agentforce use case?
Once the use case has been selected, move from prioritisation into detailed discovery.
Define exactly what the agent needs to do, which data it requires, which Salesforce processes it depends on, what actions it can take, what instructions and boundaries are required, how exceptions should be handled and how the agent will be tested.
This is where use-case selection becomes implementation design.
Sweet Potato Tec’s Agentforce Quickstart moves from needs assessment into setup and configuration, data integration, training and enablement, and post-go-live support.
SPT’s wider Agentforce service similarly covers governance, structured testing and user enablement alongside defined AI use cases.
Do not immediately move on to planning agents two, three and four.
Put the first use case into practice. Observe how it behaves. Listen to the people using it. Refine it where necessary. Establish whether the expected value is appearing.
Then use that evidence to decide what comes next.
FAQs
What is a good first Agentforce use case?
A good first use case solves a meaningful but clearly defined problem, involves repeatable work, has reliable data available, presents manageable risk and has an outcome that can be measured. Sweet Potato Tec commonly works with starting points such as Customer Support, Sales Development, Knowledge and Case Routing agents.
Which business processes should not be automated with Agentforce?
Processes should be treated cautiously where the required outcome is poorly defined, the underlying process itself is inconsistent, necessary data cannot be trusted or accessed, or the consequences of an error cannot be managed through appropriate controls and human oversight. The answer depends on the specific organisation and process rather than a universal list of prohibited use cases.
Should we start with an internal Agentforce agent?
An internal agent can be a useful first deployment where an organisation wants to limit the impact of errors while developing practical experience with Agentforce. However, an external agent may still be appropriate where the use case, data, controls and escalation routes are sufficiently well defined. The decision should reflect value and risk rather than a blanket rule.
Can Agentforce automate a process across several systems?
Agentforce can use actions and connect with wider processes, but cross-system complexity affects the scope and feasibility of an implementation. Sweet Potato Tec’s Quickstart excludes complex multi-system integrations beyond the existing Salesforce setup from its standard scope and would assess those requirements separately.
How many Agentforce use cases should we identify?
It can be useful to identify several opportunities during discovery, but you do not need to implement them all at once. Sweet Potato Tec recommends beginning with one focused, high-value use case and expanding after the first agent is working.
How do we know if our chosen Agentforce use case is working?
Define the success measure before implementation. The appropriate metric depends on the problem being solved, but it should show whether the process has materially improved rather than simply whether people are interacting with the agent.
Choose a problem worth solving, then prove Agentforce can solve it
The best Agentforce strategy does not begin with a long list of places where AI could theoretically be used.
It begins with a real organisational problem.
Look for repetitive work, operational friction, slow access to information and processes where employees are spending time on tasks that can be clearly defined. Then assess each opportunity against business value, data readiness, feasibility, risk and measurability.
From there, choose one use case with a clear job to do.
At Sweet Potato Tec, we have rolled out multiple agents across our client ecosystem, and our approach is deliberately practical. We start with the business objective, identify a focused use case and establish the data, workflows and boundaries needed to make it work.
Our Agentforce Quickstart is built around exactly that principle. Rather than attempting a broad AI transformation from day one, we identify one high-value use case, configure and test it within the existing Salesforce environment, put it into production and then use the experience to inform what comes next.
The question is therefore not simply, “Where could we use Agentforce?”
It is: “Which problem is valuable, feasible and controlled enough for Agentforce to solve well, and how will we know when it has?”
That is the use case to start with.