Agentforce projects struggle when the business starts by choosing an agent before it has defined the work that agent needs to do. Start with the revenue process, find where it slows down or leaks, then give the agent a clear job, trusted data and the controls that keep a person accountable.
When I speak with teams about Agentforce, I begin with the revenue process. Where does work slow down? Where does a customer wait for an answer? Where does revenue get missed because somebody has to check a dashboard, search another system or complete the same task by hand?
Once that problem is clear, we can define the agent’s role, the information it needs and the controls that must stay in place.
Revenue operations is a strong place to start because products, pricing, contracts, orders, billing and usage are connected. An agent working inside that process can use commercial context that already exists. The harder part is making sure the data is accurate and the agent is embedded in the way people already work.
Start with the job the agent needs to do
When a business tells me it wants to deploy Agentforce, my first question is rarely which agent it wants to build.
I want to understand where the process is already breaking down.
Think of an Account Executive who checks several dashboards each morning to find customers approaching their usage limits. The process relies on that person noticing the right account at the right time. When the Account Executive is busy or unavailable, nothing happens.
The same issue appears across the revenue cycle. A support employee may have to search several records to explain an invoice. A salesperson may leave a customer conversation to find a product or prepare a quote. A catalog manager may spend hours writing descriptions for products that already have structured attributes.
These are useful starting points because the work is visible and the cost can be measured.
The business can define what happens today, how long it takes and what frequently goes wrong. The agent then receives a clear job.
Revenue is already one connected process
Revenue may be divided across Sales, Deal Desk, Legal, Operations and Finance, but the underlying process is connected.
A product enters a quote. The quote informs the contract. The contract shapes the order. The order affects billing. Usage can trigger an overage, an amendment or an expansion conversation.
An agent working in one part of that chain needs access to what happened before it.
A Quoting Agent needs approved products, prices and discount rules. An Invoice Explanation Agent needs the customer’s order, allowance and rated usage. A Consumption Agent needs to understand how much the customer has used and what they are entitled to consume.
During the January webinar, David Beebe described the friction created by disconnected tools, spreadsheets and manual handoffs as the “messy middle.” That is where a revenue process slows down and where customers begin to feel the effect.
Agentforce Revenue Management gives agents access to the same commercial process used by the people responsible for revenue. That shared context reduces the need to rebuild the customer story every time an action is required.
Trusted data comes before agent autonomy
Revenue data has to be right.
A customer can challenge an invoice. A discount can affect margin. A contract change can create a financial commitment. The agent cannot treat these records as background information.
David made this clear during the April session. Revenue data must be accurate, secure, compliant and subject to the controls already used by the business.
An Agentforce implementation often reveals data problems that have existed for years. Product names may differ between systems. Entitlements may be difficult to match with usage. Discount rules may sit in documents or in the heads of experienced employees. Account ownership may be unclear.
The agent inherits those problems.
Before activation, I would confirm:
- which system owns each piece of data
- how frequently the information is updated
- which rules the agent must follow
- what the agent can recommend or update
- where a named person must approve the action
A useful test is to ask whether an employee could make the same decision using the available information. When the answer is no, the data or process needs work before an agent is given the task.
What we demonstrated in the January session
In January, I demonstrated several agents working across the same revenue process.
The first scenario involved a catalog manager with more than 50 products that had no useful description. The Catalog Agent used the product’s existing attributes to prepare draft copy. The catalog manager reviewed it and approved the update. The agent removed the work of starting with a blank page. The person responsible for the catalog remained in control of what the customer would see.
We then moved into quoting. A salesperson asked the Quoting Agent to create a quote for 100 servers with a 10 percent discount. The agent found the relevant opportunity and product, built the quote and applied the adjustment.
The final scenario focused on billing support. A customer wanted to understand an invoice charge. The Invoice Explanation Agent found the included allowance, identified the quantity consumed above it and explained the rate applied to that overage. It then drafted an email for the support employee to review.
Each agent had a defined role. Each one used existing revenue data. A person stayed involved where review or judgment was needed.
Keep the agent inside the flow of work
An agent becomes harder to use when employees have to leave their normal process to find it.
I see stronger adoption when the agent is embedded where the work already happens. The Account Executive receives the opportunity in Salesforce or Slack. The support employee asks for the invoice explanation from the customer record. The salesperson prepares the quote during the conversation.
This matters because even a capable agent creates friction when users have to open another tool and rebuild the context.
During the April webinar, I described agents inside the flow of work as more useful to the organization because they solve the need at the point where it appears.
The process should feel continuous. The agent starts the work. The employee steps in when judgment is required. The customer receives the outcome through the appropriate channel. That is what I mean by revenue orchestration.
Treat the agent like an employee
I often compare an agent with a new employee. The business needs to define the job first.
Sales Operations or Order Operations should explain what the agent is expected to do, which information it should use and when it needs to hand the work to somebody else. The Salesforce administrator can then build the agent and apply the relevant permissions and guardrails.
The business remains responsible for the result.
During the April discussion, I described this as giving the agent a job specification. The agent may work continuously in the background, but governance does not disappear because the worker is digital.
You would not hire a person without defining their responsibilities, access and escalation path. An agent needs the same clarity.
Humans still own commercial judgment
Salesforce summarized the principle well: Agents automate. Humans lead. Revenue flows.
The level of human involvement should reflect the risk of the action. A draft product description may need a quick review. A standard quote may follow established pricing rules. A nonstandard discount may need approval from Deal Desk or Finance. A contract amendment may require Legal.
The agent can prepare the action and reduce the manual work around it. Accountability remains with the people who own the process. This becomes especially important when an agent can affect what a customer pays or what the business commits to deliver.
The approval model should be designed before the agent goes live.
Choose one workflow that matters
The first use case should be focused enough to test and important enough to justify the work.
I would start by mapping the current revenue process and marking the points where people wait, search for information or repeat manual tasks. Useful questions include:
- Where are customers waiting for a response?
- Where does revenue get delayed or missed?
- Which task follows a repeatable set of rules?
- Where do errors create disputes or rework?
- Which process already has a clear owner?
- What outcome can we measure before and after activation?
The answer may lead to a Consumption Agent, Quoting Agent or Invoice Explanation Agent. It may also point to an internal task such as maintaining the product catalog.
The first implementation does not need to cover the full revenue cycle. It needs to prove that the data, process and governance model work.
Measure the business result
The number of agents deployed is not a useful measure of value on its own. A business should track what changed.
For a quoting workflow, that may include preparation time, approval time and error rates. For billing support, it may include response time, repeat contact and disputes. For consumption, it may include expansion revenue and the time between detecting an overage and sending a quote.
During the April webinar, we discussed expansion velocity, overage conversion and revenue captured through agent-supported activity. These measures allow leaders to answer practical questions. Did the process become faster? Did the customer receive a clearer answer? Did the business capture revenue that it previously missed? Did employees spend less time searching and preparing?
That is how an Agentforce project moves beyond a demonstration.
- Define the business problem before choosing the agent.
- Give the agent a clear job, access model and escalation path.
- Use accurate, governed revenue data.
- Embed the agent in the tools and processes employees already use.
- Keep people accountable for pricing, contracts, billing and customer commitments.
- Start with one workflow and measure the result before expanding.
Related questions
How do you make an AI agent accurate? +
Give it access to trusted, governed data and define which sources it is allowed to use. Add clear instructions, permissions and approval points. Test the agent with real revenue scenarios, including incomplete records and exceptions.
Should you deploy agents all at once? +
No. Begin with one workflow that has a clear owner and measurable outcome. Use that implementation to test the data, controls and operating model before expanding.
Why is revenue management a strong place to start? +
Revenue processes already use structured data such as products, pricing, contracts, orders, billing and usage. That gives the agent commercial context and a defined process in which to operate.
How much autonomy should an agent have? +
The level of autonomy should match the risk. Drafting and analysis may need a simple review. Actions affecting price, customer charges or contractual commitments should pass through stronger approval controls.
Who should own an Agentforce agent? +
The business team should define the role and expected outcome. Salesforce administrators usually manage the configuration, access and guardrails. The process owner remains accountable for how the agent performs.
What makes an Agentforce implementation successful? +
A successful implementation changes a measurable business result. That may be faster quotes, fewer billing disputes, earlier expansion conversations or less manual work for employees.
Tunde leads strategy at PhiX and has spent his career close to the Salesforce platform, from engineering to enterprise revenue transformation.
Connect on LinkedIn →See where an agent will actually pay off.
Start with a Revenue Infrastructure Review, or an Agent Activation Plan, and leave with a prioritized roadmap.
Book a Revenue Infrastructure Review