Start with the process, not the agent. Find the point where somebody is waiting, searching or repeating the same task by hand, then give the agent that specific job. Define the data it needs, where it sits in the working day, how much it is allowed to decide on its own and the number you expect to move.
The aim is not maximum autonomy. It is the right level of autonomy for the task, placed where the work already happens.
01What problem are you actually solving?
Nobody decides to miss the revenue. That is what makes it worth fixing.
The usage data already exists. It sits in a dashboard an Account Executive is meant to check between calls, alongside everything else in their day. When they are busy or away it does not get checked, and the first anyone hears about it is an overage on an invoice the customer did not expect.
That is a job for an agent. Not because agents are interesting, but because the work is repetitive, the rules are knowable and the cost of missing it is measurable. We walk through that specific workflow end to end in turning usage signals into expansion revenue.
The same shape shows up right across the revenue cycle. A support colleague opens four records to explain one invoice line. A salesperson leaves a live customer conversation to go and build a quote. A catalog manager writes descriptions by hand for products that already carry every attribute needed to write them.
These make good starting points because the work is visible. You can say what happens today, how long it takes and what usually goes wrong. That gives the agent something specific to do.
When somebody tells me they want to deploy Agentforce, my first question is not which agent they want to build. It is where the process is already breaking down.
02Where should the agent sit?
An agent that people have to go and find is an agent people stop using.
Adoption improves when the agent turns up inside the working day rather than beside it. The AE opens their inbox and the opportunity is already there, with the customer named and the threshold breach explained. The support colleague asks for the invoice explanation from the customer record they already have open. The salesperson builds the quote during the call, not after it.
The phrase for this now is revenue orchestration, and the flow is straightforward. The agent starts the work. A person picks it up where judgment is needed. The customer completes something. Everyone is happy.
That only holds if the agent meets people where they already are, whether that is Salesforce, Slack, an inbox or a mobile notification. A capable agent in the wrong place still costs the user a context switch, and the context switch is most of the friction you were trying to remove.
03Who gives the agent its job?
I find it useful to think of an agent as an employee.
The business team writes the job spec. Order Operations and Sales Operations are the ones who say what this particular colleague is for, what information it should use and when it needs to hand work to somebody else. Once that exists, the administrator builds it and sets the permissions and guardrails.
The governance framework does not go away because the colleague is digital. The rigor around what the agent should do and what the guardrails should be still sits with the people doing the configuration. The business still handles day to day operations. What has changed is that you now have a colleague who does not go to bed, who is working in the background and who gives you more value in your day.
There is a newer question here that is still being worked out, and it is worth raising early: who owns agent design from a consumption point of view. How many tokens does this agent use. How long does a query take to come back. What does it cost to run at volume. Those belong in the job spec too, alongside the functional requirements.
You would not hire a person without agreeing their responsibilities, their access and who they escalate to. An agent needs the same clarity, written down before it goes live.
04What data does the job depend on?
Revenue data has to be right.
A customer can dispute an invoice. A discount changes margin. A contract amendment creates a commitment the business has to honor. An agent cannot treat these as background reading.
Within revenue throughput the data has to be accurate, compliant, secure and subject to controls, because you are dealing with ASC 606, GDPR and GAAP. These are regulated processes, and the agent inherits whatever state they are in. That is why we treat trusted data as the work that comes first, not the clean-up afterwards.
The sequence I use is capture, enhance, enrich, then act. Capture what the customer has consumed. Enhance it with what they are entitled to, what tier they sit in and what they should be charged. Enrich it against the commercial record. Only then can the agent take an action on it.
An Agentforce implementation tends to surface data problems that have been tolerated for years. Product names differ between systems. Entitlements are hard to match to usage. Discount rules live in a document or in the head of somebody who has been there a long time. Account ownership is unclear.
- which system owns each piece of data
- how often it is refreshed
- which rules the agent must follow
- what it may recommend and what it may change
- where a named person has to approve
A simple test: could one of your people make this decision using only the information the agent will have? If the answer is no, fix the data or the process first. The agent will not fill the gap. It will inherit it.
05How much should the agent decide on its own?
Match the autonomy to the risk of the action.
A draft product description needs a quick read before it goes near a customer. A standard quote that follows approved pricing rules can move with far less friction. A nonstandard discount goes to Deal Desk or Finance. A contract amendment goes to Legal.
Some of it can run without a person at all. If a customer receives the offer, likes what they see and chooses to pay or move up a tier, that transaction can complete with no human involved. Extending that level of autonomy is where a lot of the business value sits. The human is doing the lead in and the check in, making sure the agent is doing right by the customer.
The point is that autonomy is a setting, not a philosophy. You set it per action, based on what happens if the agent gets it wrong. Design the approval model before the agent goes live, not after the first exception.
06How do you know it worked?
The number of agents you have deployed tells you nothing.
Revenue is one of the easier places to prove this, because the throughput is quantifiable. You can see change orders dropping. You can see incorrect invoices and disputes going down in volume.
For consumption work, the two I would start with are the overage opportunity conversion rate and the time between the overage being detected and the quote being sent. Expansion velocity, in other words. For quoting, look at preparation time, approval time and error rates. For billing support, look at response time, repeat contact and disputes. Getting these in front of the people who need them is a revenue intelligence problem as much as an agent one.
Then there is the one your CFO will care about most: expansion revenue captured through agent led activity. You are capturing more revenue without adding headcount. That is a straightforward conversation to have with a finance team.
Underneath all of it sits cash. Revenue is about getting the money in the bank. The stretch from closing the opportunity to the first invoice going out, and DSO coming down as a result, is a serious measure for any business. Invoices in hours or days rather than weeks.
Pick the measure before you activate the agent, and take the baseline while you still can.
07What does this look like in practice?
Three examples from the sessions, each one an agent with a defined job.
The catalog
A catalog manager at a demo business had more than 50 items with no description at all. Customers could see a product name and a product code and had to work out the rest. The Catalog Agent used the attributes already held against each product to draft the copy. The manager reviewed it and approved it. The agent removed the blank page. The person responsible for what the customer sees stayed in control of it.
The quote
A salesperson asked the Quoting Agent, in conversation, for a quote for a hundred units of a server at a ten percent discount. The agent found the opportunity and the product, built the quote and applied the adjustment. The salesperson stayed in the customer conversation instead of leaving it to go and build something.
The invoice
A customer queried a charge. The Invoice Explanation Agent identified the included allowance, the quantity consumed above it and the rate applied to the overage, then drafted the email for the support colleague to review and send.
None of these needed custom code. Agentforce Revenue Management exposes the core processes, product catalog, pricing and ordering, as invocable actions. That means you can build agents that trigger genuinely complex operations without writing and maintaining custom Apex, and extend the out of the box agents rather than replacing them. Start from a standard agent, then add the actions your business actually needs.
- Define the process problem before choosing the agent.
- Put the agent where the work already happens, not in a separate tool.
- Write the job spec in the business, build it in the platform, keep the guardrails with the administrator.
- Capture, enhance, enrich, then act. Fix the data before activation, because the agent inherits it.
- Set autonomy per action, based on the cost of getting it wrong.
- Choose the measure and take the baseline before you go live.
Related questions
What should the first Agentforce use case be? +
One workflow where people wait, search or repeat manual work, and where the outcome is measurable. Map what happens today, agree who owns the process and confirm the data is good enough for a person to make the same decision. Prove the data, controls and operating model on that one workflow before expanding.
Why is revenue management a good place to start with agents? +
Revenue processes already run on structured data: products, pricing, contracts, orders, billing and usage. That gives an agent real commercial context and a defined process to work inside, and it makes the result easy to quantify through deal velocity, disputes, invoice accuracy and DSO.
How do you make an AI agent accurate? +
Give it governed data and define which sources it may use. Within revenue the data must be accurate, compliant, secure and subject to controls, because processes like ASC 606, GDPR and GAAP already apply. Then test the agent against real scenarios, including incomplete records and exceptions.
How much autonomy should an agent have? +
Match autonomy to the risk of the action. Drafting and analysis need a light review. Anything affecting price, customer charges or contractual commitment needs stronger approval. Some self-service transactions can complete with no human involved, with a person handling the lead in and the check in.
Who should own an Agentforce agent? +
The business team writes the job spec, meaning what the agent is for, what data it uses and when it hands over. The administrator builds it and holds the permissions and guardrails. The process owner stays accountable for the outcome. Include running cost, token usage and query response time in the spec, not just function.
What makes an Agentforce implementation successful? +
A measurable change in a business result: faster quotes, fewer billing disputes, earlier expansion conversations, revenue captured without added headcount, or less manual work for your people. If nothing measurable moved, the agent was a demonstration.
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 Or see what this has delivered for other revenue teams.