SPEAKER_00 0:01

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

SPEAKER_01 0:30

Welcome to the CRM Success Show where we deep dive into CRM success and failure, delivering real stories with real impact. I'm Dave Masri. And I'm Kier Witzing. And today we're talking with today we're talking with Stefan Ludlow, the CTO of Serity Partners. So welcome, Stefan.

SPEAKER_03 0:49

Hey guys, how's it going? Doing good. Great to have you on the show. Thank you for your time. Thanks for having me. So, Stefan, um, we're gonna start off real simple. Uh, could you tell us a little bit about you, your background, and the current company that you're supporting Serity Partners?

SPEAKER_04 1:09

Yeah, Stefan Ludlow, I'm the Chief Technology Officer of Serity Partners. Um, we're a fairly large wealth management shop. Uh we provide financial planning, investment management to high net worth individuals, their families. We work with companies across the nation as well to provide 401k plan management services, workplace services, and a wide variety of other other services in the financial space. Um we're roughly a thousand people, just a bit over, um spread across the United States. So we've got offices in LA, San Francisco, Chicago, New York, Louisville, um, all over. Um, I've had the opportunity to uh grow with Sarity Partners since we were a relatively small 100-person shop. Um, and I've had the opportunity to see us grow from that 100 people to that thousand, and we're going to continue uh on that journey. From a uh what do I do on a day-to-day basis? I focus on CRM, of course, which is why we're here today, data engineering, and uh cybersecurity and infrastructure as well on the classic IT side. So kind of dual hat uh in both of those domains. I get to work on everything from the laptops that every single colleague of ours has to the CRM that all of our colleagues use, to the 10 million rows of data that we process every single day across 26 different data sources and process into data lakes and data warehouses and then pull down into those systems again. Um it's quite a diverse role. Uh, we've got about four teams supporting those different initiatives underneath technology. Uh, and it's a tremendous amount of fun. It's frankly a privilege to work across that breadth of technology. Um as far as background, um, before this, I was at a wonderful company called Dynasty Financial Partners out of New York, supporting about 45 different uh RAAs across the nation, doing CRM implementations. Um, and before that, um before I I made the journey over to New York, I was in Indiana where I started off doing bond loan and grant administration tracking, the most fascinating topic in the universe, uh, and uh working in the insurance space. So always been in technology in my career, uh, and I've had the privilege of working across systems and platforms, particularly in the CRM space. That was frankly my first love in technology. That's how I got into uh the corporate side doing salesforce implementations, and then that's always been with me through my career.

SPEAKER_03 3:47

That's fantastic. Now I noticed that earlier you mentioned most underappreciated role uh was the business analyst. I happen to see that's well, you started out your career as a business analyst. So any bias there, Stefan?

SPEAKER_04 4:01

Um definitely, definitely some bias. I never say there isn't. Um, it is where I started and where I cut my teeth. Um, I had a uh a family friend once when I was very uh just getting out of school, he came up to me and he was like, Hey, you know this tech stuff, right? You know this this program and what these APIs are. And I was like, Yeah, absolutely. But I was a history major uh originally, but uh graduated from Butley University. Um, but I love to dabble in technology, so of course I said yes. So the the kind of entry role uh was a business analyst, uh working with users, asking questions about, hey, what are your processes, what are your data flows, like who's who's clicking what button, entering what data where, and was the impact to that have on upstream systems? Um, you get exposure to so many different parts of the business as a business analyst. One day you're working on uh some AR process, another day you're working on a form on a website that's taking in data, and then another day you're working on a SQL database, uh writing bad SQL queries and locking the entire database for the entire company on multiple occasions. Um, so definitely a bias, uh, but I think it's such an essential role. And now that I I've got a team of developers, it's a role that I look at as so absolutely essential, something that we don't have enough of, I would I would say, uh, and no organization has enough of of analyzing how business actually operates and how can you use technology to get in there and update it and upgrade it and make it move more smoothly, move faster, all that good stuff.

SPEAKER_03 5:43

I would agree. I think it's often where I hear projects fail is the requirement gathering piece at the beginning of the project wasn't done effectively, right? Or it wasn't done with the right people that are gonna be the daily users of the platform. But that makes sense. A couple of questions before we dive into the nitty-gritty, just for context for our listeners, um, that we had previously spoken about. Just to give an idea, high net worth, could you define that amount for our listeners? What constitutes a high net worth?

SPEAKER_04 6:17

As we think about high net worth, that's really looking at someone um I would say with over five million in assets. Um, there's obviously ultra high net worth, there's mass affluent below that. So, I mean, if you if you ask three different people, you will get a couple different definitions. But really, when you're looking at someone with more complexity than just uh a million dollars in a 401k, but it probably shifts into that ultra high net worth category as you go 10, 15, 20, 25 million investable assets. Uh, but that 5 million to $10 million sweet spot, that really is where a lot of folks have complexity uh with their investments, where they need someone to give them a hand in understanding that complexity, understanding the different options that they have, um, and where they can get a hand in that. And that's where Sarity Partners comes in.

SPEAKER_03 7:09

Perfect. Now I know one of the areas we'll focus on today as the conversation continues is around merger environments. So before I hand over to Matt, do you want to tell our listeners just how many mergers you've done in your near six years as CTO of the business?

SPEAKER_04 7:27

Absolutely. So over the over the last six years, we've done over 35 mergers. Um, so we've grown largely through what is what is called mergers and acquisitions, really, really that focus on merging uh two companies together that are doing something relatively similar. Um and that's that's really when I came into Serity Partners, my first meeting was an introduction to one of those teams that were coming on board and doing discovery. Kind of what I started my career doing was the first entry point into this company of looking at what are the tools, technology processes that uh a team up in Chicago as it happened was was leveraging and what was the the migration path, what was the integration path, how would we work together effectively on a unified client base? That was where I first started cutting my teeth, and it really hasn't stopped. Um, as we look at SARI partners, that's really become a core competency from a technology perspective, where we've actually built some dedicated teams uh within our technology practice to align in and be able to execute that while frankly not uh not kind of breaking the way that the business runs. Um for every merger that we do. If I did a merger six years ago or five years ago, four years ago, those colleagues on board and then expect and want a growing and changing platform that's adjusting their particular business needs, and we need to keep delivering on that while also uh making sure that new colleagues who are joining um have a smooth and effective onboarding and don't go through too much uh disruption as they go through that. That's always the goal, uh not to disrupt the business as it goes through that process while also aligning into a common way of doing things.

SPEAKER_01 9:16

Awesome. So so to be clear, when you say there were 35 mergers, you're not just talking about organization mergers, you're also talking about system mergers.

SPEAKER_04 9:25

Every single, every single one. Um, as we as we look at a typical merger, uh it goes through a couple different phases, and my team deals with two major ones. One is obviously the IT infrastructure onboarding. That's just how are you sending an email to your clients? Um, what email domain are you using for that? How can we as quickly as reasonably possible, again without disrupting the business, um, have someone operating as SARD partners quickly, effectively with a minimal amount of disruption. That's everything from here's your new laptop to here's how email works to bridging uh data from one system into another. So a typical IT conversion can alone have um a dozen tools that a team is using, everything from Outlook to scheduling software to chat and what have you. And then, of course, there's the CRM conversion, which is often one of the most difficult and challenging. And there's others that come down the line depending on kind of what tools the team is presently using, from how do we report on assets, how do we uh do presentations, all that good stuff. But uh my focus is really on that CRM and the IT side. Um, so it uh it's a process, and it's one that we've built a core expertise in. Um, it's something that we do over and over and over again and have developed a playbook. Uh, of course, the best laid plans uh when they go into practice, they go into the wind, but we do a fairly good job of doing that process in a repeatable fashion while understanding that every team that's coming in to SARIT partners, while what we do is very, very similar oftentimes, particularly in the wealth management side. We're all managing clients' assets, we're all doing financial planning, we're all working with one of our custodial partners in executing paperwork, we're all doing money movement. The client needs to move money from location A to location B. And it's understanding, okay, teams, how are you doing that? You how are you using your CRM to do that? Um, that's been one of the interesting things really since the start of my career in wealth management, specifically. What is a CRM to a uh wealth management firm? It's very rarely a sales tool that has that role. It's very often an operational hub that's being used to manage the life cycle of a particular client. Um, and that becomes an incredibly delicate part of doing a transition, doing a merger. How do you make sure that a team that's on a day-to-day basis using a CRM to schedule every one of their client meetings? That's kind of one of the core heartbeats of wealth management. Um, how do you make sure that when they go from system A to system B, that they're still able to do that, even though how they're going to do that, like what button are they going to click, that's probably going to change. But that they're going to do that activity, that's essential that we carry that that business process forward.

SPEAKER_01 12:27

Okay, awesome. So um I want to take a step back and you touched on this a bit. So can you just give us a bit of background? Because a lot of people, a lot of our listeners probably aren't that familiar with financial services and wealth management. Um, so a little bit of what that means and how your users use Salesforce, what they use it for. Um, I think you're on FSC. I don't remember.

SPEAKER_04 12:49

Standard, standard Salesforce service cost. Uh that's the technical technical version that we were on. We were on FSC um way back in the day. Um, that that first meeting that I actually had, and this kind of represents, I think, a little bit of the Sarity Partners' philosophy, whereas we're doing mergers. Um, if someone is doing something better than us, we'll look at that technology and we'll be like, how can we use this for the entire firm? Uh this specifically happened in one of my very, very first mergers. We had an FSC instance. Um, it was, I'm I'm sure the person who implemented it will watch this and so uh love them dearly. Uh it was perhaps unoptimized. Uh we'll we'll be charitable on that. Um so we did this, uh we we met with this team up in Chicago, and they created a a really quite excellent um CRM focused in uh what we call 401k plan management, but was where they had that team's uh primary primary driver, meaning they work with companies who have a 401k plan, um, and they they provide uh services to that company to make sure that plan is well architected, well constructed, that the participants, the employees of that firm are able to leverage it. Um they also provided services to the employees of those companies from a planning perspective. Um, how should they structure their 401k investments individually? Um, they also had a wealth management division within that company. Uh, and as we started to do due diligence as we got into their CRM, um as we dived in, I was like, this is actually pretty good uh from an architecture perspective. Um at Dynasty Financial Partners, we had used a variety of different implementations of Salesforce from SkyEns to uh Practify to the early, early versions of FSC. Um, we'd done those implementations. Uh, so we got a broad ranging view. And I always ask myself, what if we just use vanilla Salesforce? Like, is our data model really so different from what Core Salesforce does that that it's unusable? So we happened to this instance happened across our our lap and we looked at it and we were just like, no, no, this is actually really good, particularly when you compare it to the data architecture of person accounts that that we were presently kind of fighting with. Um not to say it's not come a long way, but we took the opportunity to simplify our architecture with that decision and just use Salesforce out of the box. Um that's what we did there.

SPEAKER_01 15:26

So I'm sure I'm sure a lot of people are asking like can you give us specifics? Like like what what was better?

SPEAKER_04 15:39

If you look at when you're building data integrations between two systems, uh whether you've got a hub in the background, like a MuleSoft that's pushing data back and forth, or you're building kind of homegrown APIs that you're running up in a cloud environment like Azure or AWS with a job scheduler, um, being able to cleanly and quickly identify what data from what source system you're pulling to where in a very simple way is really, really important from a time-to-market perspective. So what we found with person accounts is that there was two two main things that that we struggled with. Number one was hey, always know what you're what you're getting from an API call perspective. Uh, where is this data in the particular object? Is it on the account side? Is it on the contact side? Do you have to do kind of some some way to get get both together? Now it's largely been resolved in the years since on the Salesforce side. It's much easier now than it used to be. Um, the other bit was the lack of kind of enforced data integrity between the concept of an account and a contact. For us, that became that that was really, really, really, really, really, really, really, I can't say it enough, important. That we could generate an accurate count of our clients, that we could generate an accurate picture of what is a client from a data structure perspective. And historically, and this goes back to my my my time at Dynasty from an architecture perspective, it was always a household. So when we're dealing with, and you kind of asked uh asked this earlier, like how does wealth management work? Well, well, our clients are oftentimes families. Um, it's John and Mary Smith plus their LLC, plus maybe the foundation, plus a um business that they have, plus a trust. Um, it's really a collection of different entities uh that we're we're working with that you needed to create a hierarchy across. And John and Mary Smith are associated to the account, the household, so to speak. Um, we found that data structure to be really, really important from a how are we building automations, how are we building data integrations, how are we building reporting? And out of the box, the Salesforce account and context structure, uh, where I have essentially a company plus employees, in this case a household plus family members, uh, that data model was able to be really, really consistent and out of the box Salesforce. With FSC, it really felt like it was designed more towards the banking or insurance sector, where an individual, John Smith, is your client, whereas in our universe, it's the family. Um, so that kind of core difference where FSC almost uh, I don't want to say it encourages, and you can build this referential integrity. And we have on my side historically uh done that within an FSC environment where you create the lookup field on the person account to an account that's the household, and you can kind of get there and you can build some automations in the back end to enforce it, but it wasn't out of the box and we felt like we were always fighting it. Does that make sense?

SPEAKER_01 18:50

Yeah, I I think I get it because I'm very familiar with the FSC model. Um, there's definitely complexity there, but I I think a lot of it's done more so because they want to capture a very wide range of relationships, right? So they they don't want you to roll up only to one group because the trust could have employees, let's say, or the business can have employees, and maybe they're also potential customers. I don't know if that wants to roll up to the household, maybe it rolls up to two different places. Um, it also does lots of things like I want to know who your accountant is, and that accountant rolls up to an accounting firm, and that firm works with 12 other households, and they have six accountants to them, and they're related to different people, and you know, I gave or Maz uses accountant A as part of you know, accounting firm B, and my son just can't stand that same person, so they use a different person in the same firm. It's it's really, really complex when you get into uh you know those kind of personal relationships. And I think they really try to build out to allow all of that complexity. Um and the power you lose the simplicity is just kind of the nature of the technology, and I think that might be uh what you kind of ran into.

SPEAKER_04 20:01

Exactly. We've we found uh a lot of value in creating a an easily understandable and consistent data model, um, and it it took a tremendous amount of time. Um, one of the core things that we did very, very early on uh that helped us in that journey was we realized there wasn't an identifier that was friendly for the business to use, what we call SARITY Partners. So we were very creative. Let's create a SERDI partners ID. Um, and that lived at the household. And it allowed the business to have a vocabulary that was aligned with the data model that everyone, when we're talking about a particular relationship, we very instantly, very easily is when we talked accounts in financial services, people are very confused. They're like, What do you mean? A financial account? Financial account's not a household. What are you talking about? Well, it's a Salesforce account. A lot of confusion there. So we ended up, uh, we frankly end up using more often the short name for that identifier as shorthand for the relationship. And because they're one-to-one, we can then, as we're doing other systems that are adjacent to the CRM, such as a general ledger, such as a portfolio reporting system, which is a source of truth and financial account data for a relationship, as we're doing financial planning associated with that relationship. By having that ID, I mean, it seems so simple, right? A simple concept, but by having that vocabulary that the business has aligned on, on this relationship's ID is one, two, three, four. Okay, how do I link two systems together? Well, you put that ID on a financial account, you put that ID on a financial planning client, and we will pull that data together. And you're talking about the same thing in two different systems, which in financial services seems to be one of the deepest challenges because the breadth of different types of data. That we work with for a particular client. Everything from tax returns to financial accounts to financial plans and what have you. So having that, having that vocabulary and a simple data model allowed us to accelerate the adoption of the platform as kind of a source of truth of client data, as opposed to, oh yeah, there's just a CRM in the left-hand corner, click the button to onboard a client, but you don't really need to use it. Really became more entrenched in the business.

SPEAKER_01 22:29

Awesome. So going back to something you said previously, that you really systematized all of these mergers. Now clearly you have a very customized, because it's not even a SC, uh, Salesforce. Um a very, I guess, thought well thought out plan data model, right? So now and and at the same time, you you're saying that you were able to systemize moving all of this data from all of these other uh firms that you're merging with where their models might not have been as well thought out, let's say, um, or their data was messy or unclean or no households or that never happens, right?

SPEAKER_04 23:12

Everyone's data is super clean.

SPEAKER_01 23:14

Yeah, yeah. So, but anyway, tell us how you did that, right?

SPEAKER_04 23:17

Well, uh it it differs between platforms. So as we looked at dynamics conversions, Salesforce to Salesforce conversions, where you really have uh systems that are as complex as ours, um, those become much, much more bespoke, much more challenging because someone could have a foundationally different data model for you. Uh, we found this once. We we worked with a team uh as we started having conversations, it came out really quickly that they viewed client relationships really at that financial account level, like on a day-to-day basis. That's what they were talking about, and that's how they did their their agreements, that's how they did their uh data relationships, and that was different than us. And uh, if I said there was an easy translation layer on that, I would I would not be being truthful. Uh, it was difficult and it was change management on both sides, and that's where uh we put our business analyst hat on in a very big way uh and had to get in and understand how does that that team work? Um, how does that team structure the data? Contrast that to when we encounter a red tail instance, though, we're fairly frequent uh out in the in the wealth management space. You'll find a red tail CRM. Um you there's not a lot of flexibility in the data model for Red Tail. You've got a household and contacts and financial accounts, and then it's all out of the box and it's the same from every single instance of Red Tail, one to one to one to one to one. Um, there's a custom field area, so app ended to the back end of uh the household data, you'll be like, okay, here's custom field one, two, three, four. A team could do all sorts of stuff with that. Um, but it's fairly straightforward. You can write a script for the vast majority of a red tail CRM's conversion, and then use that script over and over and over and over again, as long as the team is generally using that system in the same way that we would expect, which we found with Red Tail, it's actually fairly consistent. So we can do a red tail conversion very, very quickly. Dynamics conversion, team of people get assigned, do a deep dive analysis of how that system is configured, how it works, um, and execute that conversion very, very carefully in collaboration with the business. So being able to flex into those two models from a data integration, data migration perspective has really been key. And as you look at our um, if you looked at our project planning tool uh and you look at any particular one instance, we very quickly define is this a team that maybe hasn't adopted CRM in a in a deep way where we need to, hey, it's just an onboarding. Here's our CRM, use it, it's great. Water's warm, fantastic. Are they on something like Red Tail where it's a simple integration where you run a script and we've seen that platform before? And there's six or seven of those in the wealth management space that are fairly here's a box, that system is shaped like that box, and you can rinse and repeat with variation. Or is it uh a highly complex system like another Salesforce, like another dynamics? So being able to not paint by numbers on every single one, but to have a plan that three plans essentially that we can leverage depending on the situation, that's really been important for our success. Um, the change management component on the user side, though, on the colleague side, being the most important part of any of those migrations, even if a data migration is simple, working with the colleagues and onboarding them into your platform, that's always hard. It's change. And it's you need to give a warm bear hug to someone and be like, hey, it's okay, we're going to be with you every step of the way. Here's how you do that thing you did a month ago.

SPEAKER_01 27:06

So it sounds like it was more standardizing the process than the code base.

SPEAKER_04 27:11

Absolutely. Absolutely standardizing the process and building that competency within the team who's done this over and over and over again. When a team first meets us and asks, are you going to take care of me and my data? The most sensitive data for that that we work with, these are our client relationships. This is so important. You can't break this. If you break this, you break how we service our clients. Um, it has to be a deeply empathetic conversation from the moment you meet them. It can never be uh we're going to run roughshod over you, and this is just what you do. Um, that's a way to destroy trust and make the whole process much more difficult. Whereas if you go in very empathetically and you've done the system that that team is on a couple of times, and you clearly know what you're talking about when you're talking to the team and be like, hey, uh, we know with Juncture, one of the with the older platforms that we sometimes encounter, it's going away now from just being offered in the marketplace. But hey, we know that when we look at an activity record in juncture, it's actually three records that have been smashed together, and you've got your pre-meeting, your post-meeting, your unstructured notes. And uh you need to go into that and kind of figure that out. That that we can go in and be like, we're not going to be surprised by that. That's important.

SPEAKER_03 28:37

Perfect. So, Stefan, just again for context, I'll be honest, I've never heard of Red Cell before, but whilst you were uh in your you know, doing your thing and in the zone, I had a quick look and just for again for context for listeners, are we right in saying it was it's a cloud-based CRM for financial advisors? That that's essentially what it is.

SPEAKER_04 28:59

Absolutely. So as we look at um if we look in the broader marketplace on like the either sales tech, consumer tech, other other uh non-financial services, um, someone will buy HubSpot CRM, they'll buy Salesforce. There's all sorts of different CRMs that you can buy pipe drive. Um, same thing's true in financial services. Salesforce FSC has a tremendous market dominance in that space, and that's kind of the standard tool that someone in wealth management, if you call it Salesforce, they're gonna sell you FSC. It's not a bad product. It's and particularly if you don't have a team of developers, you just need uh a CRM with out-of-the-box integrations, it's not bad by any stretch of the imagination. And Salesforce, so you can continue to customize it and build APIs. But on that same note, beyond that, there's of course standard Salesforce, and then there's a bunch of different resellers of Salesforce who build platforms on top of it. So you've got Practified, you've got Skyence, you've got um half dozen others, XLR8 uh is one of them that have taken either platform licenses or Salesforce in full and have a managed package that lives on top of that. So there's there's quite a bit of diversity. There's also SaaS products that are completely unaffiliated with Salesforce. Um there's Celintica, which is on Microsoft Dynamics. Um, they also have a version uh on top of Salesforce. Um, you've got Wealth Box, a really, really, really super cool uh CRM, cloud native SaaS, API driven with a bunch of connectivity. They almost came in as into the space uh several more than six years ago. They've been for a long time, to build as, hey, we're their alternative to the stodgy old uh systems that you guys have been used to. And we've got the first zap year connection, and you can just plug us into anything you want. Very cool guys over there uh building cool tools. But so in the MA space in wealth management, we encounter quite a few different tools that are being used as CRMs. There's almost always a tool, uh, but there is diversity in the in the space.

SPEAKER_03 31:10

Why why did you choose one of the things we like to cover on the show is around selection and why you choose a solid system. So very briefly, could you tell us um why you chose Red Tail? Did you choose it or it was pre pre-ored?

SPEAKER_04 31:25

We chose Salesforce, just to be clear. We chose Salesforce. We find that a lot of people choose Red Tail as their platform. Gotcha. Often they choose it from a cost perspective. Uh, it's if I'm a business looking for a CRM and I ask the question, hey, I need something that I know is going to work, that's not going to break the bank, and that has good data integrations with other common platforms. Uh, your wealth boxes, your red tails, your celenticas, your FSC, all fit the bill. Um, and you can you can make those selections. But the question really a team needs to ask if you just want to check the box CRM and get it onboarded, um, that's not a bad way to do it. But oftentimes people want to extend their CRS to continue um that journey of how can I make this a core part of my business and start to customize it, particularly when we talk about the average size of wealth management team. Generally, uh what we find is five to 15 people is a very typical size of company in wealth management. Okay. Um John Smith Financial Advisors, Smith Financial, those sorts of companies, they're all over the place. And they're wonderful, wonderful small companies that are um doing tremendous service for their clients, working with third-party providers to build a platform, and they often need to slot in a CRM. So they'll pick Solentica or they'll pick or they'll pick FSC. Um, but they won't generally customize them. What we found changing in the industry though quite a bit is as teams get bigger, like Sarity Partners, we went from 100 people to a thousand over the course of six years. Um, we needed to customize our technology very much to our own individual business processes, and that's where Salesforce really became one of our key tools, and that we had that ability to customize. And that's why people pick Salesforce, at least in my opinion. They want a platform that will work, number one, from fairly early in the implementation, um, but that can be extended almost as as far as you can take it. Uh, they don't want to be limited by their platform, and Salesforce is that platform. I think they have a price to justify that, but no.

SPEAKER_03 33:48

Perfect. Uh appreciate the clarity there. So a lot of businesses we see in 2024 uh and the last couple of years as well, in order to grow, scale, survive, they're merging, right? And doubling down, joining forces, uh, becoming bigger and better. That's a big part of your business model, uh, as we discussed earlier, 35 uh migrations, uh mergers in in five, six years. How do you I guess as I say from a technology standpoint, the tech that you're merging together? Surely there's going to be cases where there's duplicate data, there's crossover between companies you you merge with. Each business has different adoption levels than the other. So do you do like an audit, an analysis, a spot check, like we call it like an MOT in the UK, like a vehicle inspection type process when you merge with a new company?

SPEAKER_04 34:53

Absolutely. One of the one of the critical processes, and it's important for both sides as a team is going through a merger, is they need to understand what our technology is and what our stack is, and we need to understand theirs. What have they built? What are the APIs moving data between platforms? Is again what is the overarching goal when you're doing a merger? I mean, our goal of SERITY Partners is to provide uh the absolute best quality investment advice and financial planning for our clients and their families. We all want to be able to do that. So to ensure that there's no disruption in that during the merger process, we absolutely have to dive in and understand how, from a technology perspective, they're actually providing that service so that we can map out when they're going through that migration, what's changing and how are we kind of catching that business process on the other side? Every single tool gets a migration plan. Literally, every single tool uh as we go through a merger diligence process, uh, we get to it's not just making sure that everything's running well, it's also looking ahead into the future. It's like, what is the path that this particular tool is going to take? So if someone's coming in with a countly instance for instance, that's fairly common that someone will come in with that, a DocuSign instance, an Adobe instance. Really, what we'll do is we'll map a migration path. Oftentimes at this point, SARIT partners will have that tool within its stack. So it's a question of can we just join the two together, merge the contracts in a fairly straightforward way, or just add them? Uh, can you do that? Or is it do you shut down that tool, add them to ours, move a little data over, and just you're off to the races? Oftentimes it's it's somewhere in between. Uh, every vendor has a little bit of a nuance, and that's one of the things that we found doing um doing as many mergers historically as we have, it allows us to avoid disruption because we know the migration path of every single tool. So when we're talking about a financial planning tool, for example, uh, we know how data can, if it can, move between the platform our current team is using and their future platform. And we know the nuances. It's like, hey, FYI, we'll be able to recreate all the all the data uh in our system, but this one piece will have to be manually done. It's all about expectation setting, right? If you can do that diligence process, provide a team deep clarity in what the migration path is, V Serdi Partners very much wants to be one firm. What we aren't doing is just bolting teams on to the side continuously. That doesn't make a whole lot of sense. What we're doing is really becoming one company. It goes back to that when we met with that team up in Chicago, that awesome CRM instance, that awesome Salesforce instance, and we wanted to bring the best of both into the firm on a go forward basis. Like that's our philosophy. Um, so empathetic, collaborative, but you have to know. So, yes, we do that deep diligence process on every single tool. Down to if someone spent a credit card on something that costs $15 a month, we're going to ask, find it, ask the question, what is it used for? How is it used for? We often find that that's honestly where a lot of unexpected complexity can live, where someone's used a credit card to build an integration that they didn't have a big tech team behind them. They just need to figure it out to service their clients. We find that pretty frequently. And we have to understand, okay, what have you done there and how it's okay, we'll we'll keep that running or we'll keep a version of that business process running. But how do we bring that over? We have to figure that out each time.

SPEAKER_03 38:33

What surprises you the most when you do these initial audit discoveries, health checks with new businesses that have merged into the brand, uh into Sorority Partners? What's what what is the ah or the eyebrow? Like, okay, I wasn't expecting that. And it might not be on every every occasion, but just that a trend that you've seen.

SPEAKER_04 38:58

Yeah, what I found, and Maz, I don't I don't know if you've seen the same thing here, is the level of sophistication of just companies today, even in a small size from a technology perspective, is materially different than it was six plus years ago. We've had a number of instances where we'll uh meet with a team of colleagues and we'll have uh a data flow architecture diagram that's just like someone will just go over in the corner, pull one out at the ready that's got great data flows between systems and an architecture diagram, and what's the frequency? And I love that. That that's so absolutely fantastic. Six years ago I didn't see that a whole lot, but now I think there's been a bit of a democratization of tools and tooling from a tech perspective that's allowed people to build more sophisticated data integrations between platforms. They're not always the most scalable, they're not always the most robust, but they get the job done, which is people's jobs at the end of the day. They just businesses don't always, particularly when you just don't have a big depth of team, the focus is not always on how do I build the most scalable, robust infrastructure. If someone needs to kick it in the corner to make it run in the morning, that's okay. Uh, but they will build data integration. So that's what's some somewhat surprised me is the level of sophistication, even in small teams that don't have dedicated tech resources. If a team wants to build something interesting, they there are tools and technology out there that they're going to be able to make some headway in.

SPEAKER_01 40:42

Um, to answer your question, it's not something I've thought about, but I I think there's almost no correlation between team size and the sophistication of their tech stack. It's bizarre. Like you you you'd work with a Fortune 500 company and you would like, how are they operating like this? It it's it it's it can be yeah, it can be some like really, really crazy sometimes. Um I don't know if it's just a ton of historical debt to tech debt or historical processes and ways of doing things or bureaucracy. Um but there's there's I find very little very little correlation. Um one of the things I wanted to ask is about quality control, because it's something I face a lot. You'll have one team that's exactly like you said, this data is so important, it's gotta be right, and they're gonna test it and test it and test it. And then you'll have another team that won't even look at it until it's live and almost will refuse to look at it until it's in the production environment. Um and again, I I don't fully understand that attitude, but it's definitely there and it it comes up a lot. Um, is that something that that you faced where getting the user base to stop focusing on their job and focusing on making sure the transition is smooth?

SPEAKER_04 41:58

I've honestly had to have our team take a moderate role in that. Now we can never be a substitute for a team that knows there's their clients, that knows their data. Like that's the golden source of quality control and a data migration. You have to have that. You have to have hands-on keyboard looking at data and signing off on it. But yeah, as you say, there's a diversity of do I have the time to do that? Do I have the root, am I the right person? Do I have an understanding of the full client base? Maybe I understand a part of it and I've been assigned to the project. We've really had to take an activist role. If we just migrate from scratch using the scripts and don't ourselves using what we know of the industry, what we've done from a diligence perspective of the clients, if we can't ourselves go in and do our own checks in a very robust fashion at scale, we've got the tools and technology and expertise to really do it, frankly, more quickly than someone who just gets a screen in a sandbox environment and is clicking a selection, like 5% selection of records and confirming. We can do some bigger level, okay. I expected 10,000 rows of data from this table. I see 10,000 rows, or I see 999. Why? Um, we've got that ability. I we've taken a much more activist role in data quality ourselves on behalf of the teams who we're doing data migrations for in CRM specifically, um, than I would have expected, but I'm glad that we did. It's it's it has streamlined the process incredibly when a team doesn't see faults themselves, but we catch them before they've even happened or before they become visible to the team, uh, and we're able to fix those. I think that builds trust.

SPEAKER_01 43:51

Yeah, for for sure it does. Um to get to the core of my question, because again, I struggle with this with this a lot. Is my is my audio breaking? Okay. So there's testing to spec. So I put together a spec, a mapping doc, whatever. Wonderful. I run my code data to the spec. I can now test the spec. Um and I can put a business analyst on it, I can put a data analyst on it, they can work together and check that everything came over and was transformed right. Perfect. What they can't test for, what I need the end user, the data owner, to test for is the intent of their data. I have no way of knowing their intent from their data. When they classify a code or a product or a strategy in your case, let's say, um, you know, what does that actually mean? Um I'll give you this really stupid example, bi-weekly. Is that twice a week or once every other week? I don't know. Um, so it's that kind of stuff that it really need the user to do. And again, sometimes you just don't have an active participant. Um, and then sometimes like, okay, we'll just fix it post-prod. Um, but yeah, so any of that, any of that kind of stuff or any proactive measures you take to deal with it.

SPEAKER_04 45:06

Well, I think it speaks to like why does Sarity partners have folks in-house who run and manage these these conversions, these these CRM conversions? Like, why? Is because while a team may not be able to articulate individually or have the time to articulate uh the intent of a piece of data, we've seen enough systems, enough sets of CRM data over time and worked with enough teams and done diligence with this team. Again, comment I have to put on that business analyst had a very early part of the process, is we can generally look at a CRM in wealth management and understand what a team was trying to do. Not always, sometimes there's something something crazy. But I view our role as not just a sh uh mover of data between system A and system B, but it's understanding the business that's joining SARIT partners so that as we're a we're a custodian with that team of that data coming over, that we do a good job and that team doesn't have a negative experience. So if we see a piece of data that's nonsensical, we'll ask the question. Oftentimes we will have done that upstream from the data conversion to get an understanding of exactly what I see this multi-select pick list that seems to have segments of your business in it. Um, is that what you're using that for? Okay, fantastic. I'm not actually going to migrate that from that field to like the identical field, we're not gonna recreate that. We use a different methodology to do that. Have the conversation, empathetic, they understand what the future state and a robust amount of training. Um, I find, to your point, if we don't do that and we just do non-intent based data migration, so just doing it from spec, that they're often wrong. Not wrong technically, but the business breaks.

SPEAKER_01 47:08

Right. So, like another great example that I've seen a lot, I think, with Red Tail, specifically Red Tail um is the householding model, right? It's horrible in Red Tail and it's critical to your business. Um, so how do you build a household out of contact records, right? Last name, address, I can do my best, but I still need the business, right?

SPEAKER_04 47:34

We're actually to the point where we'll we'll we'll not take the CRM as a source of truth because for SARIT partners, uh-huh, our CRM is the source of truth for our client, client list, right? And that's that's really, really, really important. But not everyone's been such a steward of their data um over time, or maybe they're using something like Red Tail where it's a little cockammy sometimes. Um we'll correlate the data that we pull out of CRM with other sources, um, either custodial systems or fully reporting, so financial account systems, we'll correlate those together uh to get a picture of the client base that will compare with what we see in the CRM. And if it doesn't compare, we'll actually synthetically create data during the CRM conversion to represent what is the definition of a client on the SARIT partner side, as opposed to doing a one-to-one conversion. So absolutely, when we encounter that situation, as we don't uh we don't always trust the originating system, which creates its own validation issues because how can someone test a spec, a migration where we've actually changed data to map to a different model of what a client is. Because even your accounts don't match anymore, don't even accounts don't match. So we have to be focused on the data lineage when we do something like that and understand okay, what is every step that we've done and trace it back? But it's challenging.

SPEAKER_01 49:03

Okay. Um, all right, so this is a little more fun question. Give us a horror story. 35 migrations must have had one or two horror stories, or call them war stories if you prefer.

SPEAKER_04 49:15

The war stories, opportunities for improvement. Every question that we ask during the diligence process is there for a reason, and it's not because we found that anyone's doing anything wrong. But what I found is that when expectations, a team expects A to happen and B happens, that's when emotions get frayed, people get frustrated, and someone like me needs to hop into a room with someone and be like, okay, what's what's going on? Let's talk about it, let's take that step back. I like to avoid those at all costs. That because of the nature of every one of those questions on that due diligence, every single time we've done a merger, there's always some opportunity for learning. There's always some opportunity where where we go in and we find, hey, we could have done this a little better. Where specifically have we seen that horror story? Or that uh I wouldn't call it a horror story. I'd say the biggest time when expectations between A and B, let me give give a good example. I touched on it earlier. Walked into an office, and as I'm as I'm walking down, I I see a couple typewriters in the corner. I'm like, oh man, I love typewriters. I like woodwork, I like old stuff. That's fantastic. And there's no dust in those typewriters. That's interesting. Um, okay, keep walking down the hall. Okay, we're we're doing training. We're training people on how do we do agreements? How do how do we think about clients? Uh, and this was fairly early in our process, so there was a little immaturity at the time. And we're launching into this training, and we get asked the question well, how do you send a client 16 agreements? Like, I'm like, Well, there must be a lot of different entities involved because we do different different numbers of agreements, four different types of entities, like what's what's able to contract, all that good stuff. They were like, No, no, no, no, no. So John Smith has 16 financial accounts, you need to send them 16 agreements. I'm like, account opening paperwork, like at the custodian, that that's how accounts are open. There's one piece of paperwork for every financial account. Like, no, no, no, no, just the wealth management agreement. I'm like, why would you send them 16 wealth management agreements? Well, one for every financial account. I'm like, why would you do that? I realized at that specific moment we had screwed up. What we had screwed up is we did not know before we were walking into someone's office, getting ready to go fairly close to live with the CRM conversion, that they had a foundationally different understanding of what a client was than we did. And that no one had realized before that moment that everyone was saying the same words and meaning different things, very different things. And it wasn't a terrible scenario. We had to stop a training session, reorient it, like literally huddle in a back room, be like, okay, we now realize that they are this is the language that they're using, and now everything makes sense. Like you could literally see the locks clicking uh in people's heads. Uh, and then we came out, we recalibrated. It did require like three more training sessions, and then down the road, the way that they were doing that actually permeated into file management systems, into automations that they had rolling between systems, not knowing that critical piece of data, that that language that was different between us, that was deeply impactful. So, what do we do after that? Um, we put our business analyst heads back on, and for new mergers, we knew, hey, that's a possibility. Really dig into how do you define a client and use that on a go for it. That's actually when we started synthetically creating um parts of the relationship that maybe a team wasn't representing in their CRM, but that is CR SARDI partners uh was very important for us. That's cool. There's other other opportunities for improvement. Maybe I I don't want to flag on a podcast. There's uh it makes us sound really sophisticated and and uh and smart, but we we've made mistakes. Things things happen, we've had to recalibrate, uh particularly at a tactical level with data conversions. Um, there's been times when teams making changes for an upcoming conversion in a sandbox environment. We have nice color coding, and hey, someone changed the tab that they're on, and all of a sudden they're not in the sandbox environment, and we start seeing alerts going in our little track. We're like, oh, why is there an API failure on that field? And that nothing's pull up the olig.

SPEAKER_03 54:20

Oh god. It's it's timely, Stephen. We're gonna move on to the reflection period of of the show. So uh I'm curious, had you done mergers before taking this role in your career?

SPEAKER_04 54:37

I worked at a wonderful company, um Dynasty Financial Partners before. Um, what they what their business was, they did breaks. Um, what a break is used to be all the financial advisors, lots of them were at Morgan Stanley, Merrill Lynch, like these big, big banks, right? These big companies. Um, and Dynasty's model at the time, and it the industry has since changed, was the there were individuals who were working at those companies who wanted to kind of start their own company, to get out of the big banks and really start their own thing. Uh, so when I started working for Dynasty, that was my first introduction to that particular business model, which is what they call breaks, breakaway advisors, breaking away from a large company and starting their own uh independent advisory firm. Um, so that's really where I cut my teeth. Uh, we did dozens and dozens of those. Um, I was thrown to the wolves. Uh my first project was doing a uh link point deployment for 45 different firms. My project after that was you do a box.com implementation for 45 different firms. Uh, do a quick integration, uh form-filling uh technology that's used in wealth management, do that implementation across 45 different firms. So, yeah, uh I got I cut my teeth there. Um what does it look like to do a change at an organizational level over and over at scale?

SPEAKER_03 56:11

Perfect. So we've got about five, ten minutes left. So just want to cover a little bit of the ground on tips. Um, so I want to ask this question on two fronts. What tips would you give other T suite executives in your shoes to master merger environments? And the second part of that question is what tips would you give to like admins, developers that maybe are going through a merger project for the first time?

SPEAKER_04 56:41

From an executive level, understanding what is flexible and what's not is is deeply important when you're walking into a room with someone who's going through a migration. For us, Salesforce is the ultimate destination. So it's never on the table as an option of I I appreciate you really love your wonderful uh juncture environment, for example, but the the path for us to to collaborate and move forward and the expectations that we've set is Salesforce. But understanding what that where the flexibility in that is, does a team use something that's foundationally different than um than your team, being empathetic and open to those, understanding that it's impossible to do everything at once. If a team is like, yes, we use Salesforce and then built a React app on top of it with a bunch of different uh gizmos and doodads and what's what's it's you're not probably going to be able to promise the to bring all those over, but figuring out what are the most important and being empathetic on that. But providing that clarity not only as an executive in that room to whoever's on the counterpoint, but to that admin who is then assigned to the project. Like that's often a layer where I find um there can be misses. The execs are all talking in a room, there's deep agreement on X, Y, and Z, and then it's the the admin and one of the client service associates who are actually doing the execution work, and there wasn't that that layer of glue between them. Um building that during that conversation, making sure that they're in the room both at that executive level conversation, but also then there's that regular touch point from the admin perspective. Get the exec down in the weeds just for a moment, and a line of, hey, just confirming this is what we're doing, this is what we're aligned on. I found a lot of additional extra work that's cropped into projects unexpectedly happens from those gaps in communication where the client service associate or the team on the other side will say, Well, we desperately need this, but there may have been kind of a discussion or agreement upstream that yeah, that wasn't needed. So you didn't need to do this kind of leap over the fence, so to speak, to make it land it.

SPEAKER_03 59:14

What about for more admins and and developers? Um, any tips or advice? Obviously, you've hired a lot of people over the years, you've maybe inherited staff that are in a new environment. What would the tip there be? How can they how can they hit the ground running or get comfortable with the uncomfortable?

SPEAKER_04 59:35

For Salesforce admins specifically, understanding that the CRM is one part of the platform of any company, and it's not the platform. It is it is part of an orchestrated set of systems that manage the client lifecycle. If an admin is just looking, this is Salesforce, this is my world, these are the borders, and I don't go beyond them from an understanding perspective, they're doing themselves a deep disservice. Understanding where this platform extends, where where's the revenue coming in? Where how does that data feed work? What are the rules? Um, how does DocuSign, for example, where where are the borders of agreements and where are the integrations both in the periphery of the system? And then how does that system then interact with others beyond that border? Um, is an area where I think people can get just a touch myopic, just a touch overly focused. And having that willingness, that interest, that drive to go beyond the borders of Salesforce, I think that's that's one of the biggest differentiators between admins who are admins today, but some leadership role in the future, versus folks who you're a 50x certified person who really knows this part of the platform.

SPEAKER_03 1:00:59

That's awesome advice. And it's something that I get asked on a regular basis, right? How can we, as admins up scale, make themselves the biggest value add to their employer? So, especially in the competitive market space. Um, so thanks for uh the insight there. A quick question for you, uh, an honest answer, please. Um on a scale of one to ten, how good would you say you guys now are at mergers? 10 being we're the best in the business, one being we're terrible.

SPEAKER_04 1:01:35

10. 10. The the amount of work and effort and care that we put into I think the hardest thing that any company does, which is is merging with another company. That is so foundationally challenging and hard, and there's emotions and finances and technology. It's it's it's a combination of everything. And being good at that is so foundationally important. I I'd say we are 10 on that. There's always opportunity for improvement, um, but we care at such a foundational level, and we want to make it as perfect as we can.

SPEAKER_03 1:02:15

What would you improve on? It very quickly, what would you improve on? What are you what would you like to do as part of that merger process that you're not doing today, whether it's because of the business you physically can't, or you've just not had chance to incorporate as part of your process? I would say to make it 11, we get to 11 out of 10. So, what would that be?

SPEAKER_04 1:02:36

To get to 11 out of 10, make our platform do everything for everyone everywhere. Um as I look at CRM, everyone's done different components, different technology integrations with CRM in the space. So there are situations where we just haven't gotten to a particular feature uh within our CRM that we really, really want to. But we've been working on this thing over here, maybe an agreements module that we've been deep diving in, making sure that that's got uh deep integrations elsewhere, and we've not done a deep integration into the insurance side of a financial plan into the CRM. But someone comes along and they're like, Well, we have that, I need that, and we're like, it's absolutely on the roadmap. So balancing the additional development and continuing to mature our platform as the wealth management industry continues to mature in a more deeply integrated environment and platform world, where if you look at a client relationship and wealth management, it's really defined by about 40 different business processes that a team does with their clients from client meetings to that financial plan to that money movement. Making sure that we've got every single one of those clear, well-built, awesome user experience. That's our that's a roadmap, right? Um, continuing to do that is what will continue to bring us from 10 to 11 of having as a team comes on, how do you do X? It's over here. How do you do Y? Oh, it's here. Uh, and it's great, it's better than any other experience that they can get in the industry. That's the goal.

SPEAKER_01 1:04:22

Fantastic. Um, yeah, I definitely agree with you that there's no there's no comparison to caring, right? That's gonna that's gonna keep you at your game because people care about their work ethic and about producing quality. Um and that's kind of just like the bottom line. Um with regarding giving yourself a 10, just to say you're you're all you're operating in a single industry and you face a unique set of challenges, and I think you got really good at those. Um, but I think if you look at some other industries here, you have to be much harder to merge works. Um, I know because I've seen them. Um again, not enough, it's just saying um, I'll give you an example, um B2B SaaS companies where they buy very similar products and a lot of similar company names, and you gotta match them up, and there's heavy overlap of data. Um very different sales processes. It might be merging the products into a single product. Right. There's a lot, a lot of different complexities when it comes to kind of kind of data migrations. Um and you guys have kind of have this called luxury of um we don't have multiple world managers. So I don't think you have a heavy overlap of data, that's fair, do you think? Yeah, I I anyhow.

SPEAKER_04 1:05:49

Yeah, no, I I uh I would agree with you. Thank goodness I'm not in steel plate manufacturing. Uh one of the really cool things for for me personally. Has been uh I used to be based out of New York City and we've since relocated out to Philadelphia. And one of the things that that's given me a deep access to uh from an executive perspective is other CTOs in other industries who are either in really out here in a lot of manufacturing uh and a lot of logistics, and those business models are so different and so interesting. Uh, if I had to do a merger of two teams uh in either B2B SaaS or in um some sort of manufacturing where there's an SAP behind the scenes, I'd have to learn the playbook over again. Um, there's a lot of fundamentals that I've got, but absolutely agreed with you. And I'll take luck plus skill, I I think is oftentimes success. You don't have both. Uh you don't have success without a little bit of both.

SPEAKER_01 1:06:50

Yeah, that's true. Um, all right, so looking forward, man. What's next? Uh what's next for Sarity? Salesforce just at Dreamforce, lots of great announcements. Um, they're always pushing AI. Yeah, one of the force. So what yeah, what's next for you? And you just putting aside the next merger. Um any interesting projects coming up or anything particularly you're excited about?

SPEAKER_04 1:07:12

Well, one of the things that that we've done is is we have bifurcated the merger teams versus the teams who build net new functionality within the platform. That's been essential for success. Is if I look my my my other partners in the eye and I say, well, we're not building your thing because we're busy doing this merger work over here, that's not super great. Um, so we're always looking at net new technology. Um Salesforce, the the foundations product that that was announced, uh, this next version of service cloud plus sales cloud plus little data cloud plus marketing. I think the uh getting in the door with Salesforce with net new products that you're not using today is often enormously expensive. And so I look at that announcement, which is almost giving a little sprinkling of a bunch of the tools that marketing accounts, engagement, for example, a little sprinkling of that, not enough to really do everything that we need to do at our scale. But pre to now, I didn't have any ability to look at. Hey, let me try data cloud out in a production environment with our data alongside our our our data security and all that good stuff. Um, I'm interested in that. The work that Salesforce is doing on flows continues to blow me out of the water. That's fantastic. Um, I used to always look at unofficialsf.com for what are the components that they're getting. And now I believe Salesforce brought that gentleman in some time ago, but he's had a fantastic influence on the development roadmap for flows. Um, it changes the equation sometimes as we're looking. Do we need to build an LWC for a particular bit of functionality? Or can I use flows? Even if it's for V1, V2, or V3 of that, before we've really gotten the business logic layered down. Um, that's exciting stuff.

SPEAKER_03 1:09:13

Awesome. Alrighty, I think that's a wrap. So I would like to say a big thank you to Stefan uh Ludlow for giving us your time uh today and sharing a lot, right? We covered a lot of ground uh around mergers and Salesforce and Financial Service Cloud, other kind of wealth management related processes and systems. So uh really valuable. Um, and it's and it's clear you've still got a lot of room to do a lot of cool things in your space. So thank you.

SPEAKER_04 1:09:49

The pleasure was mine, guys. Thank you so much for having me on the show. Uh, looking forward to seeing where you guys continue to take it. Uh, it's been awesome listening to the podcast so far, and uh look forward to being an active listener in the future.

SPEAKER_03 1:10:03

We'll we'll count on that for us for our listeners. Please do not forget to subscribe to the CRM Success Show for more episodes featuring leaders like Stefan, who are really well and truly shaping the future of CRM. Thank you.