How to Measure and Drive ROI for Agentforce | Case Study | Dreamforce 2025

Good morning everyone. I'm super excited to be here. I am Yazi Peng, VP of Go to Market Operations at Pendo and I'm here today to talk about how to think like a product manager. Redefining RevOps for the AI era. So many of you here probably have either been in RevOps or have worked closely with RevOps for years and you've probably seen firsthand just how much the function has changed. In my mind There have been two major stages of robots. Robots 1.0 was basically sales ops. It was all around serving the immediate needs of the business, being order takers to sales to do things like doing reporting and quota setting and territory design and implementing process. In the last few years we've seen a much more modern take on on the role. RevOps 2.0 has been much more around being proactive, strategic thought partners to the business and really being focused on that full customer journey from the very first marketing touchpoint all the way to the product upsell conversation. And as part of that there have been certain expectations that have been placed on RevOps. So we're often seen as the science part of the art and science of selling. And as part of that we're expected to drive to 100% rep compliance on the processes that we roll out because we want to drive that scientific approach. And the way that we've had to do this historically is by buying and implementing third party tools. But despite this great up leveling of RevOps, there are certain truths that we've come to accept. Feels like no matter what company you go to, there's this resigned state of oh man, the CRM data is never up to date, it's never perfect, it's not reliable, right? Or when you roll something out, it's like we don't know if reps are actually going to do this thing. Despite the hours and hours you spent trying to find that perfect single standardized process that would make sense for all the reps. Or when you do roll something out, it's often a black box. You have no idea whether reps are actually doing that thing or getting value from it. When we assess third party tools, we often have to find the version that is good enough for a business, even if it doesn't exactly fit our exact businesses needs. And a lot of the process that we do build is based on static rule based workflows that don't actually adapt to what we need. And so basically we find ourselves in this situation where Rev Ops is seen as the science people, but we find ourselves in a situation where we have shockingly limited tools to actually drive that scientific approach. And so somewhere along the way we've come to just accept the fact that this is just the way things are. But now enter RevOps 3.0. With the power of AI, we've now entered an age where we can be builders. And that is a massive unlock. So not just being the historical buyers and implementers of software and having to just accept whatever solutions are out there, we can actually go out and build now. So imagine a world where we can discard those accepted truths. Sales is always talking about meeting the customer where they are, but what about meeting the end user where they are? The end user in our case being reps and sales leaders and CSMs and BDRs and SES. Right. With vibe coding tools and AI native workflow builders and powerful chat based tools like AgentForce, we're now entering a world where we can have processes that are both hyper specific and custom. So for example, imagine a world where we have real intelligence around processes like lead routing, where instead of having to be focused on static account based ownership, we could actually route leads based on really dynamic factors like rep capacity at that time or that rep success with converting that type of lead in the past. Right. Those things are now possible because we can build processes that are not just custom to our business, but also to our specific end users. I personally had this reckoning several months ago when I first played around with a Vibe coding tool myself. And I'll admit that prior to this, I was pretty skeptical of a lot of the AI hype out there and had seen a lot of AI roadmaps and a lot of it to me felt like shiny bells and whistles that wouldn't actually fundamentally change the way that my team did things. But the first time that I built the front end of my first app, that was the aha moment that opened up a world of possibility for me. So I challenged my team to step into that new world. Historically, the way that we thought about taking demos was, okay, let's first be really clear about what's the pain point that we're trying to solve for. Let's figure out what tools out there in the market could potentially solve that pain point and then let's go out and demo those tools. We basically tried to flip that on its head. We said, let's go out and just demo everything from the lens of the art of the possible. What are the new ways of working that we're not even aware of? We basically tried to really challenge ourselves with that mindset of being stuck in the practicalities of how we knew things were being done. Some of these tools that we looked at were tools that we were already using and we were exploring their new AI capabilities. But a lot of these tools were tools that we had never heard of. And this was all around how do we challenge ourselves and honestly get a little bit uncomfortable and practice that are the possible mindset. And I'll admit it was a bit of a roller coaster. I don't know if this resonates with any of you, but certainly there is a lot of FUD and hype in the market right now. And I personally spent a lot of my time trying to parse through what's actually real, what's not real, what was actually worth my team's time. And there were certainly a lot of ups and downs through this journey. As part of this exercise, I also thought a lot about how to upscale the existing team. We did our first ever gtmops hackathon where we played around with tools like Lovable and suvabase just to see what we could build in a day. It was really cool seeing people's aha moments when they tried to build new things like a book building tool or even a pricing calculator, things that wouldn't have been possible even several months ago, and seeing that really open up the art of the possible. Thinking across my team and the big question for me that I was asking myself was, what is the new level, new minimum level of AI fluency that was needed across my organization? Another thought exercise that I went through was I sat down with my leadership team and we asked ourselves the question, if we had unlimited AI budget but we could only hire five people, what would those five people look like? And to be clear, I think we're very far away from being able to run a gtm ops Org with just five people. But it was a helpful theoretical exercise for us to go through to understand what were the capabilities that we needed to bring onto the team. And as part of this journey, we came up with a few North Star principles. We knew that we wanted to be really intentional about how we were deploying a lot of these new technologies and processes to the revenue organization. Because as all of you know, just because you can do something doesn't mean you should do it. So a few different principles we thought about. Number one, start with the known. It's really easy to get excited about all the shiny new things that you can build, but we knew that there were a lot of manual, repeatable tasks that were happening across the organization that we needed to stop doing so things like manual account research or the manual creation of key selling assets like joint value plans, we wanted to make sure that we're actually starting with the known problems first. Secondly, we wanted everyone in revenue to be as self serve as possible. And so that meant building out the self serve infrastructure. Part of how this played out for us was we actually moved off of our existing BI tool and moved onto one that was a lot more democratized and self serve oriented in its approach. Number three, keep the tech stack simple. We all know here that it is obviously a lot of work mind share to get reps to learn a new tool. And so we wanted to make sure that the bar of bringing in a new rep facing tool specifically was really, really high. And we saw our role within RevOps as building around the core tools that reps used. Number four, given how fast everything is changing, time to value is king. We actually only sign one year contracts now because we have the perspective of we don't even know what things are going to be right for us, for the business a year from now. It's just changing that fast. And so that puts even more onus on these new tools that we were bringing in to get to value really, really quickly. Number five, challenging the 100% compliance mindset with how quickly RevOps can now build certain processes. Maybe it's actually okay if we roll something out and only 10 reps use that thing, as long as those 10 reps are getting a ton of value from it. We realized that in the past we actually stopped ourselves from rolling something out because we had this defeatist mindset of it's going to be impossible to get reps to actually fully adopt this thing. So we actually wouldn't just not even do it. And so we wanted to challenge that thinking. And then lastly, we had way too many areas in the business where one person had all the knowledge about a certain thing. So we did things like build custom GPTs where to make sure that that knowledge wasn't bottled up in one person anymore. So for example, we built an ROE bot. Another way that this played out was that when a person left the business as part of their off boarding process, we actually had them build their own custom GPT where they put in all of their knowledge about the business, what they were responsible for, so, so that we could actually ask that GPT the questions that we would have typically asked that person. And most importantly along the way we did realize that we had some gaps, two major gaps that we saw. One, we Had a talent gap. So even with the ease of a lot of these new AI powered tools, it still requires a certain building skill set and a certain level of curiosity. And so we hired two GTM engineers and one pipeline engineers to help us with this. Us. Secondly, we realized that we didn't have a good process for thinking about how to build. We didn't have a rigorous, repeatable process on the building itself. So this is where we borrowed a framework from our friends over on the product side, the software development life cycle. It's basically an iterative process that would allow us to make sure that we're not only building the right things, but building really thoughtfully along along every step of the journey. There are a lot of things that we've built or in the process of building using this framework. But today I'm going to cover one very simple but powerful case study, and that's AgentForce. So one of the many tools that we demoed in our demo frenzy was AgentForce. And it was very immediately clear to us just how powerful this tool could be for us. So we decided to apply our new SDLC framework onto our internal rollout of AgentForce. We decided to start with an employee use case. On average, we get 4,300 cases a quarter that ops has to manually sift through and resolve things like manually updating records or making commissions adjustments or handling basic account changes in our CRM. And we knew that Agent force could help us improve our speed to resolution on these most common Salesforce cases and also minimize the amount of time that the team was spending on actually resolving these. So first we started with the plan phase. We pulled all the Salesforce cases we had gotten in recent quarters. We asked our friend ChatGPT to categorize them to understand what case types were the highest volume. In the same way that a PM would do research to understand their customers needs, we did the initial legwork of understanding what the unmet need was. Next, we did some internal discovery. We did a ton of interviews with reps and dug further into the case detail from the plan phase. Using that PM mindset of deep discovery, we tried to put ourselves in the shoes of our reps for a day. Why were they submitting these cases? What were their pain points? What were they looking to accomplish next? We design a pilot. So every product lifecycle is meant to be iterative and it's all about experimenting fast. And so this is the step where we effectively wrote down our product requirements. We identified four initial case types to roll out to the small pilot group and a Big part of this design was defining what success looked like and what were the business outcomes that we were trying to solve for. So for us, our success criteria was improving speed to resolution and improving accuracy and compliance of commissions and account related updates. And then also doing this in a way that was hyper rep friendly. And then we built out v1 of Agentforce. One workflow that we started with was a really simple one, but one where we get a lot of volume account merges. And so now a rep can actually go into the chat and say, I want to merge this account with this other account. And basically the logic that we built in the backend checks a bunch of things to make sure that that actually makes sense to do. For example, making sure that that user has the permissions to do so and making sure that merging those two accounts won't impact any of our core KPIs. And then it just does it in front of the rep, does it real time. It's very simple, but so powerful. Now this is where things get really fun. Now we've built a working pilot and we needed to test that it actually works. This is where we used Pendo's Agent analytics to continuously improve the experience. What Pendo's Agent analytics does is it actually gives us granular visibility into how reps are engaging with the agent. We can see the actual prompts that users are entering in, and it also tracks and categorizes all these prompts so that we can see what types of prompts are the most common and we can see what users are trying to achieve. These agent insights actually highlighted new opportunities for new case types that we could roll out with AgentForce. And it also made our implementation process way better. For example, there was a very specific situation where we noticed that a rep actually missed the case hyperlink that was generated by AgentForce and so immediately changed the messaging within AgentForce itself to make that hyperlink way more clear and actionable for subsequent interactions. This is basically a very precise, closed loop way to understand deeply whether your agent is actually doing what you want it to do. And as you can imagine, there's a lot of iteration between these last three steps. Design, build and test. All right. And then after a successful pilot, we were ready to ship. So we launched this to 250 plus reps and BDRs. Part of our launch was that we used Pendo guides to redirect users based on what they were trying to accomplish. So if a user actually tried to submit a certain case type through the traditional standard flow within Salesforce, Pendo guides would actually redirect them to the employee agent within AgentForce. Historically this is the type of process where we would have had to try to force fit a one size fits all solution and just hope for 100% rep compliance. We would have had to try to say hey Rep, please enter in this case detail in exactly this way, in exactly this manner. Right? But instead now with the chat based capabilities of AgentForce, the continuous feedback loop with of Pendo's agent analytics and the meet the user where they are nature of Pendo guides, we can actually create a process that's customized to that rep's needs, guides them through their unique flow and gets them exactly what they need at the time they need it with real time guidance and resolution. This use case for AgentForce was simple but has been really powerful for us and it's already resulted in hundreds of hours of saved time for ops and reps across Pendo. All right, what's next for RobOps 3.0? So I am obviously biased, but I think that the role of RobOps is gonna continue to be elevated. I think the way that we've historically thought about workflows is all around who is the person doing that task and increasingly it's gonna be around jobs to be done. So instead of thinking about it in terms of a marketing workflow versus an AE workflow versus a BDR workflow, it should be about the pipeline workflow. And I think that increasingly the lines across all these go to market functions are going to get blurred and RevOps is uniquely positioned to understand and solve for all these go to market jobs to be done. As part of our new job as being both buyers and builders, we'll also have the responsibility to figure out what should be spoon fed to the organization versus what should be self served because it will be a balance of those two. And again, we're uniquely positioned to have a perspective on how to do this and how to operationalize this with this next evolution of RevOps. Adopting this PM Builder mindset is only going to accelerate Revops critical role in this age of AI. That's it for me again. I'm Yezi from Pendo. Please come visit us at booth 320 at the campground and would love to chat more after this. Thanks so much.