SPEAKER_00 0:01

Welcome! You are listening to the CRM Success Show, where you will hear from CRM executives who have overseen some of the most interesting and complex CRM implementations. Your hosts, David Mossri and Kiro Whitey, will be bringing you real stories, real insight. Follow along on social media for updates on new episode releases, exclusive content, and much more. Enjoy the show and thanks for watching.

SPEAKER_02 0:27

Hey, so today we're talking with uh Brent Downey from the Director of Revenue Technology at Pushpay. So uh welcome, Brent. Thank you, guys.

SPEAKER_01 0:37

It's good to be with you.

SPEAKER_04 0:38

Good to see you. So, Brent, um, we always start our podcast if you've listened uh before, which I know you're gonna say all every single episode you've listened to. So um we always start with a very basic uh introduction to yourself, um, your background and ecosystem, um, and then a little bit about the company uh you are currently director at.

SPEAKER_01 0:59

Yeah, I haven't listened to every episode, but I have left listened to a number of them and they're great. Um yeah, no, it's great to be with you guys. Uh my Salesforce career is uh a long one. It feels weird to say about 16 years uh this year in 2026. Um started like most uh did as an accidental admin um in 2010 and uh fell in love with the ecosystem. I had no idea that there was actually an ecosystem around it. Um, and as an accidental admin, it was great to have uh a community to be able to rely on and um and experience that. Um and so fell into the admin world, um, absolutely loved it. Um I moved to a couple different companies to uh be in that admin position. Um, one company in particular, I was working with consultants to move um or deploy uh Salesforce to our global sales team and uh kind of got the consulting bug there and uh thought that that would be something that would be interesting at some point in my career. Um and after a couple of years of of doing system administration, I I thought let's take the leap and let's do some consulting. So I did uh consulting for um almost 10 years and um have since moved to uh to push pay, kind of back to the client side where um I'm running our internal uh group. We we're called Revenue Technology. Um we manage Salesforce at the hub and um slew of other products and integrations um that service our go-to-market teams.

SPEAKER_04 2:37

Fantastic. Um so you started out on the end user side, but still uh financial services, um, you know, and then you moved moved also from there into to manufacturing. So you got a bit of exposure to a couple of different industries. How did you end up at Shell Black? Was that like, you know, 2015? I mean, like you said, it wasn't really much of an ecosystem. That would have been one of the probably the first partners in with a niche at that time, maybe. So yeah, was that through um was that through like word of mouth or you did you apply in the traditional sense or yeah?

SPEAKER_01 3:09

So uh I became a Salesforce MVP in 2012 or 2013. Okay. Um, and that was through a blog, uh adminhero.com. And um Shell was a MVP, I think, the year prior uh to my joining. So um, if you are familiar with the Shell Black Whiteboard series at all on YouTube, um they are uh they're great, they're still up, and I would encourage you to take a look if you haven't seen them before. But um I knew Shell through the MVP program, through his whiteboard series, and I actually met with him to talk about starting my own firm and just some of the perils of starting a business and things to be aware of and look out for. Uh, we met at Dreamforce 2015, I think it was, or I think it was 2015. And um the funny thing is, I left that conversation. I was like, well, that was more of a job interview than a conversation of starting your own business. Um, so I ended up uh accepting an offer to work for him, and uh it was great. It was it was um one of my fears with moving to consulting was the amount of travel that a lot of the bigger agencies require. And I had a young family, we just started our family. I didn't really want to be away from home that much. And um Shell's organization is completely remote, you know, minimal travel. Um, so it really worked out, it worked out great, and then got great exposure to the consulting side of uh of um Salesforce. Um we were really heavy into financial services cloud. So when uh FSC came out, we already had a niche in uh financial services, particularly in wealth. And when FSC came out, we really saw the traction there. We we pounced on that and became self-proclaimed FSC experts uh and grew into that uh as well. So um spent a ton of time documenting best practices, understanding the FSC platform, and then deploying those for that clientele.

SPEAKER_04 5:10

Yeah, I mean I'm in Dallas, as you know, and um I was speaking to Maz uh a head of this call. Um, great, great brand from a from a Texas perspective. I mean, you know, people that I I know have worked there, good people, high quality. So um so so and you know, usually when somebody's at a business for almost 10 years, things must have gone well. Um in the consult on consulting, you know, and as an SI uh to be there that long. So I guess you had your desire for building a business within a comfort blanket of an existing kind of business uh as well. So best of both worlds.

SPEAKER_01 5:45

Yeah, it was great because it was uh you know you know, Shellbox is a small enough firm that um we all know each other uh from an employee perspective. Um I really had the opportunity to help build and scale the organization along with Shell through that time. Uh and so it was it was nice because I got the ability to kind of build a business without all of the intricacies of actually building a business.

SPEAKER_04 6:11

Yeah, without the headache, you can say it. Yeah, yeah, absolutely.

SPEAKER_01 6:14

Absolutely.

SPEAKER_04 6:15

Um so so you actually touched on uh the MVP piece that I wanted to ask you about. Um those that are in the ecosystem know about the MVP, um, you know, what what that kind of is and why it's there and what it is. But obviously 10 years ago that was very different. I didn't realize it was back in 1516. I thought it was more like 1819 that you you uh received that. So just just give us like what was that like? Tell us, you know, a little bit like did you did you know there was an MVP award? And did you I mean, I'm sure you're blogged because it was your personal interest versus hey, I'm doing it to get something out of it. But just tell us how that whole worked and when you found out, and do you think it's helped your career since and and that type of stuff?

SPEAKER_01 6:56

Yeah. If I recall correctly, I I believe the MVP program, the first class of MVPs was 2012. Um and I was aware as I grew in the ecosystem that it was there, especially in that first year or two. Uh, there was a lot of of um communication on social platforms and in the community forums uh related to that first class. There was kind of a really big push from Salesforce. So uh in a way, it kind of became a goal to become an MVP. I wasn't really sure how that would happen or what that would look like. Um I felt like that was something to strive for, but uh just I just didn't know how to how to do it. Uh I started blogging really for myself at first because uh as I was working in this manufacturing company, I was a six-month uh six months into my career as an admin, moved to this manufacturing company where we're deploying to 1200, 1300 users across the world. I'm learning, still trying to learn the platform, let alone some of the nuances of translation workbench and multi-currency and all these other pieces of the product that don't get touched very often. And I was running into issues where I'm not finding documentation on how to leverage or solve best, you know, solve these issues with these functions um and features. And so as I developed solutions or found things that worked, I thought, well, if I'm having trouble finding this content, others must be too, because I'm sure I'm not the only one. And so that's where uh the blogging came from. And then it began to pick up steam. And I thought, well, maybe this is the mechanism, you know, if if I get uh um the ability to become an MVP, maybe it's through admin hero. Um so that's that's really ultimately kind of where that came from. But you know, again, while it was a goal, it was never one of those things that I was doing explicitly to become an MVP. Uh, that just happened to be kind of the channel or the mode uh that I was able to get into the program. I think it's important for people to know that the MVP program is structured in such a way that it's really meant to reward those that are contributing meaningfully to the uh broader Salesforce community. And there are folks that have wrong motives trying to get into it from a career attainment perspective or uh, you know, some of the benefits. And so um there are some safeguards in place to ensure that those that are are being awarded uh that that particular um title are excluded if they're doing it really for personal gains. I think it's a lot harder now to not have that desire for personal gain there and and do things very intentionally to get into the program. Um when I got in, it was still very small. I think there was like 50, 75 MVPs. Um, I think globally now, if you include those that are in the Hall of Fame, like myself, which were the old-time retirees, uh, there's there's well over 200. So um, you know, the scale is much different now as well. But great program, certainly helped my career tremendously um and gave me a platform that I'm super grateful for to be able to contribute to the community and um engage in that way. It's been it's been really pretty cool.

SPEAKER_04 10:20

You you mentioned uh the blog as well, which we were gonna talk about uh but since you mentioned it, and I did see you reposted uh yesterday uh the blog. So I was gonna ask you, is it still there for people to read? Um and would would you say still current? Uh I know you you reshared the 90 things you wish you knew as a Salesforce admin. Um what would be the one thing? Let's slightly off topic, but we'll jump back on. But what would be the one thing you would uh one thing you wish you knew uh as a Salesforce admin starting out your career?

SPEAKER_01 10:49

Gosh, you're gonna test my knowledge on that article, which I wrote like eight years ago. Um I think if I was starting again, uh one piece of advice would be to um I don't die just dive into the deep end as quickly as possible. I it's almost I almost feel a little bit challenged with that because the product has changed so much uh since I started. I I happened to look at the release notes for the the uh year that I started as an admin. Chatter had just been released. That was the big release in that summer, summer 10. And the total release notes was like 152 pages. And now we're nearing like what 900 uh in a release. So there's just as an admin, there's so much that you're expected to do now, and then and your knowledge is expected to be so vast. Um, you just gotta start and you gotta you gotta dive in and consume as much content as you can uh to to make sure that you're running successful platforms.

SPEAKER_04 11:53

Yeah, as quick as possible as well. We're gonna come on to that in a second. Uh Matt, do you have a quick point you wanted to add there?

SPEAKER_02 11:59

Uh yeah, I was just saying that this is uh call it an epidemic across the entire IT industry, not just now. Um, and just to make a point of how fast things are changing, I think it was last week, maybe the week before, they actually retired the AI associate cert less than two years after it was released. Like, yeah, which is incredible. And their whole focus is AI at the same time. Right. Yeah.

SPEAKER_01 12:24

Yeah, it's it's it really is fascinating how quickly things are shifting. And and you know, obviously that's a combination on the Salesforce in the Salesforce ecosystem of acquisitions, product integration, um, and of course, you know, the rise of AI and how quickly that's being adopted, not just with Agent Force, but just you know, rise of AI tools for admins and developers and things like that that integrate to Salesforce and fundamentally kind of changing, I think, the expertise. Uh, you don't necessarily, I suppose, need to know all the specifics of Salesforce. I mean, Google did a really good job indexing help articles for a long time. AI is expanding on that, and now it can actually action for you. So as long as you've done, hopefully you're doing quick vetting of the results before you hit yes, go go build that. But um, certainly now the X level of expertise has shifted a bit to uh knowing how to leverage the AI platforms. I I still think you've got to have a good understanding of data model and best practices and things of that nature, because you'll very quickly ruin your system if you let AI just do all those pieces. But uh that that knowledge transfer has begun for sure.

SPEAKER_04 13:32

Well, if uh anyone's curious what the other 89 things are um that you that they wish uh you knew, uh head over to your admin hero uh blog. I I had a quick skim through and uh F2 Disagree is probably the one that resonates with me the most, right? So um, you know, being hired for a reason, don't be afraid to speak up. So um it's good. Um so so what about uh push paid? So you're 11 months into this role of senior senior director, revenue technology. Um let let our listeners know what push pays do because who's kind of in the name, payments, um pushing payments. Uh I was uh when we had our brief, you know, I was I didn't know exactly what you you guys did. I heard the name and I was surprised in a way, you know, it was like kind of cool. I never thought this product would be needed and serve a purpose, but when you think about it, it's a no-brainer. So just tell our listeners what does what does the business do exactly? And then the second part of that is how what was the history around, you know, uh a little bit like how you use Salesforce as well.

SPEAKER_01 14:38

Yeah, sure. So the quick intro to uh Pushpay, we started as a payment processing organization focused on mission-based uh and nonprofit organizations. Um, and we've quickly scaled over the last handful of years into more of a tech stack, um, a technology partner for nonprofits and uh specifically in the faith-based market. So we've got three kind of core products now uh that make up that stack. The original product is what we call donor management, um, and that allows for whether they're uh supporters of your nonprofit or perhaps um congregants at your church to be able to provide donations um uh through a secure payment portal. Uh, we've got a an acquisition uh that happened a number of years ago uh that makes up our um what we call our CHMS or our church management system. So this operates uh a lot like a CRM, but specifically for churches. And um that integrates obviously pretty well with our donor management system. And then the third product uh is uh Resi, and that's a streaming product. So you can uh live stream events. Um we've got for-profit and nonprofits on that particular uh platform, but in the nonprofit or uh faith-based market in particular, you could think about streaming um, you know, a church service, for example, to different social channels, uh posting those to your websites, um, and Resi's the video streaming platform that does that. And of course, those all three work really well together, um, but you can use them independently as well. Um and then in terms of the uh use of Salesforce, um, Salesforce is like essential to running our business. Uh it's at the core of our internal tech stack uh related to go to market. So um we leverage that as our source of truth. We've got uh multiple products that sit um on top of that to help augment, like any other organization has, uh, you know, DocuSign and other installed packages in that way. Uh but it also integrates with our back-end systems that support all of our products and turn on different features or um whatever it would be needed to manage those products. It integrates to our building system. Uh we've got integrations to um data lakes and and tableau and other things are employed there too. So really a critical application for us. Um our challenge, uh, which I know we'll dive more into, but you know, right now the challenge is that the business has scaled and changed much faster than our technology has. And so we are in the process right now of really trying to clean up tech debt, identify and clean up tech debt, modernize business processes, and in a lot of cases get back to standard functionality where um previously decisions have been made to do something completely custom. And uh for those in the in the ecosystem or using products, these products for a long time, you know that that's not always the best way to um to leverage them. So we're kind of in some ways, we're hamstrung in our ability to scale until those things are resolved.

SPEAKER_02 17:53

So uh your title obviously is director of revenue technology, um, but all of these other aspects, you own them too, right? I guess you would call this the customer servicing side or the onboarding side, or the integrations with these other systems that are for billing, right? These are all post sales type operations.

SPEAKER_01 18:13

Yeah, it's kind of an interesting relationship. Um, like technically, I don't uh own some of the additional tooling from a cost center perspective. Um, so for example, we do have outreach and gain site, uh, which are enablement tools for our uh sales and service teams. Um those applications are owned by the respective teams, but my team owns the integration specifically, um, or in some cases the onboarding offboarding uh of team members too. So we work really closely with those other groups where that technology sits. Um there's actually the only, I was thinking of this the other day, the other day, the only team that we don't directly interface with within the organization is HR. Uh, but we interface with engineering and with product and um all of the front-end uh teams as well. And that's really because of just how the data moves and flows, um the different integrations that we have there. And even uh enabling things like agent force in our product uh requires you know working with products. So ownership of the tools uh depends a little bit. And depending on the ownership of the tools, we kind of determine who owns the specific touch points and integrations. Typically that's gonna be my team, RevTech, um, with Salesforce being at the hub. We completely own Salesforce specifically.

SPEAKER_02 19:36

Even even the non-revenue product portions of Salesforce. Yeah. You own that too, simply because you own you own the system.

SPEAKER_01 19:42

Yeah, the the the concept of revenue technology is that the bulk of what Salesforce and these systems are set up to do is uh maintain the front end uh sales and service side, which is go-to-market teams. So those teams specifically driving revenue for the organization.

SPEAKER_02 20:01

All right, so take us back. So you've been with uh with pushpay for just about a year now, I believe. Have you passed the year mark yet? It'll be April. April. Yeah. Yeah, so another month or two. So um tell us how it was when you first started it, right? Obviously, you were coming out of shell block, right? So you're coming from the consulting side, you're going to now uh client side. I don't even know if if that's a term they use on the client side. Like I don't know either. Yeah. Um right, so you go to the client side. Um right, so tell us a little bit about that, right? So so what did you inherit? How's your KT? How's your mandate right? Okay, you know, what are your top priorities? How did you get up to speed? Right, because it's it's often like a fire hose.

SPEAKER_01 20:46

Yeah, it was a lot. I think there was a number of challenges. Uh just the the transition back to the client side was really interesting. Um the the combination of uh work environments for one. Uh I was fully remote, moving to a hybrid schedule. So that by itself uh was interesting. And then when you're consulting, you do work with politics within organizations, but you typically operate more as a mediator in those uh instances. Whereas when you're W-2 actually working in the business, you tend to be in the middle of the political conversations. So, you know, there's just some things moving back to client side that I had to readjust to it from that perspective culturally. But from a uh a position and kind of the mandate, um the organization was well aware that the tooling needed quite extensive work. Uh, and so they were very clear from the very beginning that this was going to be uh a bit of an uphill battle. There's a lot of work to do, a lot of competing priorities. We still are moving the business forward with initiatives. Um and we operate as a shared service. So I've got all departments. Departments requesting work from us. We've got major initiatives from a business perspective that need to get done. And so managing those competing priorities is a bit more of a challenge in some ways than having competing priorities on the client side. Because you can you can kind of manage capacity a little different when, or um, excuse me, on the consulting side. Because you when you're consulting, you can manage capacity uh a bit a bit better, um, more intuitively, right? That's kind of part of the makeup of consulting. Um, so I was appreciative of the fact that that it was made known there was quite a bit of work to be done. Um, once you get boots on the ground, you start kind of peeling back the layers of the onion and you realize how much work there is to be done. So there's been moments where I've been pretty overwhelmed and trying to sort out what a roadmap and a plan looks like. Um and that's I think been some of the more challenging uh work is doing things in the right order, trying to make sure that we are for current initiatives that we're not adding to the tech debt, but we're actually taking the opportunity to go, how do we do this the right way? And how do we communicate to the business it's going to be extra time because we're going to do it the right way, as opposed to to jury rigging things as the culture of the business has been. Um, so that's that's been really the mandate. Let's come in and let's get this working as it needs to. Um, and it's not just Salesforce, uh, some of the related tooling is also structured that way. And so that's um, you know, kind of the larger part of the issues. Um in terms of knowledge transfer, we there was there was an extensive period. It was a full 90 days of planned activities, meet and greet key stakeholders, um, work with uh different departments to do shadowing, um, understanding key business processes, digging into the org itself and and really trying to understand what's in there, what can be deprecated, a lot of documentation review to determine what's up to date and what's not. Um so it was there was a pretty extensive amount of time there. I also um executed a kind of an analysis of the team and the business as well and had a deliverable as part of that onboarding process too. Um, you know, do we have the right skill set on the team? Um, what are the gaps or deficiencies that maybe need to get filled? Um, are there areas of work that that business processes that that are not working as it relates to our relationship to the business? So, for example, how are we getting new requests from the business? And is that working? Um, is prioritization actually working? Are the is the tool or tool set that we're using to manage our projects actually working? And in all these areas, you know, there were certain gaps that that needed to be filled. So a lot of that went into an analysis of the team and the broader um group of revenue technology with some suggestions and outputs that um ultimately some of which got executed on their own, some of which we uh we had to or I had to um begin to implement and and roll out. So um there there was a lot, a lot to to cover in that first 90 days.

SPEAKER_02 25:18

Yeah, I mean clearly it sounds like it sounds like they gave you the 90-day roadmap. Usually someone coming in your in your level, they would tell you to figure out a 90-day roadmap and come back um with us. Um I I think that's really great. It sounds like uh like whoever you're reporting to did like an absolute stellar job here. I'll also say that it sounds like, and correct me if I'm wrong here, it sounds like he knew the answer to these questions he gave you, but he wanted you to figure it out on your own um and come back with the details or or I guess the nitty-gritty, right? So if he's saying figure out if our um uh whatever you want to call it, our business request process is working, it sounds like he knew that it wasn't, and he's saying, figure out if it is, in other words, figure out what's wrong with it.

SPEAKER_01 26:04

I think there was some understanding that there were gaps in that and other processes, um whether or not there was a solution identified or truly knowing if there was an issue. I think it was kind of an area of here's here's a few things or areas of the business that you are now overseeing that might be an issue. So go either confirm that, because we know that it is, or validate that it isn't an issue so we can take it off the plate for consideration. So I I do think that there was a um general understanding of where some of the friction was within the business uh as it relates to revenue technology. And um I identified some additional opportunities through that reporting that I felt like could be uh much better. And so made sure to include that. Um the nice thing is I think coming in with a fresh set of eyes and having a bit of that consulting perspective as well. Um, I'm sure that the consulting side and and mindset helped a lot because I came in with that concept of being a consultant first. And let's just get a lay of the land. You know, if I think about coming into a new organization as a consultant and we're revamping processes, we've got to understand what current state looks like. And then we've got to understand what levers we can begin to pull and build out a roadmap from there. So that experience on the consulting side helped a lot to come in uh to push pay and evaluate teams and systems and try to figure out where do we have a starting point? What's some of the low-hanging fruit? How do we categorize these big, bigger rocks that need to get done? And out of that, ultimately, you know, we'll begin to build a roadmap. But um, that perspective helped tremendously in doing this analysis.

SPEAKER_02 27:54

Okay, awesome. So you got in there, you got your 90-day mandate, you did your investigation, you dug into tech debt, you evaluated your team, um assumed you made some level of changes at the team level, though we don't need to dig into that. Um, and then you put together a roadmap. So tell us about tell us about that process, right? So specifically of um how you how you dealt with classifying what are my big must fix ASAP issues versus this is the next year problem or this is a you know six month out problem, um, or how much are we gonna try to do an enhancement because I don't know, the product is coming on. Maybe they bought Resi. Were you there when they bought Resi?

SPEAKER_01 28:42

No, that was that was before me. Yeah.

SPEAKER_02 28:44

Right. Yeah. So how do you how do you put together that roadmap? Um, and then a quick follow-up to that is okay, great. How do you then sell that to the to the water team, particularly when you're dealing with conflicting interests on different business units?

SPEAKER_01 28:59

Well, if I'm perfectly honest, I think we're still building the roadmap. Um at this point, I feel like enough work in context has been generated um to rectify some of the areas of the business that needed to be fixed. So, for example, prioritization was a big issue that we were running into. It was extremely inefficient as we're working with each of the groups, uh, talking about prioritization of what? Uh just prioritization of work. So, as a shared service, you know, we've got um multiple groups that are coming to my team to say, hey, in Salesforce, we need this, or we need to begin to deploy this new integration or this app. Or here's a you know a slew of bug fixes that that are needed. As a team, uh, we we operate across all of the groups within the organization. And obviously we only have a certain amount of capacity to be able to execute all of the priorities of the work uh of the business. And when you've got five or six groups coming to you with high priority items, how do you begin to to prioritize those things? So the way that that was being done previously was in silos, uh, groups were asking for things that maybe had overlap to other groups, but they they were completely unaware of that overlap. Um, we were doing a lot of the facilitation within my group to kind of pair those things up and gather appropriate requirements. And that was just creating a lot of inefficiencies and people talking past each other. And then business, the business units would get upset or have frustration when certain work would be prioritized uh for a different group. And there's really good reason for it, but uh their high priority item was not. And so we've we completely fundamentally changed that process of um having a monthly prioritization meeting. Everyone hears what is on the table across the group. And what we've seen in that particular example uh in doing this is that there's so much intricacy and interplay between the groups that someone would raise an issue and go, oh, actually, that's that's really important for my group too, or we could benefit from that. I actually want to jump on that bandwagon and let's let's move that initiative forward instead of these other items that I was going to bring to the table because that's going to be more impactful. So it's helped to identify where we've got really great areas of spend uh to be able to have maximum impact on the business. And it provides additional context across the business units that maybe aren't talking on a regular basis with what a potential roadmap could look like and where they can buy in. So prioritization was one of those things that we uh that we updated. And um, you know, that that was kind of low-hanging fruit in a way, um, to be able to work that process through. Um and we did that with a number of a number of uh items that um I think help lay the foundation or re-recast the foundation for how we're going to operate as a group before we even get into building the roadmap and executing you know against against that roadmap. So now we're to the point where we've we've got a good operating model with the business. We've got major initiatives that have been identified across the business that all teams have buy-in um on that are really kind of taking priority. Um, and then we're really focused in on the things that what are blocking sales, what are blocking customers? Those become high priority items in our day-to-day. And then what are the um major initiative items that need kind of our full attention or a good chunk of our attention to move things forward? Um, we're leveraging some partners to assist on some of the tech debt and some of the enhancements where maybe there's some skills gaps or we just need some expeditious uh configuration uh to get done in order to hit hit timelines and so forth.

SPEAKER_02 32:55

So um it's it sounds very scrum-like or agile-like once-a-month meeting, so I guess it's a little bit longer than a typical sprint, but it's still very sprint-like. Um any any any issues with like people trying to bypass process, mid-month request, somebody go directly to developer because you're on vacation. Hey, can you sneak this in? That kind of stuff. Yeah.

SPEAKER_01 33:21

Yep. I think one of one of the things with this role is good stakeholder management. Um you're always gonna have you're always gonna have folks that want things faster um or that have changed their mind and now want to completely revamp something. We've had instances, as I'm sure most organizations have had, where we're even all we're very close to deployment, and the business comes back and says, actually, we've completely revamped that process. Um, and here's a new set of requirements. Um, right. So you go back to the drawing board on those items where we've really had to, from a culture shift perspective, but part of my job has been to change some of the culture and the approach of what we've done in the past to where, which has gotten us to where we are today, we've got to stop doing those things. And so if you are going to change requirements or we've got mid-cycle changes, we might be able to accommodate those things, but there's going to be some give. So I can't add something new if we've already made commitments to priorities. So, what are you pulling out of the current sprint to be able to replace um that item or pull pull in a new item? Um, or uh in some cases, very kindly telling the business, no, sorry, we're not going to do that, or I can't do it in that time frame. We will put that into priority for next uh next sprint or into our next prioritization meeting. So I think there's ways that you've got to be able to handle that. Um, saying no is is one of those. Um, but saying no with a why, because I the business doesn't always understand the rationale and that there's an order of operations and a way of developing software and these systems. Um and I think the why has been missing previously. So there was uh some contention, you know, around um this team always saying no, when the reality is it's a no, but we can do this, or no, and here's the rationale for it. So stakeholder management has become a real key component uh to what to what I'm doing to make sure that we're successful.

SPEAKER_02 35:34

Yeah, the the the sometimes stakeholders don't also understand system dependencies, right? We got to finish this integration first, and we gotta build the case management, and then we can build this feature because there's interdependencies there. Um last question on the subject. Um did your did you tie your release cycles to these monthly meetings? So did you take like a monthly meeting, put together, okay, that's our next sprint or a sprint, and then that's gonna be a release? Or did you take these meetings and you would say, okay, this is in this release, this is in that release, this is in that release, and have a regular release schedule? Right? How did you kind of manage these monthly, let's call them STERCO meetings, which I assume they were at at the very senior level, um meetings into a calendar of actual releases with deadlines?

SPEAKER_01 36:26

Yeah, I think we're still we're still refining this process um a little bit, but the intent is a monthly meeting, and this is where we will build out the priority for the next month. Uh we still operate um, generally speaking, in two-week sprints within within my team. And uh we try to do weekly deployments. So as things become available within a two-week sprint, if we can get them uh readied before a deployment date, um, we will and tested and signed off on, and all of the all of the um specifics are are confirmed. I will try to deploy that before the end of the release cycle. Part of that, uh the reason for that is that we've we just have so much um technical debt and friction that we figure if we can deploy fixes and functionality faster, then it unblocks the business. And in a lot of ways, that reduces the the need for us to support um the business through our support ticketing, um, which has a insanely high volume right now as a result. So that's that's the general cadence. Monthly prioritization, two-week sprints, weekly deployments.

SPEAKER_04 37:36

Nice. Um, I want to come back to something we talked about uh prior um to the recording was the notion of running projects like a consulting uh engagement. Um obviously you spent nearly a decade uh in in in the SI world. Some of the stuff you mentioned uh would traditionally be in scope, out of scope kind of conversations, right? Um discovery, like you can you can align it, it's all the same, right? Um and you you talked a bit about that, but like the initial 90 days is like a discovery call, right? You know, with a with a client, right? What do we want to achieve? What's realistic? What's our timeline? It's the same process. Um so so has and you've worked at an end-user process where you started, we call it a user. That's just the customer, you've worked for the customer before. So sometimes as as a recruiter, you know, we we we have um SI that you know won't hire from a customer if there's not worked at an SI before, vice versa. So But to me, I mean, I know there's nuances, I'm not naive enough to know there's nuances, there's differences, right? Um it is a slightly different skill set, more so on the soft skills side than I think the actual tech technical day today of the job. In your opinion, how much are you using how much are you running the project and the teams the way you would the same when you were back at Shellblack in consulting? Like, is it on a percentage scale, like how how much similarity is there between what you were doing?

SPEAKER_01 39:02

My day today feels like 100% because that's that's ultimately where we need to get the team. Um, but I know that's not a true number because it's uh it's still there's a cultural shift internally um with stakeholders, with what the process looks like um and what now we are requiring uh or trying to get required as part of making a request. Uh then you're educating uh the team in a different set of process steps and expectation setting. Uh, they also have an element of stakeholder management that's involved in that as well. So I'd say realistically running our projects, uh probably 50%, maybe a little bit less of what a typical kind of consulting engagement structure would look like. But you know, the hard part or the the part to remember is that there's a systemic kind of cultural change that has to happen. And those tend to be a little bit slower in in adoption. So as long as we're consistent in our approach to the business and uh continue to not make exceptions, you know, I think that that becomes uh much easier. Um, but it takes time to adapt uh to new processes too. So we're we're looking at what's working, what's not. Maybe a straight consulting approach doesn't work, but the concept does. So how do we adapt that to fit within the business itself? Um and so we're always in a process of revision and uh trying to make sure that it's as effective for the business as possible.

SPEAKER_04 40:36

Makes sense. Um so briefly we're gonna talk a little bit about uh the team uh you inherited, not specifics of individuals or anything like that, but the the the idea of um you know inheriting a team. Um how how big was the team initially? Because I believe from memory it was a larger team than it is today initially, and you you know there was a process there. So so just kind of set the scene. How many, you know, how many, you don't need to mention specific uh partners or anything, but how many people, uh, you know, FTEs, contractors, vendors, etc., were you using and and what does that look like today?

SPEAKER_01 41:12

Yeah, it was about a year ago. Um, so this is February of 26 that we're recording, February-ish of 25. Uh, the team was approximately 20, 25 people. Um, a good chunk of those were what we call support admins. So they were running some day-to-day mechanics of the system, doing reporting, data updates, um, working through tickets that were being submitted by by end users, um, handful of admins, uh, project manager, developer. Uh, by the time I came on that same year in April, that was down to about 12. So a good swath of the team um got got cut. And the in the idea with that was that for Salesforce, a typical Salesforce org, we've got 300 some odd users, 350, 380 users. Um, to have a team of 25 or whatever supporting them was just uh you know an extremely high number. What I don't think was understood at the time was that the business had built the system so complex that it was actually needed that number of people to support it. Um so again, in into the process of modernization. So uh when I started, I believe there was a total of 12. Uh, we're down to uh six. So right now I've got two uh two admins. Um we are uh backfilling a couple of uh roles or determining how to best um get some additional capacity there. Um I've got a project manager, I've got a developer, and um I do have an individual that works with uh kind of Straddle's marketing and revenue technology. So she operates as kind of product owner for um the marketing tools, uh, but she sits in in my group. So um interfaces with marketing and then brings a lot of those technical pieces back to my team. So um six of us total, if you if you include me, a couple of open positions that we're looking to fill to help. I think the the staffing probably right-sized it just right sized too quickly. And you know, now we're at a point where we're really kind of keeping the lights on uh and not getting to more of the major initiatives. Um so we've got to get some additional capacity in order to help right size the systems, and then I think you know, we're back into some form of alignment, but um it it happened relatively quickly, so that becomes a a challenge as well.

SPEAKER_04 43:37

And um what about in in terms of um onshore, nearshore, offshore? Um you know, how how how does that all look like? Is this all a local team in in Colorado? LS uh Colorado, right?

SPEAKER_01 43:50

I I think uh I'm I'm in Colorado. Um our company is based out of the Redmond, Washington area. Um so I've got uh folks that are in Redmond. I have a couple that are in um our Colorado Springs office with me. And um we we have had some partners employed uh at various times um off and on depending on you know different projects we've got two engaged right now um actually I technically I guess we'll have three uh engaged uh for various projects that that we've got uh going right now so um you know that's that's kind of a mix onshore uh all all of it onshore um we're exploring near shore uh whether or not I that will become you know thing for us I think we're trying to make that determination uh I think the larger question is you know contract versus W-2 um more specifically and what types of flexibilities does that provide where do we see the team in the next 12 to 18 months um so trying to plan a little bit for the future knowing that we have some immediate needs and just like with what we're doing with the business and Salesforce let's not do a band-aid today that's going to cause a problem tomorrow so trying to think a little bit further out as we're making some higher aid decisions.

SPEAKER_04 45:07

And obviously some of that is driven by uh new projects um that you have uh in in mind um and less so keeping the lights on but uh I I think um you know some of the stuff that you uh are looking forward uh to doing and doing more of uh we're gonna talk a little bit about uh agent force right so um so walk us through uh agent force um at push pay what does that look like um you know what is kind of like the use case and then I'll I'll let Maz pick up on maybe some of the the other areas of what went well what what what was a challenge what didn't and so on.

SPEAKER_01 45:45

Yeah the the first area that we've really employed uh Agent Force and and it's really the only application we've got right now although we've got um some potential thoughts of of additional um agents or even enhancements here but I I think it's a typical use case around help center customer service uh capacity we've got um a really great customer success team that uh works with our clients and what we wanted to try to do was provide a better service experience uh in a couple of different ways one was to provide more immediate answers to uh clients that were looking for simple responses or things that would be you know relatively easy for an agent robot to answer. We are also really wanting to retire some of our inbound customer service channels so email to case becomes you know pretty burdensome. It's a little bit of an older technology and we feel like we can reduce cases overall by channeling our support through uh through an agent. So that was really the intent but we also wanted to make sure that we weren't putting up an AI wall between our customers and our service reps and so um we went through an intentional process to ensure that uh agent force is the entry point for service but it is immediately able to connect you to a real person um if you want that. And so that was that was one of our um our big goals. So um we weren't looking at it from a head count reduction perspective in CS it was really about a customer experience and the ability to uh become more efficient with the folks that we have while um eventually getting to a point of retiring you know some of our service um based functions uh mechanical functions right like email to case what what about um so as as you uh um I don't I imagine I'll pass off to you but uh uh you know I think um obviously everyone in the ecosystem is heard of agent force there's no there's no way to not hear about it.

SPEAKER_04 47:53

Where did you start with like determining use cases?

SPEAKER_01 47:56

Because I assume given that this was something that probably was one of the first things on your to-do list when you joined like how where do you start is it as simple as saying uh okay let's just trial it internally on internal facing process enhancements right an FAQ glorified chatbot is that where you start or you know did you do a whiteboard session to determine okay what would we want to be automated and and through a bot uh through through agent force versus because you know that that human touch right yeah uh well this this project actually was underway prior to my starting so I came in right at the tail end but um if I was doing it again uh or and based on what I know um well let me start with what I know so from a project perspective um there was the the intention to become much more efficient uh the business felt like agent force was a good uh first step in uh identifying those efficiencies um I do know that there was a our RCS team um has a great operations function so they are really well uh in tune with um the needs of that organization as well as the needs of the customer uh they keep great records they come up with fantastic ideas to make not only their their work easier in Salesforce but also help um reduce friction for our customers where they might experience that um within the within the platform so they had a a pretty extensive list of things that they wanted to to accomplish this was also being paired though with the uh deprecation of a knowledge based um kind of searched tool that sat on our um on our help center and so part of this was a cost cutting measure with that specific tool in mind and ideally getting some of the same benefits through uh agent force specifically at at a fraction of that cost. So all of that was represented the driver um I there were metrics that were put around it to kind of help understand the the cost implication in the ROI. And there was a goal that was determined by the business. So it will be successful when these things are determined to be have been met. I think we're pretty close to that our first round didn't quite accomplish everything that that we wanted it was it's been very successful uh but it's not quite where we want it to be um so we are in kind of a a phase two right now uh working with a partner to get that uh more refined and dialed in so that we have more confidence in in the bot itself or in the agent I should use the right language the agent it's still still a new habit uh yeah when you've been in the ecosystem so long those those phrases keep rolling out the wrong way an agent is a bot it's just a type that's marketing brilliance by the way um so so how how do you how do you measure do you have like a like a formal measuring that you can measure okay if they get enough answer now I met the bar I can roll it out there was a lot of internal testing around that um where we had folks that that knew the content that was supposed to be surfaced um very well and we had a slew of uh prompts that we would just hammer uh at that at that agent and see what comes back um so we did have we did have an understanding of what should be happening or what we're anticipating happening which I think was really helpful um pulling in some not outside resources to push pay but pulling in some outside research resources from that uh CX group the the customer um experience group to help with the testing as well um was was really helpful because they don't other groups may not know the same terminology in the articles well enough to to validate um and so you get a little bit of a different mix when you pull in uh those folks so yeah I think there was there was an idea of what should be expected and what we would determine success based on knowledge of what we're expecting to return or have returned.

SPEAKER_02 52:08

So so the rephrase do you have formal test cases for the agent? I think there were some yeah there were some formal test cases so you do treat it like very much like a traditional QA cycle with formal test cases pass fail.

SPEAKER_01 52:22

Side question Yeah um like you guys clearly work with uh uh a more religious right user I would think do you adjust to chop that for that kind of culture in terms of like how the how the bot responds and oh we mean the agent when we say bot just just to be clear agent bot yes see I'm still yes um there is some training within the agent I think just to have you know the the friendly tone um specifically and working with the types of organizations that we do we just know that connections are really important so we wanted the tone of the agent to be collaborative um you know as if they were talking to an actual person. We've we've named our bot our agent uh Jenny which is short for generosity um which is one of our kind of big um uh marketing and attributes you know that we talk about a lot so even just down to the naming you know we tried to make it something that was familiar but also played into our product and um where our where our clients are so we tried to create a a a persona that fit uh well with the organizations that we work with so jenny with a G. Jenny with a G. Okay cool. Not Jam on the block.

SPEAKER_02 53:42

No that's a different Jenny yeah yeah so okay so what about um the knowledge base that you think Salesforce knowledge base or connecting to external no that was a Salesforce knowledge base okay so you're not you're not or not yet at least trying to run through very specific user context or client context or customer context queries with this knowledge base. It's just a generic knowledge base or are you dealing with the security of segmenting we've got some segmenting happening um between products.

SPEAKER_01 54:22

So for example right now Jenny's not working with the uh resi knowledge articles um that's a that's a different phase that we'll be looking at deploying uh jenny to or with for that product um but we also have some segmentation by product uh that within those knowledge articles it's important to make sure that we've got the right um tagging for we we we have found um issues really the issues were were that we found related to the knowledge base um are what you would expect where the documentation just wasn't clear um it was not as robust as probably it needed to be phrasing was different it was all internal language more so than the external language that our clients might use so when you have an agent that's trying to make a decision on a knowledge article to pull back you've got a conflict in language for example or terminology that's being used and so there were times where we had knowledge articles for what was being asked for but she wasn't finding it andor returning it properly. So there was a lot of work to update the actual content of the knowledge articles to create more clarity and distinction between product names and different aspects of our product. We also have on occasion, you know one of the challenges that we also run into is that we have clients but our clients have clients. So you think about we we work with a church for example that church has folks that are using our product from an end user perspective we're not servicing that end user right our end user is in the middle it's the church. So you sometimes we run into instances where the church's um end user is trying to get an answer from the bot and the context that it's returning is from an administrator perspective for example of the product and not actually returning a response that's helpful to the secondary end user. So trying to make more distinctions that way part part of what we want to do in this next phase which is on our list is to uh make sure that they've got the bot the agent has context of a user uh right now it it doesn't have context of the user so it's very generic but we want to be able to say hey you're an admin in the org here's what we know you can do from a permissions-based perspective and so we're gonna return this result to you or you're not an admin in the org let's not bother uh sending this particular set of of instructions to you but instead we'll return something that's more appropriate to your role I think that'll help a lot in um the user experience portion of the agent and uh for that for our end users um our our clients so talk to me about maintaining the human touch right because that you said was really really important um I think you said you can auto route auto route to a human at any time um like do you wait for them to ask do you offer hey I'm gonna route you or do you say would you like me to route you to a human um and then how do you deal with like the 24 hour thing?

SPEAKER_02 57:42

Do you really have staff 24 hours or do you turn the chatbot off?

SPEAKER_01 57:47

Yeah I'll answer the last one first we we do turn it off um we have we do have some available agents out uh sorry well so agent force itself would be um available but the the direct to a human would be within business hours uh but typically in that scenario we will still will um indicate a call back so yeah have someone call me back during business hours that'll initiate a uh a case in our system and then we've got a team that first thing in the morning will go and um and call back and make sure that either the issue was resolved or we'll help to resolve the issue. We've been refining this process a little bit you know that we went in with the intention of it being a um not not not an AI wall. I think some of the messaging and defaults that are placed uh into the agent are really critical. But what's the first thing when you when you open up agent force and that welcome message is displayed you don't want that to feel cold or in our case we didn't want that to feel like there was an inability to get to a person. And so we've been testing out different pieces of messaging to say hey if at any time you want to talk to someone just ask me. And that's actually the first message that comes up or the welcome message that comes up now so that people feel like they can immediately get to a to a person. Whereas before it was a little bit buried or you had to ask the question and see what would happen. So we we do want to maintain that human touch. And then of course the way that she responds um you know we wanted to make sure that it was very conversational as agent force is out of the box but also had um has a bit of the the tone that you would have when you're working with one of our one of our um agents you know on the phone or over email so um do you keep statistics on that?

SPEAKER_02 59:38

How many people say immediately say human please like right after the first message?

SPEAKER_01 59:43

Probably I don't have those but I do have a team in the uh the the CX team looks uh has been looking at every single chat conversation since we've deployed um not only to refine the agent and our content but also identify where we can make improvements like that. So I don't have those metrics but I'm sure we've got some number around somewhere we're on a first request they're asking what um I think the importance of choice is key.

SPEAKER_04 1:00:11

I think as a consumer whether you're um you know buying something online or booking airfare whatever right you want the choice of being able to speak to a human um or not have to speak to a human right can I just get the answer as quick as possible.

SPEAKER_01 1:00:26

So I I I think that's really important especially given the nature of what push pay do right um you know your audience um what the causes are and also the probably the age range as well of of of of who's going through through the the platform so good stuff last question on agent force and we'll we'll wrap but um tell you sky's the limit uh of course when it comes to agent force if we sat here in 12 months uh you know having having this conversation checking in what would you have liked to have achieved with agent force like how far can this go for push pay as a business um what would be like the pinnacle end goal that agent force would accomplish the the thing is that like it's the agents are already accomplishing a lot for us um if we look at case deflection rates you know they're they're really high uh which is a big win um the overall satisfaction I think right now is a bit mixed um and that's what we're trying to get higher scores on uh when we look at um general feedback from uh from our clients so you know I think it I I don't even know if there's like a technical thing that we would try to accomplish right now with agent force that we're not getting um I think what would be really exciting is that people are actually excited to use the agent uh more so and and again that's not because we want to remove the human component but just that the agent is so helpful and easy to use uh to accomplish what I'm after that that becomes my default uh as as a user and then if I run into something more complex or have things that maybe I can't do from a permissions based perspective that the agent you know can't award um uh functionality to then then there's an escalation point you know to a person. I think to me that would be that would be a big win. But there there is still such um hesitancy around AI uh and it in the everyday applications. I think even just about my I had to open a case with Salesforce um this week and using agent force to do that feels really clunky and it takes multiple requests when I used to be able to just click a button and key in what I needed and submit the case. So you know when I think about the different applications of the experience to me to me it's not so much what can the the agent do but what is the experience of the agent between me and the agent. And I think that that's the area we would really love to see refinement and improvement.

SPEAKER_04 1:03:12

You're um that's good insight you're you're using um primarily agent force from a service capacity uh which I know is where it's most commonly used um so so it's not a uh organizational uh you know uh specific reason but I'm curious and you might not have the answer it could just be a yes or no and we'll see um as we close up now but do you see agent force for example at pushpay being used outside of just purely service cases of inquiries do you do you see a world where you might be able to leverage agent force for revenue generating activities sales uh sales enablement sales optimization inbound leads you know that those types of things as well do you do you think that's possible?

SPEAKER_01 1:03:59

Yeah I think I think that's definitely possible um I I've seen some use cases for that in the ecosystem uh and some applications of that um where I struggle personally is still this concept that your data and your systems really have to be in alignment and have to be well tuned to be able to really leverage these and there I I think that there's a concept that you can just kind of put AI on top of these things and they're going to fix the problems that are underlying in your systems or business process. And the reality is that the the agent is probably going to exacerbate those problems or make them more noticeable. Yeah and then because you're working with an agent that that has only so much knowledge and autonomy it's going to become an extremely frustrating process. And if you pigeonhole certain processes to use that agent then you've got really frustrated users that you're actually creating more friction for them than you are creating helpfulness. So I think I think ultimately while there's a great series of applications for agents whether it's agent force or um other other tooling that the same concepts still apply good data model good data hygiene solid business processes and you've got your systems are you know they're they're in lockstep with the rest of the business and they're efficient um if those things are still true they I think those have to be true for agent force or any agent to work effectively and produce the type of results you're looking for.

SPEAKER_04 1:05:39

I mean how can we top that as a as a final thought um so all we'll say is thank you Brent or appreciate your time uh you spent with us today it flew by and um you know I think we could have a follow-up podcast in in the future around some more of the agent force stuff uh but I I yeah I guess your test your your note and take on it is obviously the risk is potentially higher if it has a more um you know if something were to go wrong in in in a client facing sales cycle type of thing so a bit more refinement a bit more bit more training for for for jenny needs a bit more uh upskilling and and uh training before she's let loose in uh uh in in the sales cycle let's say we would agree with her access to actually do things instead of just regurgitate information.

SPEAKER_01 1:06:25

Yeah. Yeah I think that's right. Baby steps.

SPEAKER_04 1:06:29

Fantastic. All right Brent well thank you so much again uh for our listeners please do not forget to subscribe to learn more about CRM successes uh from companies like pushpay and by leaders like Brent. Thanks all