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.

SPEAKER_04 0:26

Welcome to the CRM Success Show, where we deep dive into CRM success and failure, delivering real stories with real impact. Today we're talking with Andy Vase and Neilan Patel, both from Rent. Andy is the director of enterprise applications, and Neilan Patel is a senior engineering manager. Welcome, Andy and Neilam.

SPEAKER_02 0:45

Thanks for having us.

SPEAKER_05 0:47

So we're going to start off real simple for our listeners today. Neilam, ladies first, we'll start with you. Could could you first both tell us a little bit about your roles first, and then we'll circle into what the company actually do? Neilam, over to you.

SPEAKER_02 1:03

Yeah, so I lead the enterprise applications team at Rent, which is our business operations teams across the organization. Our key stakeholders are our sales, our sales operations, client experience, marketing, billing, finance, collections, anything that helps run the company. They are ultimately my team's business partners. We manage and support all the business processes that we build within our Salesforce platform. And in addition to any of the legacy applications that we also still support and maintain.

SPEAKER_05 1:43

Fantastic. Ivy?

SPEAKER_03 1:45

Yeah, awesome. So I head up the enterprise applications team here at Rent, and we really focus on the lead to order to cash lifecycle. And so obviously CRM, uh Salesforce, and everything around it is a big part of our group here. Um regionally just acquired the DNA team as well as part of our group. So we're kind of coming full circle in terms of building that 360-degree lens of our customer. Um but yeah, that's that's our purview here in the Enterprise Applications group.

SPEAKER_05 2:10

Fantastic. And rent as a business, my understanding is it's essentially a uh, I guess like an online marketplace connecting renters with properties. Uh that's a super simplified version, I guess, of what it does. But Andy, do you want to maybe Ne Lam, because you've been there a lot longer, do you want to shed some light on kind of what what else rent do?

SPEAKER_02 2:29

Uh digital marketing for advertising, rentals, and apartments. Um, we have a couple of websites. Our flagships are rent.com and apartmentguide.com. And so those are the two sites that we do operate off of for the most part. Uh, we are a subsidiary of Redfin most recently. Um what else? What else would you like to add?

SPEAKER_05 2:55

What about um I was reading you offer kind of communication platform of some form, um, like to help property managers and tenants?

SPEAKER_03 3:08

Yeah, yeah, we're a full service solution for our property managers and clients. And so we have products that help answer phone calls and live chats, and our goal is ultimately to help our clients fill their leases. Uh, and so in addition to being a marketing agency and being an ILS, which is a listing service for rentals, we also offer other solutions leveraging cool technologies like LLMs uh to streamline the management process and sort of the intake of potential renters for our clients, which are usually property management companies as well.

SPEAKER_05 3:38

Nice. And let's give an idea of scale, um like roughly how many properties or or renters do you know rent.com kind of support and provide for. Andy.

SPEAKER_03 3:52

Yeah, Neil, you're gonna have to help me a little bit in this one. I know we have about 40 million unique users uh a year that visit rent.com, um, but that's just rent.com. We remember we're owned by Redfin, and so we really have a bigger footprint than that. I think we have actives a little over 10,000 property management companies, Neilam. Does that sound right to you?

SPEAKER_02 4:11

Um we have over 20, about 19 to 20k properties.

SPEAKER_05 4:17

Um US-based or North America as a whole?

SPEAKER_02 4:22

North America as a whole. Well, US-based.

SPEAKER_03 4:25

Yeah. Very interesting. Just so your users better understand, uh, we we really focus on property management companies, so not the individual owner that just rents their helm to a potential renter, but these are companies that manage multifamily buildings, um, very often more than just one as well.

SPEAKER_05 4:42

Perfect. Okay. So, from a Salesforce perspective, where did that journey start for rent um when it came when it comes to Salesforce? Neilam, you want to pick that up?

SPEAKER_02 4:54

Uh that journey started a long, long time ago. Um probably around the time that I even joined the company. Uh, they had purchased the Salesforce platform. Uh, not very many people were aware of the platform. It was still kind of shiny and it's a shiny new toy, right, for engineers and technology folks. Um, over time we developed on it, we configured it, uh, we did a lot of custom coding, uh, all of which were all learnings that we learned in the last couple of years that they weren't the best ways of implementing uh using Salesforce. And so we unraveled that just a bit um with our service cloud project that we'll probably get into more details in a few in a few minutes.

SPEAKER_05 5:43

Perfect. And uh again for our listeners, I know you mentioned uh for for as long as you were there, just for context, that's about 14, 15 years, correct? So around 2011, 2010, 2011. Um and then basically what I'm hearing is a couple of years, uh the last couple of years, you start to see the ROI out of Salesforce, and that times up quite nicely when Andy joined the business. So I wonder if that's just a coincidence. Basically, you brought Andy in and everything's great.

SPEAKER_02 6:10

Andy came in to help uh everything become great, so yes.

SPEAKER_03 6:16

Awesome. All right. Um I think maybe I'll just add to that slightly. We we implemented again in 2011, and I think we at a at a at a point we were really great. Like we we were top of the line. Salesforce was driving rent's business, which was actually larger maybe a decade ago than it is today, and so it was a huge part of that growth story. Um, I think what happened over time is that middle implementation became a little bit stale, a little bit outdated, um, and you know, wasn't really taking advantage of some of the newer features that Salesforce has released over time. And so what we've kind of done here is try to rejuvenate it and bring out some of that potential in the platform or that that maybe we didn't have from the decade of its existence.

SPEAKER_05 6:58

So so before we go into service cloud specifically, which uh Maz will pick up on in a little bit more detail, um in its most simplistic form, how how are using Salesforce or how were they using Salesforce prior to the kind of the Service Cloud project we're going to talk about? What was it used for? Was it simply to help sales professionals canvas and prospect to more landlord owners? Um was it more inbound than that? What was it used for? Sorry, Nilan.

SPEAKER_02 7:36

Um it was mainly for intaking customer requests. We used it for contracting. Uh, we also used um custom, we built, we know, we developed custom code to help support our billing and fulfillment needs for the contracts that were processed. Uh, we used it for integration with other platforms. Um, but it was all very much of a reactive model of how we did implementation versus thinking through what Salesforce and the platform it can offer and really thinking about all the features and the the bells and the whistles that would help the business grow and we can help scale and maintain the the growth of it.

SPEAKER_04 8:21

Cool. So you got you guys mentioned uh that some of the stuff that I guess that was real operating really well in the 2011 time frame and then kind of went a little bit stale, um is that just simply because uh Salesforce I guess it was around that time, maybe a couple years later, that they really started ramping up their investment and modernizing Lightning. I don't think came until even later than that, was 2016.

SPEAKER_02 8:47

2016, yeah.

SPEAKER_04 8:48

Or so, right? So um was it just a function of the entire market or Salesforce is moving and you guys just didn't catch up or keep up or was the business environment changing? Like what like what what caused it to go stale?

SPEAKER_02 9:06

I think a little bit of both of what you just mentioned, Dave. Um business growth, Salesforce itself, we didn't pick up on the new features right away. Um landscape, the business model didn't change, but the way we ran business was run differently. Uh we had leadership changes along the way. So it was a variety, it was a variety of factors that we didn't, I mean, we just didn't touch it for many for quite some time. And I can't even say years, I just want to say some time.

SPEAKER_04 9:41

Cool. And you guys, I would say at your core, and correct me if if this is probably a bad assessment or if it is a wrong assessment, like you're really a marketing company, right? You're helping renters right do their marketing to find um to find tenants. So any of that expertise like goes back into marketing your services and like with that done outside of Salesforce. How how did that how did that like drive your process that you guys have this kind of let's say industry knowledge or expertise?

SPEAKER_03 10:16

I think that evolved over time, Neilam, right? I mean, uh, I know you were here for a tenure. We used to just be an ILS, which is an internet listening service. So we were primarily just one of the premier spots on the internet you would go to if you wanted to find an apartment. Um, a lot of those ancillary marketing services that we do today, like TikTok and social and search and engage and all those other products that make us kind of a full suite marketing solution for PMCs, that was part of maybe the evolution in the last three or four years. Uh, and that also really is a big part of what spurred um some of the changes we've had to make in the platform to support these different channels and products and services and fulfilling them and onboarding clients and everything that kind of goes along with it. So definitely that that was definitely a big part of it. Um, along with, you know, you don't break what's working because it was working for us for a very long time until some of these changes came about.

SPEAKER_04 11:08

Okay, cool. So that I think goes right into the Service Cloud project, right? So now you guys are um expanding your offerings, a lot more products, and I know for a fact this caused, I think, like you started having more complicated onboarding processes, right? And that's part of what Service Cloud came in. Um, I know that wasn't all of it. So yeah, why don't you tell us more about right the decision to go with Service Cloud, was it being used before at all, and you just kind of expanded on it. Um, or was this like a full-blown initiative that give us the backstory?

SPEAKER_02 11:41

Um, Any, you want this one?

SPEAKER_04 11:43

Yeah, either one of you guys, whoever knows it more, better. Go for it.

SPEAKER_02 11:46

Uh well, Service Cloud, we always had Service Cloud. That wasn't a thing that we purchased. Uh, we always had it. We just didn't implement it or use it in the most powerful way it could give us. And so what I mean by that is we didn't have case management rules, we didn't have case routing, we didn't have skills-based, we didn't have any of the standard bells and features that Service Cloud would offer, that does offer, right? Um, and so the way we supported our clients when they submitted issues or anybody submitted a request, the customer service support model was more of a reactive. Um, we had a first in, first out concept. Cases didn't get routed automatically to anyone. They went to the first person that was available, whether it was the right person or the right team, whether they knew it about, knew about it or not. And if they didn't, they would have to escalate it or hold it until they could find someone to help resolve the issue. Um, case close times were ridiculously long. Uh, not for the lack of trying, they were just long. Um, we had potential revenue losses because clients could have been asking us for some more information on certain products, but we didn't have it. We didn't know the case existed until we got to it, right? And then we lacked visibility to critical issues that were being reported because we weren't tracking it the right way. We weren't tracking it in any way. We're just we're being very reactive, and we've got a case come in, we've got an issue, we're looking to solve for it, and that's it. It was a start and finish, but nothing in between of trying to figure out what could be causing the all the cases that come in. And so that that's kind of the initial reason of why we started the service cloud project. Um, it was essentially a revamp overhaul. Um, let's tear everything down and start from the foundation up.

SPEAKER_03 13:40

I would just maybe add to that a little bit and say, I remember when I first joined, we were actually looking at like alternative platforms. Uh, and you know, if you work with me or know me long enough, you'll you'll hear me say Salesforce probably isn't the best service solution on the market. It's probably not the best CPQ solution on the market, but it is truly the best customer platform on the market that kind of can touch every part of that customer lifecycle and be able to bring that all together to create a seamless experience through the entire client journey and lifecycle. And that's, I think ultimately why the business and us doubled down on investing in Salesforce and going through that service cloud transformation. Uh, because it was core to our ecosystem, core to our infrastructure. We built a lot there, and that transformation really helped us get so much more out of it. Whereas going to another solution for service would have just been, you know, a massive project with not nearly the same ROI that we've gotten, uh, that we've been able to get with what we've done here.

SPEAKER_04 14:40

So, how how do you go about tackling your project in this size, right? Because you're saying you've got to divide up your service into teams based on skills, figure out how you're gonna route it. Maybe you don't have, maybe did, I don't know, have the case history to know what are the cases that you need the skills for. Um right. So, how how did you guys decide to tackle this? I know we said in the wraparound, you go to hybrid, okay. That's how we said here.

SPEAKER_02 15:06

We actually took the data that we did have uh with the current cases um and you know, exported them. We sat down with our business partners and we analyzed the data. We looked at the type of cases that were coming in using any field that we had possibly that we were recording, along with any follow-up notes. Um, and from that we derived a case management process that says, here's the type of case, and here are here are the possible reasons and sub-reasons that this case could follow under. Um, and with that, we derived a case management kind of hierarchy. And then from there we went and started building out, okay, well, here are all the case, here's the case hierarchy, here are all the things that could fall into this bucket of work, and here are all the people that can work this. So this is where you start implementing case routing, case uh skills-based management with individuals on the team. You can assign their skills in Salesforce, right? In the in Omnichannel, so that we know which user can answer this case on a first touch resolution. One of the first, one of our goals, and we identified a couple of goals. A, we need to have a really good exceptional customer service experience. That's what really sets apart most companies these days is when they have a fantastic client experience. And then the second is how do we how do we increase the or decrease the amount of time that we can start and finish and close a case for a client in the least amount of transitions to other teams or other individuals within the same team. And so, first, first closed case touch resolution. And so those are we had some goals in mind that we wanted to set out and accomplish. And with the revamp of everything, I think we had a really good start by just exporting the data that we had first, reviewing it, analyzing, dissecting it down. That alone was, I think, what I don't know, one to two months of work. Um, and that's really working with the business partners. They have to, they're they're the key to making it to be successful. That was their, they were the key stakeholders.

unknown 17:21

Awesome.

SPEAKER_03 17:23

You asked a question early about methodology, that was the beauty of the agile process. Neilam and her team really engaged with our stakeholders, did that upfront discovery, mapped out what our future state needs to look like, did that mapped out our current state, future state, understood the journey there. But as she implemented it, it was iterative and it was really working together with the business to fine-tune things. And I think that was uh critical to the success of that initiative and project.

SPEAKER_04 17:49

Yeah, for sure. Um, I just wanted to point out it's really, really smart using um tick list type fields or lookup fields as opposed to pretext. It's one of the biggest mistakes in case management to lots of lots of text because you need notes, it's a case, but very difficult to report on um if you don't have proper classifications and almost better to have improper, uh I'll say not perfect classifications, but classified in some level than uh than not. Um, and that leads into my next question. Uh Andy, we'll we'll hop it over to you. Is so now you guys are, I guess, petition to grow, expanding your product basis, right? How much do you think of service when launching a product? Like, do you now think through the whole service process at the forefront of a new product launch, or is that still an afterthought? Wait till they get to data, then no, we we have a framework, right?

SPEAKER_03 18:42

Like that was something that Neilam did is she created a framework that really wraps around our products and services. And so when we have a new product that comes to life, it plugs into our framework. We have the questions we need to ask, we know how we need to configure that particular case's workflows, what the milestones need to look like for it. Uh, and sort of it fits into an architecture that was developed that that accommodates any new additional ask in the future.

SPEAKER_04 19:07

But how well can you predict what cases are gonna come in?

SPEAKER_03 19:12

Um, well, you never know what type of case is gonna come in, I guess, right? Like so you you have the nuances and you build your case management in a way to accommodate structured things that you know how they're gonna kind of flow and where you can kind of even develop automated solutions to resolve them without having to go and spend time and leverage things like knowledge to deflect cases as they come in to help our users. And if we do get a case or that's new or it's we can't solve for it, we have workflows in place that gets it to the right person that can either triage it or resolve it themselves.

SPEAKER_05 19:44

When it comes to um the case management review, you mentioned business partners again, just for context, like who were the business partners for for this program, uh Andy? Who did that consist of? Was it was it was it this the service because the service people themselves? Like were they actively involved in helping shape the the as is to be, or was it leadership?

SPEAKER_03 20:07

Uh we'd start at the leadership level, right? So we we started with getting buy-in at the leadership level, mapping out the journeys that go around all the different case workflows, and they invited the folks that are their leaders on their team. And so, you know, you can definitely chime in here, but as we're going through that discovery process, we really included the leaders, the folks underneath them, and then individual contributors on their team that really knew particular areas. And we collectively worked together to kind of map out the understood processes at that time that we needed to be able to support. Um, and so uh it was really customer service, it was onboarding, it was billing, collections. So we really touched on every part of the business that ultimately leverages Salesforce today, which is every aspect of our company, quite honestly. Everything kind of flows through the platform uh here on the run side.

SPEAKER_05 20:54

And then you mentioned um service cloud, your words, not mine, maybe isn't the best service, uh Salesforce isn't the best service uh product. Um always curious, is although we focus almost 90% on Salesforce, we do cover the cover other CRMs and products. Um what else was a consideration, even if it was briefly?

SPEAKER_03 21:18

Yeah, I mean, ServiceNow is always like the first one that comes to mind. Uh that that's that's the big player in the space, but obviously it didn't quite fit with the rest of our stack. Um, there are other solutions out there by Laysian and other products that also work really well depending on what you're looking for in terms of scale. Uh, but again, it was more than service, it was about building a pipeline and accommodating our customers' journey as they walk through their life cycle with us. And so to take one piece of that and move it to another platform and have it integrate back just didn't make sense. Uh, and so that's ultimately why we we landed in Service Cloud.

SPEAKER_04 21:54

Yeah, so interesting. You mentioned ServiceNow because I think what, two days ago, three days ago? They're getting in the CRM market. Watch out, Salesforce.

SPEAKER_03 22:04

Yeah.

unknown 22:05

Yeah.

SPEAKER_05 22:06

Go ahead and uh cure time will tell. Um maybe a collaboration or partnership coming there at some point. Uh who knows? Um how to say that?

SPEAKER_04 22:16

We can say what we want. Are you kidding?

SPEAKER_05 22:20

Um in terms of filter here. We don't even want to see that. Um in terms of like, so you talked about like kind of KPI KPIs and Elam in terms of you know trying to be you didn't say world class, but but you said you know, improve obviously service and and and make that where it should be in terms of a business like like rent, what you would expect as a maybe a consumer of services, you'd expect you know case cases to be answered quickly, efficiently, the best person you know to be to be assigned to your case, and and and case history and so on, right? They're all basics you would expect when any of us deal with a company, right? Um, in in today's tech market. So um could you elaborate on specific KPIs, right? Like, okay, you don't have a lot of KPIs to compare to, you just know things aren't great. We're gonna do service cloud again. Um were there any kind of metrics that you'd set out as a project team to say, okay, we want to reduce the days to close a case by X amount of time. So you know, any nitty-gritty?

SPEAKER_02 23:32

Uh we didn't, so it was so beforehand we didn't have anything to measure our measure against, right? So we didn't really have a baseline. Our baseline was uh this project, and we could only get better from there. So I I mean today, if I if we were to go back in time and look at cases that were open, there were cases out there that were open for over 20, 40 plus days at a time, and nobody had touched it. It was still sitting in the status of not touched, right? Um that's just poor experience. I mean, you we can't have a client wait that many days to have someone reach out to them, right? But if you go look at our case view today, you will not probably see more than maybe five cases not touched, but not in a day, maybe within the hour. Um that's because we have cases that are just constantly being routed to the right people, to the right teams. They don't all go to one single drop point, they actually get auto-routed based off of everything that we're getting from the client, from the internal user. Um, and so that alone is a I think was a big win for us to see that we don't have cases in our queue that haven't been touched by a single person yet. Um within one business day, you can see things are moving and progressing along for for most all cases, if not all.

SPEAKER_05 24:52

I think just a massive time save, not only obviously for the customers, but even internally, you know, asking, you know, where are we at with this, where are we at with XYZ, you know, you could just see it all in real time, moving along the right channels. So um, but but you had the product before, right? It's it's not a new product. So it was just it was just again, like I'm trying to understand like what why why why not sooner?

SPEAKER_02 25:17

Like why um it was it was definitely a miss. I I think there was a lack of knowledge on how best to implement using Service Cloud when we first purchased the platform. Um I just don't think it was done appropriate correctly, or we didn't think through enough at the time. And back then, uh I mean, I had never even used Salesforce 14 plus years ago. And so everything I know now is everything I've learned over time on my own, through experiences, whether it be a win or a loss. Um and so as we evolved as a company, as you know, as individuals on our team evolved in learning the platform itself and the and how we use it, I think we all learned that this wasn't right. Um we could do better and we can't and we can do better. It was a matter of pulling the plug and having having someone help us pull that plug and bring some confidence in the fact that we can get it done. And I think that's when Andy came in uh when he joined the company. He brought some he brought a level of confidence to our stakeholders that they just didn't have for us yet. Um, and we lack that with working with our partners, I think. And Andy came in and helped help us with that, and we were able to convince them let us let us break this down and start over, and you'll see the benefits and the the return on the investment in doing it.

SPEAKER_05 26:45

At the beginning, but benefiting from it long term. Um, all right, so Captain America, Superman, I don't know who your favorite uh superhero is, Andy. Um but um so so you you take up the reins of of the project. Um just just give us an idea of like the size of this uh this project. So like how many users, licenses, how long did it take? Was it different phases? Did you do it all in a one and done? Was it like a multiple phase rollout? Help us understand the size.

SPEAKER_03 27:17

Wolverine, he's my favorite superhero. Uh yeah, no, it was definitely done in phases. We have about 600 users in Salesforce, and that includes both client service, onboarding, uh, sales users, and our internal ecosystem. But we all use every feature of it, including the service piece. So um every part of the organization ultimately touches it. Um, it was done in definitely phases. I we really, there's still even pieces that we're tying together now as we're going through and adding different features, but the big overhaul is getting back to foundations and the fundamental piece. So it was kind of like let's just re-architect the core of the platform, get our case types and case reasons and our case workflows all cleaned up and ironed out. Let's understand how it's gonna, what workflows we need to support that. What does alerting need to look like to function there? We we had our internal folks and we brought in some contractors as well. So we leveraged a size and brought in an amazing art architect, service cloud architect, uh, Yulia, um, who came who came in and then really worked wonders with our team to help um arrange stuff. And then we hired our own architect, Joe Moffitt, who's been fantastic here as well. And so we had some really smart people that were handstick keyboard as well, and we we really rolled it out iteratively, but it was big bang at first to just kind of flip it over and rebuild the foundations. And then we added different pieces as we went along, including you know dashboards and reportings that came with CRMA after the fact that really gave the right lenses to the business to understand the impact of some of the stuff. And that was probably one of the more interesting things of this of the transformation, actually, is we did a lot of work, you didn't really see the result. You really didn't measure the result, you didn't really know what it was until maybe like five or six months later when we really started to plug all that data in and start drilling into it and building these robust dashboards. We hired this amazing CRMA expert that came in and did some really cool stuff for us. Uh, and that really kind of got the business excited on what else we can do. Um, and so we still tweak to this day um different parts of it to kind of get the most out of it, but that was kind of how we how we went about it. It wasn't it was big bang a little bit at first, and then iteratively feature by feature, um building on what we created as a foundation.

SPEAKER_05 29:29

And in terms of like additional capabilities within service cloud, um, depending if you go customized or out of the box, you know, in terms of features, but was there any like omnichannel routing or like knowledge base, any Einstein in there uh at the time?

SPEAKER_03 29:46

At the time, no. But we implemented all with all everything you just described, yeah.

SPEAKER_05 29:50

Okay. So the project then, if if it's still ongoing in phases, we're talking a couple of years, right? This is uh quite a long-term project with ongoing enhancement um still still taking place. How'd it go? Yeah.

SPEAKER_02 30:12

Uh great from where I stand.

SPEAKER_04 30:16

Um I think he's asking more a little bit more about the journey than the we know the end result is killing.

SPEAKER_02 30:21

The end result is great, absolutely. Uh the journey was definitely rough. Um, it was pulling a lot of small band-aids off, if you can imagine, you know, a child saying, I have a boo-boo, and you put a band-aid on it and you make it feel better, and then they come back again five minutes later, like, I have another boo-boo, and you put another band-aid. Well, we essentially ripped all the band-aids off all at one time. Um, it did hurt for a little bit uh while we did it, but over time it was it became fruitful to see that it was okay to rip that band-aid off and really start from scratch and really use the foundational platform and then build on top of that using the the standard features that Salesforce offers.

SPEAKER_05 31:10

Cool. Um obviously, no implementation is a straight line to success. Um, we we we all know that. Um Andy, biggest challenge that either you anticipated or didn't anticipate along the way.

SPEAKER_03 31:25

Um yeah, I mean, there's a like the proverbial saying of changing the wheels on a car while it's driving. I mean, that that was probably the biggest challenge, right? Uh we we we were using the platform day to day actively, and so we didn't want to disrupt business. It was critical to all the revenue that we produce. Um, Service Cloud doesn't we didn't just leverage it for just cases, it was also part of our onboarding and fulfillment processes to get clients live. And so a lot and collections and every other piece. And so we needed to preserve the different workflows to support the different parts of the organization while we kind of did these things and then seamlessly have the two converge and then onboard different groups over time. And that was kind of what stretched it out a little bit, right? Like it wasn't just like a net new flush and right implementation where you kind of go live and off you go. Um, it was let's do this core transformation and then let's start bringing in all these different pieces without disrupting the day-to-day workflows of our of our business users. So I would say that was the most challenging part of it. Um, just making sure we we delivered value while um not disrupting our existing workflow and service.

SPEAKER_05 32:34

Could you um again I might be sharing some skill set gaps here, my side, uh knowledge gaps, but could you not build build in a different like sandbox um and create like a second org in the meantime? Is that what you ended up doing? If so, so like limited disruption, not put into production and so on.

SPEAKER_02 32:54

So we did we do have um, we did have sandboxes, we still do have sandboxes uh that we did our initial implementation, testing, validations. Um, but then when you have a a project of this magnitude where there's a lot of migration that we're gonna be working with, and we do go live, we had a cutover, we did it over the weekend where we don't have very many people working, we established a timeline that the platform will not be available to users. We made sure we had the least amount of disruption to our business throughout this the migration time, but everything was done in our lower environments, implemented, documented, well documented, thanks to Joe. Um, and anything that we did for the migration in the deployment itself was in production, obviously. I mean, we have to do all that in production at some point.

SPEAKER_04 33:47

Yeah, I think the core of Kira's question, and correct me if I'm wrong, is um going back to that changing the wheels while you're driving type analogy, right? So if you're developing in a lower environment doing proper deployments, why like why is that needed if it's just because of a phased rollout type thing, trying to get some ROI instead of doing a big bang? Um that's I think what you were asking, Kira. Yeah, I I that's good summary.

SPEAKER_02 34:14

Well, we wanted to do the big bang rollout so that we were all everybody was running against the same case management implementation out of the gate. And then the phased rollout pieces were onboarding other teams into the process so that their teams were getting the cases in their queue in the right way. Also, if there's anybody missing, we know that they're missing, they're not getting any work in their queue. So the Big Bang was the actual case management part of it where we derived a plan, we have an architectural schema for it. Um, and then the migration of what it is today to what we want them to see tomorrow was our Big Bang rollout. So that's something that you would have to do. We did it, we did a migration in our lower environments, everything looked great, or it didn't, we fixed it, and then we did the full migration in production as as a big as the big bang as Andy's describing.

SPEAKER_04 35:11

So um could you not like uh close out cases in the current process and do new cases in the new process and or something like that? How was your approach for like mid-flight cases?

SPEAKER_02 35:26

So any of the the cases that we had in flight, they all had a reason, sub-reason. We did we essentially created multiple fields on the records and identified which ones we were gonna flag as X, which ones we're gonna flag as Y. Um, and so when we did the migration, we knew which ones were going to go to the new type reason, subreason buckets ahead of time.

SPEAKER_03 35:52

And I'll just add one other like things complex for us is we are you know owned by a public company and we are heavily audited. And a lot of what we had within our platform relates directly back to contracting and dollars. And so every change had to be documented, and we did have some of those challenges we had to walk through. And so we were trying to deliver value. You mentioned this earlier, Dave, value to the business as soon as possible. And that was our goal, and so that's why we carved up the types of cases and the types of um different segments of our organization we would support first, right? Get them online, train them, have them adopt the platform before moving on to some of the other parts that are maybe a little more complex and maybe less value, more audit, but uh harder ultimately for us to kind of pull off. And so that that made us be very intentional about who and what groups we service and in what order when we roll things out.

SPEAKER_04 36:48

So did you um did you try to move your old cases into your current reporting structure or did you just like legacy?

SPEAKER_03 36:58

Did we? I we I think we we we converted the types, right? We closed that, we closed out an option.

SPEAKER_04 37:04

You were able to identify them. So you had an option.

SPEAKER_02 37:07

Yeah, we had we were able to identify. That's why I said we exported everything we had in flight. Anything that was closed, we closed that that stayed closed. We didn't even bother with the migration, but anything that was still in flight, um, we sat down with the team with our key, with our stakeholders, and said, okay, which ones do these fall into? Which areas? And then that's how we're gonna do the migration moving forward.

SPEAKER_04 37:30

That's a good thing you only had six open.

SPEAKER_02 37:33

Sorry?

SPEAKER_04 37:34

I said it's a good thing you only had six open at any given time.

SPEAKER_02 37:37

Oh man.

SPEAKER_04 37:39

I'm teasing a bit. Okay, so um I just pivot uh a little bit um to reporting. Um, I think you mentioned the DNA team. What does DNA stand for?

SPEAKER_03 37:51

DNA analytics.

SPEAKER_04 37:53

Right, I knew that. Um testing. So huh? No, it's for our our listeners. Um so so um so how how do you decide on reporting, right? Because obviously the case management you need to be time reporting. CRM analytics obviously is not. Um I believe you have some other tools, particularly if you have a whole team called DNA, right? Um replication, I know you guys have. So you know, why don't you tell us a little bit about how that whole thing is kind of built structured, either business-wise or or technically, and and maybe some of the decisions there? And without an afterthought or a forethought?

SPEAKER_03 38:37

Uh it was definitely more of an afterthought, right? Like it would as it should be, right? Like you shouldn't be building things to report and analyze, right? You should be doing that for you should be building it to solve business problems, and then you should have the infrastructure to ingest that data and transform it into a state where you want to do what you want with it, right? Um, and so much like our rest of our organization, our data landscape is uh old and a little bit archaic and a little bit of spaghetti with a couple of different uh lakes and warehouses spread across things. We're currently going through a transformation ourselves on that side of the world to consolidate everything ultimately in Snowflake. And so that was ultimately how we kind of approach some of these problems as well. And so while we do do some reporting on platform, we really want to do some more in-depth analysis that required data sets that were primarily in Salesforce, but also need to be married to other data sets that live in our organization. So, as an example, we use Zora for billing, and there's data that lives in Zora that complements some of the data in Salesforce. And we wanted to tie that together to give accurate lenses to our business in terms of how they were doing what that looked like. And so um, while some stuff is reported on in the platform and data never leaves it, the vast majority of our reporting we built by syncing Salesforce over to Snowflake and syncing our other data sources over to Snowflake. Uh, and then as I mentioned, we found this guy somewhere on the street who's really good with CRMA and queries and stuff. And so he kind of combined some of those data sets into a bunch of consolidated views that, by the way, have taken on a life of their own because not only used by us to adjust back into Salesforce and CRM analytics to view data with different lenses and slice and dice it and really drive business decisions in the platform. But that same data set has also been plugged into other business groups, right, that that pipe that into Tableau or pipe that into machine learning algorithms, right? And so we've created a central place or a source of truth for data that combines different data sets, but ultimately everyone was looking at the same one, maybe with a slight, maybe a slightly different lens. This way you're getting the same results. Uh, and that was been really, really powerful for organization and a pattern we're trying to maintain and continue.

SPEAKER_04 40:46

Uh awesome. You said you what do you use for replication, you said?

SPEAKER_03 40:51

Um so we use a couple of things. Copy Storm, right, is is what we use. Uh we use we use a couple of things. We have uh copy storm and own backup as well, just purchased by Salesforce, hoping to maybe consolidate a little bit on that as well. So we have a couple of different things for Salesforce for other services. There is a zero copy solution to Snowflake. Uh Data Cloud offers one as well, and something we explored a little early with Data Cloud with Salesforce. And so when we bought it, the zero copy wasn't quite there, at least not the real-time version of it. Uh, and that's a whole nother topic for another time. Um, but uh but but we ultimately did not go that way, although that is an option now. Um, and so we we we do still use CopyStorm, which is pretty cost effective uh to replicate our data. I think it's at like a five-minute delay or something like that, and gets over into Snowflake for us to play around with.

SPEAKER_04 41:42

Okay, and in terms of reporting platforms, I know you said CRMA, uh any others?

SPEAKER_03 41:47

Tableau. Uh yeah, so we have Power BI too, um, but that's going away. Um, and so we're really consolidating around Tableau and CRM analytics.

SPEAKER_04 41:57

Okay, awesome. Uh how do you uh feel about the two of those? Any preferences one over the other? Why, compare and fast? Because that's the one of the most common questions when it comes to Salesforce Analytics.

SPEAKER_03 42:11

Yeah, let me give you my honest answer to that. And so um hopefully no Salesforce AU is watching this. Uh it's a little confusing, right? Because you have Tableau and you have serum analytics, and they can kind of sort of do the same thing. Now, historically, Tableau did not play great with Salesforce, didn't embed well. Uh, it was a little bit wonky and junky, right, when you kind of plugged it in there. That's not really the case anymore. Now, serum analytics lets you do some really cool things in the platform, like doing like predict like creating alerts and then having those alerts do stuff in the platform that drives certain behaviors. We're not actually using any of that stuff, right? Like it sounds good, but we haven't really practically applied any of it. And so, like, we're really starting to ask the question of like, well, do we need both? Can we just maybe consolidate in Tableau uh and just sort of embed that back into Salesforce? What's great is how we approach this project by creating those views. And so if we did want to do, and we kept our CRM analytics views essentially like dumb, right? They're not doing anything, they're just displaying the data from those views. So if in the future we do want to switch to a tool like Tableau and embed it back into Salesforce, we didn't really lose any of the work and logic we created. Uh, we we can really replicate it fairly easily. In fact, I think we've we've done this for some from data sets near already. Um, and so yeah, I mean, uh what I would tell your your listeners between the two is you know, CRM Analytics is the better analytics tool if you want to go all in on the platform. It has some really cool features that Tableau doesn't. We just haven't used it. My hunch is we're not the only ones. And so it it it should be something to think about when deciding between the two and figuring out where to make the best investment.

SPEAKER_04 43:52

Yeah, I think the biggest thing is CRMA looks more Salesforce, but that's changing in a big way, I think. Um yeah.

SPEAKER_05 44:03

So so um in in terms of a couple of quick questions on the service cloud project, uh before we kind of leave leave the service cloud project aside for a moment. Um overall, scale of one to ten, uh one being terrible, ten being fantastic, um, looking at the bigger the full picture end-to-end, Nilam, how would you rate it in terms of success for the business?

SPEAKER_02 44:28

I mean, speaking with a biased answer here, I'd probably say eight or nine because I do think there's always room for improvement. Um, I do think is it is successful because we have clear visibility into the data now. We have an understanding of where our issues lie, where customers need more help. Um, and also, I mean, we're able to make decisions based off the data now. We're able to make decisions based off of alignment for resources. Where do we need to move our resources if we need to do some realignment with them? Um data-driven decision making is a big thing these days, and in general, and whatever market or uh area that you work in, that that's like a big thing. If you don't have data and you you can't make a decision, at least a cognitive decision to understand what you want to do next.

SPEAKER_05 45:24

Andy, in terms of um, you know, if you had to redo this project all over again, uh, what would be the one bit of info that you wish you knew sat here two and a half years later at the start?

SPEAKER_03 45:37

Yeah, you know, so it was this was probably one of the toughest decisions. And and I still think about if it was the right one. Should we have gone with a new org? Should we have just gone with a fresh org as opposed to transforming our existing org? Um, at the time, it didn't make sense to do that because our org was so intertwined with the rest of our organization, and we could probably spend another hour talking about it, that if we did that, you'd almost have to rebuild all this legacy tech debt just in this new org. And yes, you might have a fresh start in some places, but you'd still be so intertwined with other places. Um, but then at the same time, like we have like objects that have hit their field limits because we've had it for so long, and you kind of have these like you know, wonky issues that you know just an old org brings about. Um, and so that was probably like the one thing I still think about. I I think we made the right decision, um but but I still question it to this day if it was you know definitely the right one.

SPEAKER_05 46:34

Okay. Neilam, um in terms of I guess advice to other engineering leaders, similar backgrounds to yourself about going through a service cloud project, what would that be?

SPEAKER_02 46:48

Um don't be scared. Just start with the foundations. If you've got a custom org and there's a lot of customizations you've done to it that was not foundational uh to what Salesforce offers, I I highly encourage um pulling the plug and taking three steps back just to start over because the return on your investment for doing it the right way far outweighs what you're going to do maintaining the custom code that you've already built.

SPEAKER_05 47:20

Was there ever a moment during the couple of years where you thought, I wish we didn't bother at all?

SPEAKER_02 47:29

No, I was I was super excited about tearing it down. Uh, probably far more excited than Andy was, I think, at the time. He probably thought I was crazy. Um, but I I was all in on what we were doing. I firmly believed in it. You have to believe in what you're working on, you have to be excited about it. It's the only way you can get buy-in and get champions on the business and operation side of the world. Um, and so no, I I I didn't have any doubts that we should that we should not do this.

SPEAKER_05 48:00

Good. Andy, I'll ask you uh one last quick question and then we're gonna pivot from um service cloud. Um any light bulb moments during the the project where you where you're like, okay, closely your perspective on the business and how they're using Salesforce and Service Cloud doesn't predate obviously Ne Lamps, um, who was there almost from the get-go. Um so any any any coming in to a to a different organization in-house versus consulting, which we're gonna cover in a second, um, any light bulb moments for you along the way, and specifically what was it when you're like, okay, they get it now. Oh and I don't mean that like in a negative like all the skill set that let me let me backtrack. I don't mean it like in a negative way, like, oh, you know, it's not like consulting, they don't they don't get it, kind of thing. I mean where it maybe you were getting a bit of friction, and then it was like, oh, you see, like this is why the pain was worth it, kind of thing.

SPEAKER_03 49:02

Yeah, I don't know if I'm gonna answer your exact question, but maybe it'll answer the question I wish you asked me, which is I think the light, like the the big thing was like understanding the journey that like our customers and people experience and thinking about the problem from a storage perspective, right? I think maybe before we were like people would ask us for stuff and we would just do it, and we didn't have the big picture in mind when we were doing things, and that's how you ended up with this like spaghetti web of solutions. And you know, one thing I thought Newland did a fantastic job at the beginning of this project is taking a step back and just mapping out the world and then using that as to drive the rest of it. And so I don't think we did that for projects generally, we just kind of worked in little chunks. We were we were agile, and you know, agile is great, but it's a very dangerous word, especially in the world of Salesforce with cloud platforms, because sometimes you need to be a little bit more intentional. You want to be flexible, but you also want to be intentional. And to be intentional, you really need to take a step back and you know see the forest and not just the trees. And I think using that lens to solve the service cloud proje problem is also something we've used for other problems thereafter. And I think it's been really helpful just in terms of like how we engage with the business, how we build trust, how we make sure we're talking the same language, how we make sure the outcome is going to be aligned with our expectations, right? Um, even so much simple things like just draw some wireframes out of what you want that future state to look like. And so I thought everyone really did a good job kind of taking some of those things that you learn in consulting, right? That's like pretty basic stuff that you do in like the consulting world that I think we brought here and applied it, and I think made a really big difference to making sure we were just aligned with the stakeholders and the outcomes.

SPEAKER_05 50:49

Good. Okay. So so um quick questions on career choices uh at a high level. Um, Andy, uh we just mentioned obviously you were with an SI for quite a long time before moving to Ren. Um I it must be a question I get asked all the time. Um, yeah, especially especially back in the last year. Uh a lot of people that you know have been within an SI for anywhere between five and fifteen years of their career, uh, kind of had enough for whatever reason. Some have transitioned well into to end users, others hate it. Um, what would what would be your general advice to someone who's like maybe weighing up whether they should make that move or not? Like, don't bother if you like XYZ. You should do it if you like one, two, three reasons. I don't know.

SPEAKER_03 51:38

Yeah, so one of my favorite sayings, I hope I can say this on a podcast, is the grass is always greener, but dogs poop on both sides, right? And so um that that's true here. I I think if you're gonna get into tech, starting at an SI or consulting firm is where you want to start. You want to get that broad lens, you want to see a bunch of different implementations, you want to learn like structure and project management, some soft skills, like how do you approach a project, right? Um, but being at the NSI side, one thing I could definitely relate to is like it's like a really transient role. You kind of hop on a project, some are successful, some are not, you move along, you never really get to see everything fully through. And then when you're on the other side of the lens, like you read the other side of the field, you really get to own it, get to experience it end-to-end, but you deal with a whole different set of challenges and problems, right? That you that you get to kind of you know shield yourself from as an SI. Um, and so my advice to people is like stay like start off your career with an SI, especially if you're young coming out of college, go work, like I tell some of my nephews, go work for a consulting company. Like, go work there for a couple of years, and then you can go in-house and you'll have like this full briefcase of tools that you'll be able to apply to solve different problems. Um, but being at an SI forever also kind of you know has its downsides, right? You don't really get to have the full weight of responsibility of a business depending on what you're doing. People are just another customer, and whether it's a success or not, you kind of move along down your career path, anyways. And so uh there's a certain amount of satisfaction to be on the other side and see things through and really see the impact on the business and work with a broader group and be able to fully commit yourself to whatever it is you're doing. And so um start at an SI when you think you're ready, make the switch, and then you can figure out what you like more later on.

SPEAKER_05 53:31

I think um your point around the staying at an SI can also be a negative effect for too long, right? Um, because you know, I think especially as you work your way up towards the top, right? Um, in those kind of like application architect roles, enterprise architect roles, managing teams, and so on. Um did you go deep enough in one business uh to truly understand how different ERPs implement with you know and play with CRMs, right? You it's very much kind of fixed project, move on, timeline, etc. So, like you said, you're you're you're scraping a service with an SI often versus becoming as technical as you probably could be with an in with an end customer in-house. So would you agree?

SPEAKER_03 54:19

Yeah, it's something I actually admire a lot about Neil and like her level of depth of understanding of rent and its business and the nuances and our clients and the different end users and systems, like that is like a life experience of its own. Being in this space servicing PMCs and everything that goes along with it, like that is an education that you just can't get without being in this industry. And so, having had that experience, there are other folks within our industry that you can migrate to and apply that knowledge in different ways, or even ancillary industries that have similarities. And so um it's a very different core set of skills you develop by being inside of the company and understanding the business as opposed to just being a technologist that's trying to apply different frameworks and solve problems based on your own experience.

SPEAKER_05 55:06

Uh Nilam, I'm gonna um pivot quickly to you. Um Maz, you had a question? Sorry.

SPEAKER_04 55:14

Yeah, yeah. This is one that I think about a lot, because I've been almost my whole career in consulting as well, is the definition of success when you when you're internal. Um yeah, why don't you talk about that, right? Because you know because when you're in the consulting side, it's often did we get a renewal contract? That's how I define success. Yeah, so so internal, right? It's much longer, it's a longer game, I guess.

SPEAKER_03 55:41

It's a longer game, different, different game, different score. Um, you know, different stakeholders. I mean, that's the thing too, right? Like your stakeholders, your executives, they change. And like you might think you're winning, but then you get it, you get a new player on the field that has a different perspective, and maybe you're not through no fault of your own, even, right? Um, and so definitely you get those different challenges being in-house as well, if that makes sense. Your definition of you're never done. Like, there's always something to do internally. You're your your sow is never done, and uh, you know, your renewal is perpetual until it's not.

SPEAKER_05 56:20

Uh Nilam, um your describe it, uh, status in tech is very unusual, I guess, in a sense that you know, um, you've stayed with the company for a very long time, and I'm sure your phone must have been ringing off the hook during, you know, all that time, but especially, you know, 2021, 2022, when the market was booming. Um, but you know, you made the decisions today. You've worked your way up from being an individual contributor as a QA to to you know 14 years leading leading a team, and and you know, we all know you're awesome at your job. Andy talks very highly of you as well, uh, throughout the podcast. So um we do see a lot of people that do chase that extra 10 10% elsewhere on salary, right? And then 12 months later they're they're back on the job market. It was a short, short-term decision. Uh they haven't built up the tenure and loyalty with that company as much. Um, what would you say the biggest benefit of sticking around has been for you and your career specifically?

SPEAKER_02 57:19

Um, I mean, yes. They I've been with the company for many years, and I think the a couple things that keep me around. Uh, there's motivation, um, there's endless opportunities. The minute I feel bored, or I just don't feel like I'm doing what I love anymore, I have a conversation with my direct manager, and I tell that person very openly, very candidly, like, I'm bored. This is not fun anymore for me as an individual contributor. And then we work our way through finding the right things for me to work on, or we change direction, or we find initiatives that I can focus my energy around that would make it fun and challenging. Um, but I enjoy the people that I work with day in and day out. There are always ups and downs. There, every day is not always going to be a perfect day. But I also get what I'm looking for in my in my professional and personal side is I I like my work-life balance. Um, I'll there are days that we'll be online for more than eight hours a day, and that's okay, because then I know if I need to step away for an hour later on, nobody's gonna question it. That they don't, nobody has a concern of me missing an hour on a normal workday because I am doing my job. Um, there's a lot of respect and trust that goes along the way, not just with your direct, not with my direct manager, but all the folks that I work with day in and day out, as well as even my own team. Um, the folks that I work with daily to getting things done. Um there's a lot of contributing factors of me staying with the company for so long. Um, if you would have asked me when I was in my you know early 20s, um, which I still am in my mind, um I probably would have like jumped ship after three years, uh, which I mean that's what most people that come out of college do. They go for a couple of years and they jump ship, go somewhere else, you know. Um I don't I don't chase the 10k more, I chase a balance um in challenges.

SPEAKER_05 59:34

Would you say the reason you're so motivated by the role is because you've you you know the business inside out, you've you've been a part of its growth and you care fundamentally, you know. Would would someone care as much about a company if they've only been there two years? Probably not, but you know, being there 14 years, I mean, you know, without it being cliche, we don't we don't not nothing to family, but like these are people that you spend some serious amount of time with. Um, you care about them, their success, um, you care about the business because you've been a big part of that. Would you say that's keeps you motivated because there's that personal attachment a bit more?

SPEAKER_02 1:00:08

I I I would agree with that. I would say that. Um there is a little bit of a personal attachment. There are things that I I know I've done or I've worked with my team on, or my team has done, and we see the we see the outcome of that today. Um I've seen I've seen people go through many phases of their their journey at the company as well, just like I have. Um I enjoy elevating other folks on our team. I encourage them to want to do better. Obviously, they want to go outside of the scope of what they do today. Wonderful. Let's talk about what they want to do tomorrow. Um I I enjoy the the coaching and the skilling up folks. Um, I think I just set a different bar for most people. I set a different bar for myself. Um, and it's usually a high bar. Sometimes I probably set the bar too high, but that's okay. Um and I probably set the bar high for my team, and that's okay as well. They'll tell me to get grounded a little bit. Um, but they they're up for the challenge.

SPEAKER_05 1:01:09

Good. They have to be. There's no they're not allowed otherwise. Um so last question to wrap up uh today's recording. Um agent force. Is that something that's on the roadmap for the business going into more of 2025? Uh Andy.

SPEAKER_03 1:01:30

You know, we're we're it's a very timely question. We're we're definitely look we're literally looking at it like as we speak now. Um, we have some use cases for it. There's also some competing technologies outside of Salesforce that our company is looking for looking at where Asian Force would probably be a really good fit. Um, and so the the short answer is yes. I think it's a it's a great product, right? That's the future. Um, is Asian Force the right product to for us to get it there? TBD. I think it goes back a little bit to what I said earlier, which is like it's not a service platform, but it's all part of the same thing. So maybe the answer is simply yes for that reason. Um, but we're looking at it, we're looking forward to leveraging it, doing a POC on it in the near term, and and hopefully um getting value out of it.

SPEAKER_05 1:02:15

Awesome. So watch this space. Um, all right. Well, uh that's a wrap. Uh thank you, Andy and Nilam uh for giving us your time uh today and sharing your story. Uh a bit of a unique first for us on the CRM Success Show. It's our first uh episode where we've had two two guests, so thank you for bearing with us. Uh, we really appreciate your time.

SPEAKER_02 1:02:35

Thank you. Thanks for having us.

SPEAKER_05 1:02:38

Uh for our listeners, please do not forget to subscribe to the CRM Success Show for more episodes featuring amazing leaders uh who are shaping the future of CRM. Uh you can follow us on LinkedIn, YouTube for latest updates and exclusive content. Thank you.