SPEAKER_00 0:02

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 Monstri 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 listening.

SPEAKER_03 0:29

Welcome to the CRM Success Show, where we deep dive into CRM success and failure, delivering real stories with real impact. I'm Dave Mastery. And I'm Kira Witzi. And today we're talking with Niroz Jane, the global head of strategic partner platforms at Mercedes Benz. So uh welcome Niroz.

SPEAKER_02 0:45

Thank you.

SPEAKER_01 0:46

Glad to be here.

SPEAKER_02 0:48

We're glad you're here. So thanks, Niroj. Um so so just give our listeners uh a bit of context about you and your your background. Um I I know you've you've worked in the Salesforce ecosystem for a long time, but um a brief background uh of your experience today, please, Niraj.

SPEAKER_01 1:04

Sure. So uh the two strategic platforms at Mercedes Benz Mobility, which is the finance side of the major leader finance side of, we are using Salesforce and Museoft to do four operational areas: the automation and agent uh desktop or workstation replacement with Salesforce. These areas are collections, credit, uh general customer service, and something what we call as retention remarketing. When you acquire a car from Mercedes, we finance it, and when the lease is over, we would like to send you another Mercedes-benz with our financing. So that's the remarketing part. And this is being done globally, about 38, 40 markets, three regions. We are live in America's uh your project is ongoing, customer service is being done in Asia, two markets uh will be scaled further. Um, so that's my responsibility area. I also have a little bit of Pega and Azure responsibility. We are using Azure for data factory data migration to into a data lake kind of capability there. And Pega is our previous collections platform that we will slowly be replacing with Salesforce. Before Mercedes Benz Mobility, I was at Cred Suisse in their capital markets, global markets uh uh vertical. They have two large Salesforce instances. I was focusing on one, architecture and setting up a delivery team. Before that, I worked at JP Morgan Chase in a similar capability, architecture and delivery capability build-out here based in Dell and Legacy West in Plano. And um their goal was to have a vertical, they had a commercial banking division, which is a large bank inside of JP Morgan Chase, and there are five banks within it uh which do you know from retail, cash, uh, auto, other financing for a certain mid size of clients, right? And there we were replacing CRM and it was uh part of a large transformation project. So Mercedes-Benz and JP Morgan Chase both were large transformation projects for us. The technology selected was Salesforce. Before that, I was at Salesforce in the advisory services when it used to be called that, and I had two large customers, including State Farm, which is uh which is known to me as the largest Salesforce implementation ever. The first launch we had about 90,000 users, and I believe they are over 200,000 users now. It's a wall-to-wall approach for state farm. Uh, but all state farm 18,000 agents were launched day one uh with Salesforce as their workstation to service the customers. So that's my Salesforce scope. But before that, in my past life, I used to be a developer, I did a lot of.NET and Java, and before that, I had a lot of power builder work. And I have also done a lot of middleware integration tool kind of work, BizTalk and Web Methods, and Azure Service Plus, and to name some few. Lately, we've been using MubSoft for Salesforce projects. So overall 30 plus years of experience in IT, um, delivery and architecture both. Um, but uh architecture is close to heart.

SPEAKER_02 4:16

Fantastic. Um you you mentioned as well during during your uh intro, but you spent four years directly at Salesforce itself as well.

SPEAKER_01 4:25

Um State From project was through through advisory services while I was an employee of State Form, yes. Uh state employee of Salesforce, sorry.

SPEAKER_02 4:34

Fantastic. Um so some of your projects, I mean, have been hundreds of millions in terms of spend, right? Very enterprise, um, big focus on financial services, and and that that is a theme that has continued into your current role. So um would you mind telling our listeners uh a little bit more about the mobility angle or or I guess company aspect of the broader Mercedes-Benz group, please, Niraj?

SPEAKER_01 5:02

Yeah, I I was new to this term and I had never heard that term before. Uh we all of us know Mercedes-Benz, we know it from dealerships, but we also know there's a manufacturer, the OEM, that makes the car, designs, and makes the car. That's the second leg of it. The dealerships are this the network, but there's the manufacturer and the engineering team. And there is a third team that gets the customer into the vehicle and keeps them into the vehicle, services them, and makes sure they can return and stay with the brand. That's the mobility part they call it. But financing of the dealerships and the buying the leases from dealership for the retail customers and servicing them and even repackaging them and reselling them in the wholesale financial markets is what the financial part, which is a large part. But mobility also does other things like charging network is being developed under mobility. There is a fleet management company that does white labeling for other brands other than Mercedes, and then there's um you know ride hailing companies with other companies and some other subscription-based car plants, you know, things like that all fall under mobility. Anything that is not to do with designing and manufacturing of the car is handled by the mobility piece. Uh, in America's, we are loaned as captive finance, and there are every almost almost uh every um car manufacturer either has their own captive finance, and sometimes they white label with with the finance companies, they do multiple brands financing for multiple brands, right?

SPEAKER_02 6:32

Fantastic. And and um your role title strategic platforms. I was I was curious. Um, what exactly do strategic platforms entail? And and is there a process internally for defining what is strategic and what's just a normal platform?

SPEAKER_01 6:48

Yeah, so so normal platforms in finance companies could be.NET, uh could be homegrown, a lot of homegrown angular.js kind of applications. Um, and not a single platform, right? Uh, you could have a.NET application also, and each application is funded as an IT application and built, and then a lot of services or microservices published and consumed, and you get a spaghetti mesh of things, right? Um, the strategic part comes where companies decide to, and AWS is a good case study on that, that they went from microservices to now monolithic platform, they're calling it. So they um something similar is happening with Salesforce large customers. They have tried .NET, Java to other lot of other vendors too, SAP and Pega. So Pega is was a strategic platform for us. We are moving away from it. But strategic means that companies are trying to get away from custom development business and um have a limited IT business, but focus on business and business goals and the business requirement, have a low-code, no-code development platform, and have an agile, fast delivery of business requirement and go lives within a year or year and a half maximum of start of a project to actually launching a large product that can actually censor an existing product or set of applications, and that's the transformation. So State Farm was similar, uh, they had mainframes and other systems. Um, we have mainframes here which we replaced last September, but there are a bunch of applications in the list, save like 40 applications needed to do credit business, or 80 applications needed to do credit business, and each country having their own local systems. So strategic means have a limited number of platforms, uh, freeze all other application developments, and slowly, as the funding becomes available, rewrite them into Salesforce and use of another related platforms, and not uh not expand the usage of legacy applications or those technical platforms. Mostly these are you know JavaScript, .NET, Java-based applications, home grow.

SPEAKER_02 8:58

Fantastic. And um, I was doing a bit of research um earlier about the mobility arm of Mercedes, and just to put a few numbers out there from the last couple of years. Um, revenue, and obviously you know better better than me, but uh according to my Intel, revenue 30 billion um dollars goes through um the mobility arm of of the business. It employs over 10,000 employees worldwide um and finances over five million vehicles um worldwide as well. So this is a big group within Mercedes, right?

SPEAKER_01 9:35

Which you've never heard of before.

SPEAKER_02 9:38

Never very cool. Um and and then my last question for you uh about your kind of you know about you for now. Um what does your team look like in terms of team size now now, like in terms of like numbers of people, where they're based? Tell tell us a bit about kind of your role, team size.

SPEAKER_01 9:59

Yeah, so our biggest presence was Europe, um, including Salesforce Europe advisory, big part. Um, large advisory presence still in Europe. We've been moving from Europe to offshore locations, so Latam and India, but still staying with Salesforce. Uh, we had other vendors too in the mix, but uh, because of the skills and the newness of the AutoCloud product, we wanted to be working very closely with Salesforce, so we have gravitated more towards Salesforce. Uh so the largest presence is offshore location, about 100 consultants, but then the next location is uh again Salesforce majority, some employees in Europe, and then a very small footprint in America is about five, six people. And I'm talking about technology side, we have a decent product team size as well from business.

SPEAKER_03 10:52

Okay, wow, wow. So you covered you're covering a lot here. Um just to run down what I've heard you guys are doing this in Salesforce, right? Financing or a big part of the financing management, um uh ride hailing, charging stations, service, um you're dealing with dealers as well as end customers, and not to mention your user base. Um so how did you now I know you came in this later, but is this like all in a single Salesforce org?

SPEAKER_01 11:26

No, so yeah, so I was just trying to describe what MVM does, but ride heading is not a Salesforce related platform or product. Um the four areas that I describe the you know, the collection, remarketing, credit, and customer service will be Salesforce, and we are doing pockets of it, you know, two years to two and a half years into it. So, you know, another two and a half years to go before we got all four areas fully done. We have retention remarketing part in America's and the credit part done. The customer service is being done in Asia first, and the dealer part is being done in Europe first. Uh, we haven't done customer end customer facing Salesforce yet. That will come.

SPEAKER_03 12:09

So though though there are different Salesforce orgs per region?

SPEAKER_01 12:12

Mobility has only one for all regions. So all 38, 40 markets will be on single instance of Salesforce. They are currently on single instance of Salesforce.

SPEAKER_03 12:22

So how do you how do you deal with things like GDPR? Like you keep everything in Europe, even if it's global?

SPEAKER_01 12:29

Yeah, the so we started with America's instance, as we speak, it's being moved to Germany in the Hyperforce instance. We were waiting for a financial services contract to be done for Hyperforce, that's been done. So the Hyperforce migration will be directly taking US-based instance from Virginia to Germany-based Hyperforce instance. And then Europe.

SPEAKER_03 12:51

I assume. That's interesting.

SPEAKER_01 12:56

Any any downtime, or they just I mean, we I had similar client Chris Suisse before it almost similar 3840 markets, and the the base was if you host uh somewhere like in Switzerland or Germany, then that location is acceptable to most countries, including Asia. So we we do go through market to market, do a legal review, and then there are a couple of standouts in Europe, a couple of standouts in Asia and America's there's not much privacy of data. So the it's very lenient. So any generally a German or a Swiss location is worldwide quite acceptable to most countries.

SPEAKER_03 13:37

Um I mean I was asking about the server move. Is there a downtime when Salesforce needs you to move?

SPEAKER_01 13:41

Four hours. Hyper force migration from US first party data center to a hyperforce would be four hours is one game.

SPEAKER_03 13:49

Um not bad.

SPEAKER_01 13:52

So it's different than a site switch, right? Site switch has within US we have a backup location. We don't even find out, Salesforce doesn't even communicate or maybe gives an email heads up. But there's zero outage. But for from a first party or legacy data center of Salesforce when they when they own the hardware to hyperforce, it's a four-hour outage downtime. According to Salesforce. Tell us. Sure. So the biggest advantage is um if if say this company has three large legal entities, they're all dealing with the same customer in three different ways or four different ways. They're all sending them emails. We don't know about each other's communications to the customer. And I don't want to make a SysFor switch here, but you know where it's going. It's the 360. Them having to be on the same platform and same instance, or maybe now connected to data at cloud, data cloud, would really make a big difference. These companies have a as part of transformation a CX strategy, right? They want to give a luxury experience to the customer and a not a disjointed experience that you're not getting emails from sales and marketing and finance and roadside assistance, right? And all talking about different things, right? And they're all talking about the same leases or cars you have, right? So that's the biggest advantage across the firm. Um, and then if you talk about just different parts of service, right? Customer engagement, could it be for collections, for general customer service, for road size? If you talk to one agent and you had another query for another request you had with the company, the agent will have to give you a different toll-free number to call. And that's not a good customer experience. Um, and then sometimes customer service also generates leads and that needs to be sended over to sales and marketing. And if there's a completely different legal entity and completely different instances of Salesforce, or maybe one per country kind of instances, then and there is not much handshake happening between these entities. Different toll-free numbers, different letters, different emails coming from as if you're working with different companies, basically. So there is a lot of synergy in bringing the same entity or multiple entities in multiple markets on the same instance because you get one view of the customer, but also the customer gets a consistent unified experience, and it is very important to modern-day enterprises the the experience customer is getting from them. So it avoids uh on the IT side or on the cost side, it avoids a lot of integration efforts. Uh, you are on the same platform, data is available, you can use experience cloud for dealers, you can use experience cloud for customers, and you can use the inside uh agent consoles, right? The service consoles or sales consoles. So everybody is looking at the same data models, same data, same instance, and then your chatter. If you're a I'm a big fan of chatter old days from Salesforce days, um, maybe you're doing Slack, but if you're on chatter and you're talking to from one of the customer service areas to sales and marketing, you can you can just admission somebody and say, Can you look at this case? Can you look at this lead, or can you look at this approach to the right kind of situation? So huge, huge, huge cost savings in terms of integrations. And integrations are the long hole in the tent of Salesforce implementation large companies. The the Salesforce part gets done in three months, six months. The other year is spent on integrations and data migrations. So more applications, more departments, more lines of businesses you can put on the same instance of Salesforce, uh, the less is the cost and the delays and the duration for Salesforce implementation.

SPEAKER_03 18:05

So I mean, talking about integrations, right? Obviously, you're in different markets. I'm assuming these markets all have different systems, let's say the financing system within the individual markets, right? Um, and then you have to integrate that back to Salesforce, I guess, to a common data model, right? So how do you like how do how do you do that, right?

SPEAKER_01 18:30

Um that's where I mean that's where MuleSoft comes in. That's why that's the main reason Salesforce bought MuleSoft, right? Because, and I'm gonna talk in terms of generalize it, but middleware lingo a little bit. There's a canonical data model definition inside of a middleware tool. That's what's synthesizes across variations in markets and regions and lines of businesses, but between something like a mule soft and Salesforce, it's a consistent view. That's the key to the success. So all things handle the variations in the edge adapters of MuleSoft, again, a mule soft term here or a middleware term here. Let the middleware tool handle the differences and let the solution be very consistent, reusable, single apps, single solution globally within Salesforce. I mean, it's a nirvana ideal state, uh difficult to get to. And you know, some customers can afford something like Informatica Cloud or in MULESOFs, others may not. But I highly recommend that handle the differences in a middleware layer and get a middleware layer that is not Java coded but configurable again, like Salesforce is low, low code, mule soft is also low code or no code. So that's the the recipe, uh, if you ask me.

SPEAKER_03 19:50

I mean, Mealsoft is obviously a good choice for this because you can build those layers of APIs, standardize the APIs. Yes. Um, I'm assuming you're standardizing pick list values and things like that, all within the MuleSoft API layer, right? So I guess you have an API per market, and then that goes to a core API, and then that plugs into the not even not even that.

SPEAKER_01 20:10

It starts at what's the definition of a customer is account and a contact. You you need to define that across all markets, all regions. And if you have a contract management system from a third-party small vendor, then you might have multiple of them, like in the first question. Then you need to commonize whole CRM data model, starting with the account object and the contact object. Right? What do you call a dealer in one country might mean something different in another country. So that is the homo, that's the part where the data architect role comes into play and then their knowledge of Salesforce is important. And then working with Salesforce product managers is also very important. Make sure you're not defining a lot of custom data models, even though it's no code and configuration. But if you don't store the Salesforce information for your business domain in the right objects of Salesforce, then you're highly customized still, even though it's through clicks. So the data model is the foundation, as I understood, for Salesforce.

SPEAKER_03 21:12

Yeah, I mean, uh it's a little bit more than the data model, right? It's it's I would say the data governance too, right? Um, maintaining that unity of definitions, right?

SPEAKER_01 21:21

Yes, just and and we can talk about governance, it will require another 45-minute discussion. Um, a lot of companies are moving away from governance. The word governance has become a bad word, unfortunately. So, because it slows everybody down, it's the perception in the large enterprises. So they're trying to move away, trying to hit a hybrid approach, not agile yet enough. And the governance world actually slows them down. So it's a degree of uh you know at what level you want to govern the data model at, and then what at what level you want to give a lot of leeway to project teams so they can deliver fast, right? So there is a level And layers of data model that should be centrally defined and then a lot of flexibility to business to do the other 10-20% that they need to get done.

SPEAKER_03 22:10

Okay. So, I mean, honestly, honestly, uh, that's uh a bit of a surprise to me. I did not know that data governance is becoming a bad word. Um, shame on me. Maybe I can't I think governance, governance.

SPEAKER_01 22:23

It could be architecture, it could be Salesforce COE. I mean, those are the terms I see companies are afraid of and moving away from it.

SPEAKER_03 22:30

But you gotta have standardized KPIs, right? Um, doesn't the C level suite want to know global stats? And don't you?

SPEAKER_01 22:38

Yeah, so the product teams are responsible for them, defining them globally. That is true. Um but what I focus is on the technology side and the architecture side, and data model is a practice within data modeling, is a practice within architecture, and that's where the business looks at the IT side of governance bodies as the blockers, to be honest with you, right? If those are the things that they are worried about. The main first question you had business versus IT. Yeah that's the crux of it. That the if you have a large three-level architecture board and it takes you two weeks each to go through three of them, then um nothing gets decided for a month and a half, and that's not something business can afford these days. That's the governance piece I'm talking about.

SPEAKER_03 23:25

Yeah, what are you um go ahead, Kira? Sorry.

SPEAKER_02 23:27

What what are you what are you seeing internally, uh New Arch in terms of like buzzwords or or titles that they're calling it? Because you also mentioned you know COE is is kind of phasing out a little bit as well.

SPEAKER_01 23:39

Um what what are you seeing replace it with with um so if you so large companies who come from waterfall background in finance, they use safe method quite a bit, right? Um street from us big on safe and so is Mercedes. Uh the teams that are new might sugarcoat and rename their ceremonies to be safe, named after safe ceremonies, but they are still waterfall, meaning integrations are not delivered within less than six months, so that's still waterfall. That's where hybrid kicks in, and safe try to support it in the hybrid mode. But what I'm seeing is the the appetite is very low on on waterfall, and business wants changes done very quickly, and the applications rolled out quickly, enhancements done quickly, and and the issues fixed very quickly. And that that can be supported with SurSforce being a low-code, no code platform and a configuration-driven platform, and you're not worried about infrastructure. So a lot of goodness of SaaS there, but also agile adoption is increasing, meaning pure agile adoption, and and that brings us to the automation part quite a bit, right? The CI CD and the test automation is very critical. If you want to make two releases a week, um, I mean, large companies make nightly releases, right? We know that. And Googles of the World allow developers to drop code in the production live, right, at any time of the day, right? So if you want to make uh business enhancements and deliver them weekly or even more rapidly, or at least two weeks at the end of every sprint, then you need to have a lot of test automation. And that requires a mentality change and away from manual testing and all that, build a regression suit, build a performance test suit. But once you do that, then the business really values what IT does. Um really rapid delivery and the Americas part we did, we did it that way. Um, the week we went live, all dealers switched in America's Canada, Mexico, US to Salesforce for credit application processing. Um, they process billions of dollars of credit every month. Um, zero outages thanks to Salesforce and Muse being sales-based products, no more data center issues for us. But also the test automation allowed us to do two hotfixes in the first week of Go Live. And zero testing was done for those two hot fixes. Everything was 100% code coverage with automation. So that's once the business gets the test of that, they're not going back, right? And that's what is needed, I believe. Um, Salesforce can be done manually in production directly as well, right? In a very low-end setting. And then the highest setting, you could have Git and all things, CI CD and Git Actions or whatever, but test automation with you know Perkins or Selinum and other frameworks for Salesforce, you can really drive that value to the business. So the answer to your question, link it back to the first question. Yes, business is driving these transformations, but IT has a key role because these kind of automations and these kind of architecture decisions cannot be made by business. IT has an important role to play.

SPEAKER_02 26:54

Fantastic. Um, I want to pivot slightly, Neeraj, into um some kind of big, broader uh questions for you. So your track record for delivering large enterprise Salesforce projects successfully speaks for itself, right? Um you've you've you've done it time and time again throughout your career, Credit Suisse, JP Morgan, State Farm via Salesforce. Um, and obviously you've consulted with big five consulting partners prior to that as well. Um what are what are some of the general challenges or or let's say like top three general challenges you encounter when you walk into a large enterprise Salesforce project? Um you must see like you must almost have like deja vu. Uh I've seen this again. Where was it? Okay, this this client, same thing, same scenario. What are those general challenges that you walk into?

SPEAKER_01 27:48

Well, when you walk in, there's a lot of excitement about the new initiatives, new transformations. Um, the the folks from legacy side are it's not lost on them, the failed attempts in the past. So they do have some kind of uh doubt in their mind, and they might have been in their local data centers. Now it's going in the cloud and they have a fear of losing the control over or the job profiles are changing or skills are changing. So that's one part I see. But the biggest part is uh um when you put up a hundred million dollar transformation project or or a set of products to be built as part of that transformation, we're talking about three three arms or three legs of it, right? There's a cultural transformation, there's a business transformation, and then there's a technology transformation or IT transformation. A lot of times people will focus on the IT part of the transformation, meaning a complete change of platform, can be itself called a transformation. If you end up doing lift and shift, then it's not a transformation, not even on the IT side. If you just did a lift and shift, uh, you have to question the requirements, and business has to do the business transformation, meaning get rid of the country variations as much as possible, get rid of the regional variations as much as possible, fold as many applications you can into Salesforce, write those. But the cultural transformation is not somebody that we are directly tasked with, but it ultimately we run by it and we run into it and we suffer through that as well, right? Because it brings a big mind shift, right? Everything is in cloud. Developers can sit anywhere, and work can happen anywhere. That's a big mind shift, right? People are not in your office, not even in your country, right? Uh few C's apart. So that's a big mind shift. That's the biggest challenge I see. It's the uh that the people have to consider all three are part of the transformation, the culture, the business, and the technology. Um, and then the knowledge, right? You have to hire the talent. Some talent you cannot purely rely on an SI partner to tell you what you need to do, and they may not have the domain knowledge of your business, and you have no expertise in Salesforce or Museoff. So you do need to hire people from the industry who have done this before. That's another key of the recipe. And then the third one is you have to manage the cost of licensing and delivery quite aggressively because things can go out of hand very quickly. A six-month project could turn into a year and a half, and then you are running out of money, right? So that's the third piece that I see a lot of challenges in.

SPEAKER_02 30:23

Um, it's interesting you mentioned um changing of skill sets, right? Um Maz, I know you had a thought on this as well, but but um you going from one system to another most of the time, right? You've got a skill set that's been embedded into an organization, people that have a different technology background that then have to go on that journey with the business at the same time. Um and you know, if you if you flipped it on its head, and and let's say you were doing a uh a migration the other way from Salesforce to another product, how many of that team would actually want to lose all the years of experience Salesforce have been building to go and work on another product? I would I would probably estimate less than half.

SPEAKER_01 31:07

Um would be willing to 20%, more like 20% are willing to learn and something. There is no, depending on how your setup, how your performance management cycle is, you may not have the incentive to completely unlearn something. I mean, to learn sales force, you to really unlearn the.NET and the Java part, right? It's a true story, and and we can talk about that in a separate call. But to unlearn something and and to learn something for a year or two before you can call self yourself architect again, for example, that's not that's a daunting task for most people. And I would say 20% is a stretch. I would say more like 10% of the people are coming with that open mind. And the rest of them want to hold on to their roles, but may not be willing to make that time commitment, right? I I remember doing three certifications for Salesforce when I was an Accenture voluntarily because I've been doing.NET, Java, Sysaps, Sebul for way too long. Um, wanting to develop an industry vertical domain as well as uh some newer skill, uh uh niche skills, uh, where there's less competition. Um, so SaaS was the one that came across. I spent a year and a half doing three certifications of Salesforce. I tell people that it will take them at least six months, and people do not think that they want to invest that kind of time, right? Yeah, but it's at least a two-year journey to switch from .NET Java to Salesforce, but it's a very rewarding one, financially speaking as well. But not many takers. Um, if you have a job already and just a new platform is coming, then you might feel entitled to just be uh allowing you to do that project even without the skill set, right? And that's a challenge too.

SPEAKER_03 32:55

Yeah, so you've been doing system architecture a little bit longer than me. Um, I started I graduated school in like 98-ish, right? Um and I've been working in tech throughout college. Um, and back then the big thing was obviously uh LAN apps or local apps, fat apps. Um and the switch to the web was tough on a lot of people. A lot um almost as bad, but not as quite as the switch from mainframe to networks, although that was pre-my time. How though I I don't think you've lived through the network the mainframe switch over problem, but definitely.

SPEAKER_01 33:33

My first job was cobalt programming. Oh wow. Yes, I'm boring. I'm low welfare. Just doing it myself. I just did it myself. Oh, cool.

SPEAKER_03 33:44

So I was I was gonna ask how cobalt programming. Cool. I I took cobalt in college, believe it or not. It was a course was offered. Um I used it once to read a piece of code to translate it, and that was it. That that's my entire career in cobalt. Um so yeah, yeah. So so how how would you compare the twitching from you know, let's say, you know, web-based ASP ASP or Java, I assume you mean Java web, right? Over to Salesforce. Yeah. Okay, compare that right even to mainframe if you can.

SPEAKER_01 34:16

I mean, the browser is a dumb terminal, if you if I can call it that, accessing Salesforce. So the main part is the middleware, the middle layer and the back end layer is changing. The web layer is replacing the dumped the green or the blue screen or the black screen of the mainframe. Much user-friendly. You can copy paste, you have cursor, you have um a lot of other things available in a modern browser. JavaScript is very powerful. We all know the power of the web-based applications, uh, be it single page interface or otherwise. But the the biggest switch, uh, the biggest benefit, uh, I mean, it's it's almost unfair to compare mainframe with Java.NET. I mean, Salesforce is kind of built on Java, right? So it's it's that, but it another you know, 4GL, 5GL or whatever we want to call it. Salesforce probably is a 5GL system. But um mainframe, you know, you you you had flag files and and you had the four programming sections available in Cobalt defining your display section and the file section, and some some very FL-basic logic you could do. And the terminal was not very user-friendly. And there came the Power Builders and Cybase of the World, where they and we Visual Basic, right? They built the FAT clients and access database if you are using a local database or a color cybase or SQL server. Uh, and that was the your three-tier architecture. Um, Power Builder, even had object-oriented programming, very powerful. Then came the ASV.NET and JSP and those pages. Uh, HTML, very powerful again. Uh, you can get Chris very easily get the cross-device, cross-bowser support, and the whole worldwide web happened. Um, again, still hard you have to write a lot of code to connect to SQL Server or ORECOL or Cybase, and and and you have to still write business logic, data access logic. And then comes this platform like Surseforce, where you go and you define your business domain as an account and the contact object is already there, but you can add a vehicle. Now, vehicle is also there, financial agreement is also there. So, most of the domain data model is already there. You're adding some additional objects through clicks. You don't have to worry about uh you know deleting tables and recreating them and saving the data, remark, re-migrating them. If you add a new field or you change the name of the field or data type, that the all the back-end data operations are taken care of by Salesforce for you. So you're getting an out-of-box data model, you're getting a lot of data, you don't need a DBA with no due respect to DBAs. Um, and what you're doing is as a Salesforce developer, you're talking to a BA or a Sys business user, and they're saying, I need these kind of reports, and here are the reports from legacy system. You're figuring out what fields are there, what fields are not there, you're doing data mapping, you're figuring out your data migration approach, you know you need to make some integration calls through APIs, you can call them from Salesforce or through a middleware tool. But most of your time is you're designing a flow graphically. Uh, you might have to write a formula field or even FX to do some calculation if it is more complicated. But you are able to show the next day to your business what they describe to you today. That's the power of the platform, right? So under the cover, Salesforce is like a hibernate kind of framework if you ever work with that or and hibernate on the .NET side. You are defining your domain, and the UI and the data model and the app layer and the data layer all are being generated for you. And Salesforce has a nice UI. Uh, some people click uh complain about the clicks to get to child objects, but otherwise it's a good UI. A lot of drag and drop capabilities, plus, you got app exchange. So things like DocuSign, you can you don't have to build an integration with custom UI for that. You can DocuSign has done the work, you can drop that into your interface. So very powerful. Thousands of applications in the App Exchange. I mean, it's the equivalent of you know, Play Store or App Store from Apple and Google for the consumers, is the business version of it. Um, the the main challenge that if Salesforce can solve remains in the integration data migration space, unless the client agrees to do more with Salesforce as a monolithic platform. So that's been my journey. Uh the moment um we used to do a lot of Java and data development in when I was in Accenture IT team. And the moment I come across saying we're gonna replatform all our sales application to Salesforce or something like that, I was part of the team that's selecting the platforms. The way I understood Salesforce, that it was running the 30 API versions or 30 engines of the different versions of Salesforce in parallel. So if you build something with version 20 and then you grow that application, next day it could be version 21, and then now it's whatever 50-60. All parts were running in parallel. You never had to go back and upgrade your previous code or page to the new version. In Accenture, I saw projects for SAP upgrades that took two years. Wow. And then when I came to Salesforce, the upgrade was zero downtime. I mean, some down used to be some downtime, now it's five minutes. And next day, your most 99% of your app just works. When I looked under the cover of Salesforce architecture, I was mind-blown with the metadata concept. I heard the term metadata for the first time, and then I learned that Salesforce doesn't actually have these objects in the physical data model, they're all JSONs or XMLs and abstracted in various layers. And somehow Salesforce can get the better performance than Oracle itself can get from Oracle database, even though these are not physical tables in Salesforce. I was just mind blown, right? And I spent that year and a half learning Salesforce just because the you know the love of uh the architecture change that Salesforce was doing there for me. We had a server farm of 30 web servers. I had to stay awake over the weekends for after application deployments to check every server to make sure the app is running on every server and the load balancing is still working fine. And we had to change our load balancing algorithms so many times, and we had so many issues working with Akamai for remote countries for Accenture. Once I came across Salesforce, I have not looked back. And I think people who have not taken this journey towards SaaS, I think I highly encourage them to consider it.

SPEAKER_02 40:44

Do you do you think again a quick yes or no? Do you do you think there's still time to make that journey or as a ship sailed to move into SaaS?

SPEAKER_01 40:52

No, I mean companies have to do it. Most companies have Salesforce instance, maybe a small one, but every company that can be sold Salesforce has been sold Salesforce. It's just the degree of usage and which departments are using it, and how many have their own admin in the business versus in IT. But everybody has Salesforce, and it's just the size of the implementation or footprint. But from an IT side or even from business side, I encourage more people to train themselves. Trailhead is a great resource, and and even if you're in a business domain, you could have a potential career in technology thanks to Trailhead, right? So I've seen people make that switch either direction. People, IT people became product owners and product managers, and uh business users became you know configurators of Salesforce platform or admins at least, right? It's not a choice, it's a SaaS is uh I mean maybe the AI and Gen AI and agent the agentic models will change that a little bit again. But Salesforce had has an advantage there as well because they got the CRM data already.

SPEAKER_03 41:59

Yeah, I just want to to point out the reason Salesforce gets their performance is because they uh I'm thinking they're some more tongue and cheat, but they cheat. Um and they do that by forcing you into Sokol, which really limits your ability to write really complex data queries. Um and then it uses much less CP much less compute. And then that's why you spend so much time writing code to keep your relational integrity in place, right? I have to write a workflow to update the account field when you update the child field, and all that is to restrict the CPU and keep everything running fast. It's very intentional that they're they call it a relational database, but it's really not. It's somewhat the normal.

SPEAKER_01 42:38

It's not it's the object uh it's the JSON serialized, deserialized into blobs, right? Or data is stored as blobs. Um but but recall in SQL, Cybase, and Oracle, I work with all three of them. You had to write triggers and whole business logic was dumped in the trigger, database trigger. Talk about data governance, right? You don't should not have any logic in the data layer, right? And the stored procedures were thousands of lines of code, and the whole business logic was in the two-layer architecture, right? The database had the logic, and then you had another fat uh UI layer or something. So we have made we we come a long way, right? With microservices, SOA, microservices, and now SaaS like platforms like Salesforce. We come a long way, but you're right, there are things to be desired still, right?

SPEAKER_02 43:27

In terms of um enterprises, so go going back to so we see you know leaders, they might be stepping into that enterprise landscape or environment, I should say. Uh perhaps their business has gone through a merger or an acquisition, then they've got bigger, um, or or perhaps they've just made the career change, right? They've had an opportunity, they've done, they've proven their trade at a mid market customer, and they've got an opportunity at an enterprise business. What are the a couple of things? Um, what are the absolute Not to do actions they should take um when when transitioning to a large enterprise uh organization and implementing Salesforce based on your experience, what should they absolutely not do?

SPEAKER_01 44:11

From an employer perspective or an employee perspective?

SPEAKER_02 44:14

Let's let's say one for employer, one for uh employee.

SPEAKER_01 44:19

Yeah. So um, you know, not everybody gets lucky with a greenfield approach, right? Um, we use the term brownfield as well. These transformation projects, I've been lucky, were clean slate, meaning the companies have tried other things, custom or other platforms, and they were saying now we're gonna do with Salesforce, and this is our last try. And if you arrive in those programs at the right time, then you're doing Salesforce from scratch. And if you do get that lucky, and I've been lucky that since, then take the opportunity to do the sprint zero as we call it, right? This in agile world, build the architecture foundation, get a middleware tool in place, get your services right, so that then when you start after six months of foundational work, when you start building business functionality, then you can deliver every two weeks. And maybe six weeks is not six months is not realistic, it's more like nine months. But first MVP out in nine months, but you spent good time in those first nine months building the architecture foundation. Don't take shortcuts there as an employee or as an employer. Uh, invest that time, and then you can have a good payoff in you know 10-15 years of using that system. Don't have the pressure to build something custom, quick, and dirty and launch it in six months, right? It doesn't work in an enterprise place, it's a recipe for a redo. You can use it for demos to business and sell more, get more funding with it, but it's not a usable system. You know, you might have to integrate with 20 other systems. Uh, so that foundational work is very important. Sprint zero, we call it. Um, so that's my one advice for sure for both employees and employers. But if you're making a switch, um, make sure you understand why to invest in the proper automation for CICD DevOps. Make sure you understand why you need to invest from day one on test automation, regression, and performance both. And again, that's the second thing. Don't cut corners there. Actually, you will face a lot of objections about you're looking for the best ideal architecture or beautiful things to do. Actually, that is the cheapest and the fastest way to do this transformation project. Get your foundation right, then you can really go fast and agile. Otherwise, you will have challenges from going from one market to another, one line of business to another, if you don't have these automations and DevOps pieces taken care of.

SPEAKER_02 46:45

What would be um your one bit of advice uh for an em uh for a company uh that are implementing Salesforce, uh, let's say a financial services uh business, because a lot of your background's been in that industry. Um, just one bit of advice that you would pass on uh based on your years of knowledge of successfully implementing Salesforce.

SPEAKER_01 47:07

Zero customization. You as an employer who's funding 100 million or 10 million or whatever for the project, you should demand that there should be a zero customization. That means map it to standard data model of Salesforce. If you need to create custom objects, you need to justify that in a some some kind of light governance architecture mode. Quick decision making is very important. And the second one is no apex coding, no JavaScripting, no LWCs. Uh we have flex cards, we have a lot of other things now. Uh, if you can afford an industry cloud, if you are in an industry that Salesforce supports, go for industry cloud. You will not need to build a lot of custom code, epacks or LWCs, or write a lot of JavaScript code. So if you are a company, I would say that you put out a mandate saying zero customization, unless Salesforce code config cannot handle an external legal require compliance requirement. Right? GDPR might be one example, right? You might have to write some code to do GDPR. Uh unless you can go to App Exchange, then it's still zero customization. If you can get an app exchange, or you can code and click, uh, use no code or clicks or config only. That should be a very simple mandate from leadership, and that can drive a lot of success in the programs and cost savings as well.

SPEAKER_02 48:29

Let's focus on um industry clouds, uh, Niraj, because I know this is something we spoke about in our brief. Um, you know, you you mentioned a preference for where possible opt-in for industry cloud features over custom Salesforce development, which is just a viewpoint that you've you've touched on here. Um Mercedes, you're using automotive cloud. Um, what what did it replace? I assume it's core cloud. Would you say it's been a success? What have been some of the the biggest benefits you've seen of going with an industry cloud and integrating it versus just the core cloud product?

SPEAKER_01 49:03

So so there's force.com. It comes with account and contact objects. I've seen companies not even use account and contact object. I come across an ISV who's building a package for for auto industry, but not using even an account and contact, and I had to reject them in the selection process. Saying if you're gonna create custom account and contact object, how will I drop that package into my implementation? It doesn't work, right? And I have to build integration. So then comes the service cloud sales cloud. Uh, we were using combo before we switched to auto cloud. We are needing a combination of auto cloud plus FSC because we are captive finance company uh or finance company. So the lending framework is the first thing being created by FSC team. And FSC used to be a package, we spoke about it earlier, and now it's being rewritten to the core, meaning all FSC objects soon will slowly become available to anybody using any of the industries or sales of service cloud, licensing apart. And then once you have these core objects, you you can then layer your vertical on top of it. So you might need a concept of a household in any industry. You might need a concept of a credit application in any industry, you might need a concept of a contract object in any industry. So there's those industries are contributing to the core of the model. And then what industry cloud does, which is more powerful to me currently than auto cloud itself, is there are a lot of features like Omni Studio, Service Process Studio, which is allowing me to avoid Apex and JavaScript to a large extent, almost to the 99% or 95% extent. I don't have to do any of that. So you will see with Lending Framework and AutoCloud, if you discover it a little bit more, you will hear about something called a stage manager and an integration procedure. These concepts are not available in sales cloud and service cloud. These are higher-level abstractions. You can really do integrations without even getting mule soft into the play. More and more integrations can be done in auto cloud without needing a middleware as well, especially the real-time calls. Near real-time and guaranteed delivery, order delivery, you still need something like mule soft. But if you're just making a plain, simple web service call, zero code required, uh, and you can have a workflow that makes multiple integration calls, and you can track the status of all through that through stage manager, and individual calls are made through integration procedure. If you do case management, you might end up with hundreds of types of cases, and that's not a good thing because each case type will need fields on the case object, then, and that's where the service process studio comes into play, where it allows you to create a name-value pair of custom attributes by case type without touching the case object. So it's a very powerful feature, but it requires you to understand what not to do. Then don't do the customization of the case object. Look at service process studio, build these templates, they call them. Each case type could have a business process, and you could need different information, and that is defined in set of attributes on a template. It completely avoids customization of case objects, and then you're saving so much on the limits. The global, how can the your question, right? The other question, how can you scale such a platform single instance to whole company? These are the industry cloud features that will allow you to do that because you're not hitting the limits of case types and subtypes and number of fields you can have on an object. So industry cloud is a very powerful feature. It costs extra, obviously. But I think the savings come in terms of you don't need you need app builders, you don't need appex developers then. You don't need a JavaScript lightning web component developers. You can make do with people developers who are two, three years into Salesforce have configuration skills. That's good enough. So that's the trade-off. You pay a bit more on the licensing side, but you can really enforce that zero customization kind of principle with the help of industry cloud. So we were ahead of Arto Cloud when we did the credit application. We borrowed the lending framework data model, but we had to build our own workflows and UI. We are in the process of switching it back. Um, that's other advice to companies who are new to Salesforce get your roadmap right. Don't take pride in customizing before Salesforce can deliver that functionality. So you have to have the patience. If you want to do case management, do the case management first because or lead management or opportunity management because that exists already. If you want to go deeper into your businesses, processes, then wait, collaborate with Salesforce, try to get those through the industries. Don't create a completely custom module of your own. It's gonna be expensive.

SPEAKER_03 53:59

So a lot of our listeners, and myself included, don't know much about auto cloud in terms of like the feature set. Like what do they do? Or like what are they used for specifically within the auto industry?

SPEAKER_01 54:13

So maybe I will give you an agent floors flavor of it. Let's just jump to the new concept. So there will be agents, there will be an auto speci industry-specific agents, four agents, as I understood. One would do uh, or five maybe, one would do generic customer service. Hey, I need to make a payment or I miss my payment and I need to call you or chat with you. So that will be the first agent, general customer service, but that will be auto-specific. It will know if you're need wanting a code to terminate your lease early, early termination code. So this agent would know what kind of document to generate and give it to you. The other agent is the credit agent. So the credit agent could help and credit analyst analyze all the information collected by dealer from the customer about their history and financial information from the credit bureaus and summarize it for the agents to quickly understand and help them underwrite a deal. There is the retention remarketing, so there will be another agent which will help retain the customer with the brand, right? Automate things around returning your vehicle, getting a quote on a new vehicle, things like that, right? And the last one is collection. Obviously, nobody likes the collection part of it, but the internal collection users could be benefiting from knowing what else is going on with other agents. Is this customer talking about a new lease while they are in collection? And and vice versa. So the four agents are being envisioned by AutoCloud now in this space. Another one could be which is not the domain I'm in, is road size assistance, right? So there is very specific functionality, fleet management, this B2B2C angle. There are drivers and then fleet managers, and then the company who's the might be white labeling their fleet to financing it and then offering fleet management to their B2B wholesaler and then retailers are involved. That's a complete domain of its own, fleet management. Forget about just auto financing in general. So there's a lot of deep industry-specific things that are happening, and AutoCloud is working closely with customers like ours to collect these requirements and define the data model. We're working very closely with the FSC team as well. But uh, this domain, um, you know, captive finance is very small, domain. Number of customers is small, but lending framework, everybody needs gonna need lending framework. Whether you're underwriting a credit card application or a mortgage application or even an insurance, you need to go through that same process. So um that's the that's the work that's happening right now.

SPEAKER_02 56:57

What about um so you're using Financial Service Cloud also? Um, do you have that integrated with AutoCloud? Do they do they sync together or are you keeping them as two separate products?

SPEAKER_01 57:10

So the main reason why FSC team is moving away from a package-based approach and rewriting their data model to the core is so that other verticals can use it. So you cannot you can buy auto cloud package. Auto cloud is not done as a package, by the way. It's directly done as to the core, so it's not a package. Okay, so they are the most modern vertical, newest vertical, but the older verticals are re-platforming to the core. I think Excel Force way they set up the product teams, what easier for them to package-based approach, quickly realize that it's not reusable across the verticals. But uh so AutoCloud has support for dealers, has for custom and customers, for finance company, for roadsides assistant kind of groups, for the contract management integration, servicing the contracts. So there is a lot of functionality, but the the main part that came out initially in AutoCloud was more dealer facing or customer facing. The back offices are being addressed now.

SPEAKER_02 58:10

I I did see that was one of the biggest benefits of uh the product. Um, it talked about how um a lot of these uh automotive businesses uh they are heavily reliant on other dealer management systems.

SPEAKER_01 58:25

Yeah, yes, the third parties, the dealer tracks and route ones on the world, yes.

SPEAKER_02 58:30

So um, you know, automotive auto cloud plays nicely with with those, and I think that's probably the biggest benefit. Um but but I think it's really interesting your perspective on um I think it's fair to say, if given a choice, pick an industry cloud uh would be your where you sit on the argument of industry cloud versus core cloud.

SPEAKER_01 58:49

I mean, if you have financial services, FSC is no-brainer, and that's the area I want to continue to stay engaged into, um, unless another captive finance company is looking at Salesforce. But I'd say FSC and finance is my focus. And if there is a finance client client, more than FSC, the values in the industry cloud, which you get bundled into any industry package, uh in any industry vertical you sign up for, you get the industry cloud features. That's the that's the biggest back bang for the buck.

SPEAKER_02 59:23

Got yeah. Now, um I I guess uh you know, obviously automotive clouds very new. Um, you know, Mercedes being probably at the forefront, and and I know one of the early adopters. Um how much is Salesforce kind of leaning on you and and Mercedes for feedback? Are you on like an advisory board or or anything like that? Are you getting involved in those kind of conversations?

SPEAKER_01 59:45

I mean, our leadership in Germany, HQ, is quite engaged with them. Uh good partnership. We had their product managers visit here us in Fort Worth from India and Detroit. So we know all of them, we have their emails, their phone numbers, uh, we text message some of them regularly. So very good, strong relationship. Uh it's uh Salesforce's vested interest to know the domain more and understand what they should be building. And I I like that part where Salesforce does collaborate well, including product teams. Not every project gets to be very close to product teams, but if something new and large scale, then they do get to. I've been lucky that way. Uh cannot say the delivery happens at the space that customer expects after sharing all the use cases and the knowledge, know-how. The delivery does take time, right? Every release, we get a chunk of work delivered, but the sales cycle starts much sooner, right? It doesn't wait for two years for a full product to build. And that's the roadmap discussion. If you are a customer and signing up for something with Salesforce, please, please, please do not take pride in doing things before Salesforce. Align your roadmap with Salesforce and do not commit anything other than you know, maybe case management or lead opportunity management, if maybe the first safest thing for you to try. We tried credit underwriting credit decisioning straight from day one, and we succeeded, but we had to put a lot of horsepower on it.

SPEAKER_02 1:01:18

Um I think we've lost Mass.

SPEAKER_01 1:01:21

You're muted, Ms.

SPEAKER_02 1:01:22

or not technical difficulties. Um, I know the question that Maz wanted to ask, so um I'll ask it for him once we get him back on board. Um he's dying to know how do you go about managing hundreds of resources in different countries? Because that is a maybe the million-dollar question, right? How do you successfully manage so many resources on a global scale?

SPEAKER_01 1:01:53

And the credit is where it's due. It's Accenture Internal IT. We always had development centers. So while I was at Accenture, I had a development team in Buenos Aires, I had a development team in Dalian, China, I had a development team in the Philippines, I had Pune, Bangalore, Bombay, Madras in India, and I had a data development center in Madrid. So I'd done the full gamut of locations you can find. I've not done like Poland or something. I mean, some of our Salesforce Europe folks are based in East Europe as well. Um, Salesforce, in my mind, and I spent seven, eight years there, was the first company that figured out the whole 24-7 model. And I'm not talking about production support, I'm talking about development. Um, we never had full development teams here. Only one time we hired a consulting firm to teach us agile in a very large project we did. We did people on the floor, on the ground, and we were very aggressive with Agile approach, completely agile, no hybrid. But other than that, Accenture, all Accenture projects were done offshore. Uh I funny story, I go to office. Uh, we were quite allowed a remote flexibility by Accenture for the last five years I was there. Uh, they actually paid us money to set up a home office so we can do odd hour calls with uh, you know, imagine doing an odd hour call with Philippines, which is 13 hours away from you, right? Uh, but since Accenture figured out this model and they deliver all their client projects in that model too, because of the cost concerns and all that, right? The scaling that's required. You know, they had an AT ⁇ T project, I remember Australia telecom company, thousands of people deployed. And these remote development centers do work. You know, COVID forced companies here and financial companies to here to learn that. And I'm like, guys, this this we were doing 15 years ago, this COVID thing we were doing 15 years ago. I would go to office and set up a call with my colleague and offshore team. We will be both wearing headphones during the lunch break, talking to people offshore, not talking to each other face to face. And then I'll walk to them. Can we go out and grab a lunch? He's like, No, I got another dev team call, so you guys go ahead and go get the lunch. I'm like, I'm not coming to the office. If you're not gonna spend time with me, I'm not coming to the office. But that's where I learned the offshore development model does work. Uh, State Farm had 17 sprint teams, they were on the ground, uh, they were planning 34 sprint teams. We actually stopped them from creating more sprint teams, which was a very large project and a very aggressive deadline. Um, safe does come handy for old companies who are used to waterfall. Um, but uh um what do you do is uh actually I get this task. Um every interview of mine has been involved with that. How do I go about setting such a DevOps structure, right? It's a DevOps exercise, and we create fully contained sprint teams so you can do a business analysis to production deployment and support in each sprint team, and we rotate these responsibilities, the shared responsibilities. That's what we did at JP Morgan Chase. That's what we do today. Um, and then you have architects embedded in each sprint team, you have dev leads identify the senior developers, becomes the technical lead for the sprint teams. You do this common architecture rounds, talk to each other, resolve some decisions of blockers. Uh, and then the you do have dev managers, right? Who are the dev leads are coming to a dev manager to talk to them about what blockers they are facing in each spring team. And then we have a lot of product team calls too, where we are discussing what feature is not safe to include because automation is not ready. So those are a lot of negotiations. So there's a lot of politics, a lot of negotiation at my level. But we do have a lot of structure in the teams where you know there's delegation and authority delegated where things get work done by individuals in even in a large setup like that.

SPEAKER_02 1:05:53

Um just conscious of time, uh Niraj, um very very quickly, what's next for for you and uh Uh Mercedes and Salesforce, what do you got lined up in terms of projects?

SPEAKER_01 1:06:05

So America's sort of stable and done, focus shifted to Europe. I'm a more of an initiative-based guy. I've been in you know three, four year long initiatives, uh large complex transformation. My wife is advising me to not do another transformation project, looking at uh my health or whatever, my aging.

SPEAKER_02 1:06:27

Because you never are home. You're always traveling.

SPEAKER_01 1:06:30

Yes. True. I mean European client. The advantage working with European client is early morning calls and you can get work done in the second half of your day. I really like that part. But the transformation part is the hardest part because of the cultural part. Right? That's the one you are not directly in charge of, and you do not want to create a project around that part that can delay a lot of things. I mean, I'm sticking to financial services. Uh American America-based companies is my still focus. Um, another European client, I would not mind it, right? Um, Europe project is mostly driven by Europe right now. We were driving Asia Project more heavily from here. So we'll see what happens. We are getting acquired by the parent company. So a lot of changes uh coming soon. Um, but I'm for now, um, like I mentioned to you, if somebody wants to look at a CTO with a buy-in to a lot of SaaS platforms, then I'm game. But financial services is what I'm sticking to right now. Something like a low-code platform, no-code platform. I'm also looking into new platforms that are coming up just to compare them with Salesforce.

SPEAKER_02 1:07:43

Any front runners, DR? Any any any ones that you've seen at the forefront that you think could rival Salesforce or at least a bit of room for its money?

SPEAKER_01 1:07:51

Not there yet. Um not there yet. Um and Salesforce is a good AI play right now, so kudos to them. The stock price reflected that. Uh, there is a Gartner report that I'm studying for low-code, no-code platforms for 24. The report is out 22 and 24. I was comparing. There are four or five players that are seated above Salesforce. And I'm looking at all of them and trying to compare the architecture magic is there or not on them, but not there yet. But there are a few.

SPEAKER_02 1:08:23

You know whether people play a sport for fun, but you're still working for fun as your hobby to uh to continue to learn.

SPEAKER_01 1:08:31

These large projects, uh, my learnings is more about how to navigate the landscape and politics and all that. Um my actual technical learnings will come from me looking at going back and looking at what Salesforce has done and what others are doing.

SPEAKER_02 1:08:46

Understood. Fantastic. Well, um, Niraj, thank you. Um, we really appreciate having you um, you know, as part of our podcast series. Um so thank you to you.

SPEAKER_01 1:08:57

Sorry, it took a few months. We got there. I think you were very patient with me, uh, but uh sorry, we were very busy. Very busy.

SPEAKER_02 1:09:08

You're worth the wait, Niraj.

SPEAKER_03 1:09:09

Um pleasure. Thank you.

SPEAKER_02 1:09:13

For our listeners, please do not forget to subscribe to the CRM Success Show for more fantastic insights uh and lessons learned from industry leaders like Niraj Jane that we've had joining us today for this episode. Thank you. Thank you.