Tips For Migrating To Financial Services Cloud From Sales and Service Cloud

Synopsis: Considering an FSC adoption or migration?
Join us for a special conversation with Jacob Schutt, CTO of Parallel Advisors to gain valuable insight around key platform migration decisions and how to keep your organization aligned throughout.

Speakers: Jacob Schutt, CTO, Parallel Advisors and Jon Pierre Millan, West Coast VP & Facilitator, EMS Consulting

0:00:05.4 Jon Pierre Millan: Alright, we’re gonna get things kicked off. Hello, everyone and thank you for joining our session today titled Tips for Migrating to Salesforce Financial Services Cloud from Sales and Service Cloud presented by EMS Consulting. Today’s conversation is part of our broader digital transformation series where we examine the impact Salesforce has on various transformative initiatives within the financial services industry. My name is Jon Pierre Millan. I’m you’re moderator today and I’m also a regional vice president here at EMS Consulting. Thank you for joining us.

0:00:37.0 JM: I have the privilege and honor to speak with Jake Schutt, the principal and chief technology officer at Parallel Advisors. Parallel Advisors is a firm comprised of financial advisors who hail from investment firms, ranging from both wirehouse firms, as well as RIAs. They support multi-custodian platforms and are based in several offices throughout the US, including San Francisco, Colorado, Ohio, Oklahoma and Hawaii. Outside of his role as chief technology officer, Jake has had former board roles at the Audubon California, Richardson Bay Audubon Center and the Wilmon Timberlands. He currently serves as an advisor board member for creativemass.com, a CRM overlay to financial services cloud and trustworthy.com, a family operating system for important documents and information.

0:01:32.5 JM: Jake is also published in the work titled Delivering the Paperless Office, an analysis of the five steps to help improve efficiency and reduce costs at firms. He has also been a speaker and co-presenter at Dreamforce. You can find Jake on LinkedIn at linkedin.com/in/jakeschutt. Jake resides in San Francisco Bay Area with his family. Jake, we are honored and excited for this conversation. How are you today?

0:02:00.6 Jake Schutt: I’m doing great. Thanks for having me. I really look forward to talking about this. This is one of the topics that’s pretty near and dear to my heart and obviously, to the industry at large, so really looking forward to it.

0:02:11.0 JM: Absolutely, Jake, and we are thrilled to have you. We’re excited about the conversation. We think our audience is in for a treat. Before we get started today, everyone is welcome to submit questions through the Zoom chat feature throughout the presentation. We will address them at the end or we will follow up with you directly via email if we’re not able to answer it live. I wanna take a little bit of time here to just discuss the overall outline of today’s conversation for the folks joining now. As I mentioned before, I think the audience is in for a real treat here.

0:02:44.7 JM: As the CTO, Jake, you’re one of the primary driving forces for innovation at Parallel Advisors. We talk a lot about your guiding principles for technology, decision-making and how you have helped lead the advisors team through a migration from Sales and Service Cloud to FSC. Incredibly relevant topic, as you said, for the folks joining us today because there’s a lot of financial services organizations out there that may be considering a migration similar to the one that you just went through, or even adopting financial services cloud for the first time. So you and your team partnered with EMS Consulting to work through that migration. I think there’s a lot to learn from your story, and it can be complex. So what we’ve done is we’ve broken it out into four sections. The first is the what, so to speak. So why it’s an important conversation for the audience today, how did we get here and very much relevant issues and topics that need to be addressed.

0:03:42.8 JM: The second part of today’s conversation will be, how do you do it? So as an organization, what are the things that we need to know and how do you address those? And then the third is learnings, what can we learn from the process you went through and certainly, the journey and your team, and help folks maybe miss any of those potholes or obstacles, or challenges and how to anticipate those. And last but certainly not least, we’ll finalize our conversation today on partnership and how you think about evaluating a partner for these kinds of things. So with that being said, let’s dive right into it. I know we’ve got a lot of content to cover, so first of all, can you talk us through your guiding principles for making technology decisions at Parallel Advisors? And more specifically, how do you decide which technology and which platforms to say yes and which ones to say no to?

0:04:36.9 JS: Yeah, I think that’s a great place to start. And I’ll say it at the outset that stubbing our toes is one way that we learned a lot of things, so plenty of mistakes along the way, but one of the things that we do in the way we think about evaluating technology in general is putting it through a crucible of decisions that we come up with. And those are some simple ones but they help guide us when we’re looking at any technology and keep us on the straight and narrow and weed out a lot of things so that our time is spent more efficiently. And so some of those things are… The first one is, it has to be cloud-based. And when we started the firm back in 2006, this was heresy but it’s now the norm. And so we want every system that we use to be cloud-based and in that way, it’s much more secure and stable, and it can scale more easily, and it’s more efficient. And I think everybody knows that today, so that’s not that profound but it does weed out some of the systems, even in today’s world.

0:05:47.7 JS: The next thing we wanted to do is we wanted to utilize what we perceived to be industry leaders who are innovating regularly and drive value to their clients or to our clients and ultimately to our firm. And so by picking industry leaders, you may lose out on some of the newer ones that might be innovating more quickly but you benefit in scale and size, and dollars. And that ties in to the next thing which is that we wanna make sure that the partners we’re using have a very deep development path. We spent a lot of time talking to them about what they have on their roadmaps and the dollars that they’re gonna contribute, and the timelines that they have to continue to innovate and obviously, we want that innovation to be aligned with where we’re going as a firm.

0:06:35.8 JS: And so that’s actually a pretty good one to spend a lot of time on with the vendors that you’re interviewing because it tells you a lot about them, their firm, and then it also allows you to dovetail into the next one which we consider is that, can we partner with those firms to influence that development path to our own benefit? And ultimately, they make decisions about this but if we can demonstrate why we think it’s relevant for them to allocate their resources in one way or another, it benefits us and it will most likely benefit a lot of the firms that they’re targeting, ultimately, in the long run. And so that’s something we’ve done for a long time with many vendors, including Salesforce. And so those are the four main ones.

0:07:28.0 JS: We wanna be an industry leader in our space but we don’t wanna be on the bleeding edge of innovation. There’s a lot of ways to, as I mentioned, stub your toe or to potentially get yourself in trouble if you’re right on the bleeding edge, and so we wanna take stock of where the industry is going, evaluate it, understand the trend and then canvas that particular niche and find the best, the leaders in the space with the things I’ve mentioned… With the attributes I’ve mentioned.

0:08:00.0 JM: Jake, you mentioned something there that I believe will resonate very, very deeply with a lot of the firms out there who are considering or perhaps embarking on their journey within the Salesforce ecosystem for the first time, or maybe they’re considering a migration. So a lot of that is incredibly relevant, specifically to the direction not only your firm is going but the partners you associate yourself with. And I know that Parallel Advisors had previously been on the Salesforce CRM platform, more specifically with Sales and Service Cloud for many years prior to the migration, so how did you know that it was time to migrate or to upgrade up to Financial Services Cloud? What was it about that platform, maybe the data model? What was so attractive to you and was there something that happened? What let you know it was time? Was there a mile marker? How do you think about that?

0:08:55.6 JS: Yeah, in this case specifically, we were beta users on the original wealth management edition that Salesforce created and over the years, they’ve tweaked it quite a bit to service ourselves and our clients and to make it what we needed, and it worked very well for a very long time. We’ll talk a little bit about this later but there’s this trade-off between having a CRM system ruling you and you ruling the CRM system. But the way we knew it was time was that, with the rapid pace of change in our industry, there are better data constructs available, certainly without a seam. So that was the real reason we wanted to make the shift. We saw that the benefit of that new data architecture would allow us to continue to grow and innovate in ways that the old one wouldn’t. And you can argue that we were a little slow on this but nevertheless, that was the real thing that made us wanna make the jump. It leads us towards things that we can do in the future around AI and proactive notifications or next-best-action and workflows, and all these other things that you could do more nimbly on a better data architecture. You can also push data to your users much more easily without so much manual processes. So those are the things that we identified.

0:10:21.8 JM: That’s very relevant. You mentioned a lot in that response around the data model and understanding you were an early beta tester of the original, what excited you most about the data model specifically for Financial Service Cloud? What are you most looking forward to doing with it as you thought through your evaluation?

0:10:43.0 JS: Yeah, so more specifically, I think one of the things that we wanted to do was set ourself up to take advantage of what’s coming to our industry, not just through Salesforce and through its Salesforce partners but the industry at large. There’s so much happening. There are so many systems that are focused on servicing advisors and clients that are new that are gonna integrate or will provide data that we can take advantage of, and so this really gets into these things, these buzz words that you’ve been hearing about for a long time around artificial intelligence and for proactive notifications.

0:11:22.9 JS: So just thinking about the artificial intelligence thing for a minute. We think about it by answering or asking questions. So what’s most important to our client base and what can we learn from them based on the data that we have, whether it’s coming from… In our own CRM system, whether it’s the emails that we’re capturing or notes and tasks, or the behaviors that they’re doing? What can we glean from that data that’s most important to the client? Or conversely, what are we not addressing with the client based on the data that we’ve seen aggregated? And you can use AI to do those types of things. And so these are some of the things that we’re starting to think about integrating into the system but we can’t do it without the right data model, and so that’s one of the things that we’ve thought about.

0:12:13.5 JS: Proactive notifications are another one. They seem mundane when you think about them but they can be incredibly powerful and I think that there are a lot of tools out there today that can act as listening platforms where you can start to get proactive notifications on something that’s happening with your clients. And so if I can push a notification to an advisor that says, “Hey, your client’s just out of liquidity event, do you wanna reach out to them?” Just a simple yes or no. It’s just a… Think of it as a pop-up or, “Hey, this article is relevant to your client’s company, would you like to send them this article?” And those are some simple examples but that’s proactive reach out, very relevant to the client in a very timely manner where you can automate it so that I don’t have to put a body on that to go and search the web and make that happen. And so those are some simple ones that we think are nearer in term… Gonna be able to implement very quickly. And again, back to the data architecture, without that, without a flexible system that can allow us to program those types of things, we wouldn’t be able to do it.

0:13:23.5 JM: I appreciate that, Jake. And so it sounds like a lot to consider but really, when you boil it down, it’s utilizing something that’s cloud-based which, as you mentioned back then, it seemed like heresy, as you said, which I really enjoy. Utilizing partners that are moving in the same direction as you are, thinking about being at the cutting edge of the industry to attain specific features and functionality that…

0:13:49.3 JS: Yeah, and I think there’s a few other things that are gonna start to happen. Today, you own certain parts of the data that you have as a firm but then there’s room for other data streams to start pouring in, whether it’s coming from custodians or broader web searches, and I think those are also important things that we wanna be able to take advantage of.

0:14:12.5 JM: Absolutely. And certainly, as you think about the open infrastructure of the platform and the ability to connect and integrate with disparate source technologies, that’s obviously key consideration for anyone out there, even just considering Salesforce at large, let alone Financial Services Cloud. Just reflecting back on some of that, proactive notifications, utilizing machine learning and AI, the ability to push more data to your users, a lot of that should resonate with the broader audience for certain. It’s a lot to think about but even the format and process you follow seems to simplify it in such a way that if you’re addressing the primary goals and the end state of the company and the organization, you should have these things ticked off as you’re thinking about it. I wonder now… We pivot a little bit into the second theme of today’s conversation which is, well, all of that is great, these are the criteria that we should be thinking about and the direction marching towards but how do you do it? So what do organizations need to know? Organizationally, how did you prepare for this migration once those boxes were checked off and your decision was made, and you had buy-in across your stakeholders? How did you prepare for this? It seems like a daunting task.

0:15:34.8 JS: Yeah, it is a daunting task. I think that depending on the size and scope of your organization, it can be more or less so but nevertheless, I see… The analogy I made to the firm was, this is a little bit like a heart transplant with the patient awake on the table. We had to make a transition and do it in a way that had no disruption to the business. And our business is a 24/7 business, so that is a little bit daunting. I think that what we had to do initially was obviously, involve quite a few stakeholders from across the firm, from all aspects of the firm.

0:16:13.9 JS: Once we decided that we were ready to make the jump, we still had a lot of work ahead of us in terms of designing or building the new version of it to reflect, A, what we had and then to keep in mind what the new functionality might be. And so having those key stakeholders involved in all of that from the beginning was super important. They ultimately were not only our advocates in helping us design the system but also our advocates to the firm. And that’s around the why question, why do we do this? And communication is more than half the battle, both internally for your stakeholders at large, and so we constantly reiterate the why. Why are we doing this? What is it gonna do for us? And it helps to get buy-in, it helps to keep people on the same page, because there is inevitably pain involved in transitions. And so you’d have to go back to that, why am I putting myself through all this pain?

0:17:15.6 JS: So that was one of the things that we did, and the stakeholders had direct input to designing the system. It’s also crucial because the new system, inevitably, is gonna change workflows, and so you can start to understand what the impact might be and have them help us, the folks in charge of making the transition, to minimize the impact of workflow changes. Training is a huge piece. We’ll talk about that separately, I think, but when you get down to training, you have to have all of these I’s dotted and t’s crossed. And so understanding the implication of the change on the organization is crucially important and this gets back, in some ways, to try to minimize the complexity of the change. And so the way we thought about that was, we wanna recreate what we had in a way that people are very familiar, they’re gonna see what they’re gonna be used to seeing and then introduce the benefits or the new features and functionality to them in a way that they can digest it without putting onerous data hurdles in front of them. I mentioned earlier that ruling your CRM system instead of the other way around, having the CRM system rule you.

0:18:31.0 JS: If your people are spending too much time inputting data into the system, they become inefficient in the process, and it leads to a lot of frustration. And there’s no rule of thumb here, only you know your organization the best. But there is a fine line between having to keep lots of data into a system and then still getting out what you need. And so we think about that in sort of report types and those types of things, but we can talk a little bit more about that. But those are some of the things we did with stakeholders early on. And then once the system’s designed, one of the things we did was we loaded a bunch of test data into it, and spent a lot of time with the test data. And that was important because you think it’s gonna work a certain way, and then you throw hundreds or thousands of tasks in there or client records or other things, and you start to see where some of the nuances might impact workflows. So that was another thing we did.

0:19:31.6 JS: And then the last thing we did was, I had sort of mentioned already, was just lots of communication, so every single weekly meeting, talking about it, what’s the status of the project? What are we working on? How are we getting there? What am I gonna ask you guys to do? Ultimately, across the firm, constant reminders on the why, why are we doing this? We did a lot of sneak peaks along the way, so we had this core group with representative stakeholders from everybody, but we had sort of open Zoom meetings, which we’d invite anybody to to join, that gave them a sneak peak of the project, and that was also great because I learned a few things there myself in terms of what we thought we had figured out and what a fresh set of eyes pointed out to us that we didn’t, and so that ultimately helped us avoid some landmines along the way.

0:20:18.7 JM: I’d love to reflect on a couple of those points, Jake, ’cause I think, again, they resonate and then certainly should be applicable for our audiences. Of any project of this size and scope, you have to make sure that you have the stakeholders aligned, so that ongoing communication and reinforcement, the why we’re doing this, the what is the end state, or your north star, and you made a great analogy there in terms of everyone organization is unique and different, so there’s no silver bullet, if you will, and there’s no rule of thumb. So making sure you have alignment across the board, cross-functionally, have buy-in and reiterate that along the way, then designing the system so that it’s not totally different from what they’re used to, and minimizing that friction, if you will. And again, you just can’t over-emphasize the communication aspect of this, and then the other piece that you mentioned, which is just more of an executional thing, which is loading the test data in there. So that you have that stakeholder group, that pilot group, if you will, testing it along that data model, that same theme, along that same vein, if you will. Did you have to change any internal data models or make any data architecture decisions in preparation for the migration?

0:21:37.5 JS: We didn’t have to change the datasets that we brought over, but obviously, with any new system, there’s new functionality, and by default that means that there’s gonna be change, and obviously that’s why we’re doing this in the first place. It’s sort of a reminder to everybody, when you… If you do get any gray thing it’s, “Hey, this is the reason we’re doing it, we’re doing it because we want this change,” and so embracing the change is an important thing to continue to communicate. So that new functionality drives new workflows, it could be old data that you’ve loaded in there, but the new workflows change the way you interact with that data. And so whether it’s the way you collect it, the outputs, all of these types of things, the way that you click and view, which is the standard view paths or click paths that you’re used to change a little bit, and so those are things that you have to constantly remind people of and then be very clear about what the benefits are for them. I think one way, one sort of granular example of this between old Salesforce and new Salesforce for us, was the relationship model constructs.

0:22:40.9 JS: Wealth Management edition didn’t have a relationship model built into it, and so we sort of had shoehorned one together in our old way, but now we have this sort of more robust relationship aspect of FSC, and so that’s an entirely new concept with an entirely new set of workflows that had to be built around it, but one that provides great benefit to advisors, and this is one of the things that they liked about it, and so it can get complex. So I’m not saying it’s easy, but there are… It’s a really great way to be able to illustrate simply to the advisors and to operations folks and anybody that would look at a record, what the household looks like, who the players are in the household, what the kids look like, who the CPAs are, what business interests might be associated with the household, irrevocable trust, all those things can be mapped and included in the relationship, and we can even group households with other households. So there’s lots of ways to do it. Again, it’s not… I’m making it sound easier than it is, but if you can work through that construct and break it down into its most simple elements for training purposes, then it allows people to get the consent of words and language, and then you build workflows around it. And people have been very happy with that.

0:24:03.2 JM: Yeah, and you mentioned something there, Jake, although it may not be as simple as you’re making it sound, as you’ve already said, but even just the visual representation of that data, you touched upon householding and how… You mentioned you had been able to build something bespoke prior to, but now having that in a centralized place, so that as your teams cross-functionally are collaborating, that’s I think starting to talk a little bit more about the value of that data model and how you visualize, well, what does that stake, that household look like, and that’s gonna be unique for each organization, but just the benefit of knowing, as you mentioned already, those CPAs trust attorneys between households and those complex relationships, having them in a visualization element, that your advisors are able to utilize and leverage to the best of their overall ability, when you’re doing things like annual reviews or having ongoing dialogues and communications with your end users and your stakeholders. I wonder if we might ask another question, this is the last one in this section, in terms of considerations, but how long did the build phase of this migration take? And kinda going back to this idea of, it’s not as simple as it sounds, but it can be, if you think about this the right way, how long did it take to roll out the new instance of financial services cloud to the entire team?

0:25:26.1 JS: Yeah, well, I would say that we had the COVID moment and during this process for us. So I think again… Well, for us it took, I think from start to finish, about eight months, including sort of a pause there in the middle, where when COVID hit… When everybody was re-evaluating what’s happening in the world… Including that pause it was about eight months. I think the actual build and delivery phase took us about four months, and I think that it depends how prepared you are going into it, which drives this time frame, and obviously how large your organization is, and the training required, for us with 75 people, that was where we ended up. But we did spend a lot of time in the beginning mapping out exactly what we wanted, drawing out page by page, UI, and sort of whiteboarding the workflows, so we did a lot of that internally even before really ramping up the project with EMS. And I think that helps too in getting everybody on the same page as you talk about the build. So those are some really key steps that I think allowed us to keep the timeline relatively tight.

0:26:53.4 JM: You cannot over-emphasize the pre-planning, if you will, or pre-preparation required when you’re taking on a migration of this scope and size, so it sounds like you had made sure that your team was well equipped for that prior to even working with us, and so are there any tips that you would throw out to the audience relative to that planning cycle, are there learnings from that that you’ve taken on?

0:27:25.7 JS: Yeah. I’m sure we could write a small pamphlet on this, but the planning process on our side prior to the engagement of EMS was hugely important because, not only was it easier to communicate, and for EMS to grasp what we wanted, which is always a challenge when getting sort of deep in tech build-outs, but it also identified areas where we’d have to focus and spend more time understanding the implications of the new system when we went to build it. So there’s sort of these sort of… I call them sort of small circles where we have to go back and say, “Oh, now that we understand what we’re actually trying to do, and we sort of better understand the new system, that’s gonna change the workflow, so we need to go back and think about, can we simplify the process, can we make it easier? And so those are some of the things.

0:28:11.9 JS: One of those things I said generally to the firm was expect bumps, maybe it’s a little sandbagging on my side, but you wanna make sure that people don’t think that this is a snap of finger and everything is gonna work just perfectly fine, and so we did a lot of communication around it internally, that there would be unforeseen outcomes, bumps that we didn’t anticipate, ways that the technology, despite our best efforts didn’t work the way we expected it to, or the integrations that we had. And so the next thing that we did was we impressed upon everybody, not just our immediate stakeholders on the project team, but the firm at large was that none of this works without your participation, and so that was another sort of back to the know your “why” moment, why are we doing this? And so it’s important that people realize that in any relationship, it takes two to make it work, and you have a set of requirements in this process as well, to get trained up, to pay attention, to take the time to get to know what we’re doing. To understand what’s gonna be required of you. And so those are some things that did, we spent a lot of time on early on.

0:29:28.2 JM: You mentioned a lot about spending that preparation time early on, and then you made the analogy of the circle, kinda coming back once you’ve realized, well, this is actually what we’re trying to build, now that we’ve kind of uncovered or double clicked, if you will. Our CIO has a funny saying about that, attack the problem, not the people. As you work through these kinds of things, inevitably there will be obstacles that come up or considerations that you hadn’t anticipated prior to taking this on. I really do appreciate and wanna make sure that resonates with the audience that you impressed upon everyone that, this doesn’t work without their commitment to learn the new system, and to adapt to the change that’s coming, reiterating that “why”. So I just wanna make sure to echo that, it sounds like from what we’ve been hearing though, overall it went well. And certainly in this section of learnings and what other organizations can do to learn from your experience, I guess, how did you manage the shift from one to the next? Did you do a lot of training? Did folks need to kind of work hand-in-hand with you, did you have that built out? Or maybe we speak a little bit about how you relied on your partners in this vertical, but any thoughts there in terms of training for your organization for the stakeholders?

0:30:52.3 JS: Yeah, training is the make or break thing, it’s… You can do the best job possible on a transition, but if the training is weak, then you’re doomed. And so, yeah, again, we started with the “why”, we started with sneak peeks. This is very early on in the project, then we started moving to screenshots, even if they were mocked up screenshots that we literally created, not EMS, then we moved to formal trainings, this is now we’re getting closer to the project go live date, where three weeks out from the go live date, we had trainings every single day at a standard time, and we mandated to everybody at the firm that they had to participate in at least two trainings, and then we recorded those trainings and then we made PDFs of those recordings, and then we sent them to everybody on a regular basis, every all-hands meeting we were talking about them, we had the key project stakeholders going out and saying to everybody, You need to go to these training sessions. When people were in the training sessions we said, “Help us out here. Tell us… If you have a conversation with somebody, make sure to ask them, have they been to two trainings, and if they haven’t, please tell them to come to two trainings.”

0:32:11.1 JS: So we’re sort of co-opting everybody at every turn to do that, and then when people… And so we had various types of trainings, we had sort of general overview sessions, we had very specific sessions on key tasks, we know what the key tasks are per sort of constituent, and so for operations, they’re working on tasks a lot, so let’s do trainings on tasks, let’s do trainings on how they view task, let’s look at the cues, let’s figure out how the cues work for them, let’s… And then for advice or something different. And so we’ve clearly titled all of those training sessions in those ways, so the people knew what they were signing up for. We kept informal lists of people who never attended, and when necessary admonished them publicly, a little public shaming never hurts, to get them to come, and so by hook or by crook, we had a lot of folks involved in the pre-launch period. And so that was crucial, because when it goes live, if you haven’t done the training, you’re already behind the eight ball. And then when the project went live, we had standing open Zoom meetings all day long, every day for the first five days, so the project team just had a…

0:33:25.7 JS: We’re all sitting on that Zoom call all day long, and people could drop in and out of it, and then we went back to referring back to all those recordings that we had done, when people asked us questions that they should have already known the answers to. And so those are things that helped us to continually reinforce the things that we wanted them to know and do, and of course, there were issues that came up that were either some… Either data issues or little tweaks to the system, where people wanted to have default views set up in certain ways, and you just run those down as quickly as you possibly could, because it’s if you don’t do it quickly, then people lose trust in what they’re doing, they try to go back to their old system, which is not what you want, and so those are some other things that were important.

0:34:16.1 JM: Utilizing the users at the firm as advocates, as partners, as you go through this, is what I’m hearing, one of the fundamental components to your success, so it cannot just be a top-down, but it has to be all-hands-on-deck, bottoms-up approach where you’re tasking folks who can maybe raise their hand early on, and who are quick to the learning curve and are leveraging that system, and you utilize those ambassadors, if you will, to help promulgate and evangelize sort of the system at large, so that folks aren’t going back and regressing to other systems, or doing it the way that they’ve been doing it originally. And then another point you made, Jake, that I just cannot over-emphasize enough is just those trainings.

0:35:04.6 JM: At the end of the day, you have to keep steering the ship towards your north star and emphasizing why it’s a value for your users, why it’s important for them to get skilled up, and the value they get from the system, that they wouldn’t realize if they didn’t invest the time required to learn how to leverage the new platform. I guess a way to close out the third section in our conversation on learnings, is what, I guess advice, and you’ve already illustrated so many great points that hopefully resonate with our audience, but what advice… And I don’t wanna say what’s the most important consideration, ’cause I’d say they’re all very important, but what advice, what key consideration would you give to another financial services firm, or another wealth management company, who’s thinking about migrating from sales, or service cloud, to financial services cloud, what do they need to be successful?

0:36:03.8 JS: Yeah, I think it would just summarize some of the bullets that I said already, clearly articulate the “why” is hugely important. I would get stakeholders involved early, early on, design testing and roll out, I think training like we just went through is, again, hugely important, and it’s really something that’s never finished, that we still train all the time on this, and we’re building up that library of videos and PDFs for people to reference. And everybody knows where to go to get those. And when you get those sort of remedial questions that people should know as if they’ve looked at the training, then you can refer it to them more quickly, you can give it to them in multiple formats, so that’s hugely important, and then the last one is, continue to iterate, the system is sort of… I look at it as kind of a living and breathing thing as your business evolves, and so your system has to evolve as well, and so ongoing tweaks and obviously assistance with users as they run into road blocks or challenges, is hugely important. And so those are the four things that I would say, sum it up most clearly.

0:37:09.2 JM: Awesome. Moving towards the last section of today’s conversation around partnership, Jake, let’s pivot slightly. How do you think about evaluating partnership for this? For a project like this, for this kind of an undertaking? But not only this one, but just other digital transformation initiatives, how did you evaluate partners for this migration, how did you come to find who would be the right partner for you?

0:37:34.4 JS: Yeah, I think I’ll start a little further back than where your question’s pointing me, but I think the first thing, obviously, is having a very clear vision for your technology in general, without that, without those pillars, without understanding what problem you’re trying to solve, you really… That’s the most important thing, you have to start there and have a strong foundation, because in today’s world where technology is evolving quickly, or a lot of different systems are trying to build one-size-fits-all solutions, you need to understand what’s the most important thing for you and for your firm and where it’s going. So assuming that that box is checked, I think the next thing is then canvassing the marketplace for the solution that you’re looking for, and really pulling all strings there to find players in the space that know that niche well, and can make sure that you at least take that first broad look at all the players, and then from there, start to narrow it down using the constructs, those pillars that I mentioned earlier, and then once you get into conversations with those folks, you’re looking for all of the normal things.

0:38:52.0 JS: Which would be, what projects have they worked on in the past? How close do those projects mimic what you’re looking for? What integrations do you have to deal with, what integrations have they done, what are the direct experience with your integrations? Obviously, you’re getting examples of references in calling those folks, but looking through their core skill set based on where your project is going and what library of solutions they have available, is also hugely important because it saves ultimately you, dollars and time, you the clients dollars and time, in getting it built. So that they’re not learning on your dime, so to speak, and that you can leverage what they’ve done, and so that’s hugely important.

0:39:39.5 JS: And then just back to sort of the key pain points around integrations, integrations are always their own little ball of wax, and you need to know not only what the partner is able to solve for you, but any hurdles that the… Where the data is coming from. And so that’s sort of its own little side process that you’re running in the background, is making sure that those data integrations are aware of what you’re gonna do, so it’s almost like another… Part of your whole process is, making sure that your other partners that you’re gonna rely on to provide an answer the really nitty-gritty questions about how data is gonna move, that they’re up to speed and they’ve allocated resources to you. So those are some of the other things that I would think about. And they need to know your “why” because it takes it home for them in terms of your urgency, your requirements, and that’s just sort of working in partnership with your vendors to influence the direction they’re headed. If they know your “why”, then they are much more likely to be interested in partnering with you to make sure they solve your problems.

0:40:51.7 JM: That’s a fantastic way to round out today’s conversation, Jake, maybe time enough, I’m keeping my eye on the time and I’ve seen questions filtering in, but time enough to ask you maybe an off-work question, but this is one that I’ve leveraged from one of the podcasts I’ve heard from Tim Ferriss’ Show, but he asks his attendance, if there was a billboard with a message, what would it say and why?

0:41:25.7 JS: I think my billboard would say one of the mantras you’ve heard me repeat many times here, it is “know the why” that simple. I think it applies to many more things than just this technology project that we’re discussing here, but knowing the “why” in any instance, whether it’s with your partner, with your kids, with your own motivations, I think it’s a hugely important grounding question. It provides a lot of insight into the response that you start to answer that question with, or whether your vendor’s answering it, or your kid, or your partner, I think those are all things that can be pretty insightful if you really start to dig into that.

0:42:09.6 JM: There you have it, folks. Know your why. I love it, it’s a great message, and you’re right, Jake, it applies to so many other factors in life, so many other aspects, so thank you so much for this, for that, I do wanna just allow… We’ve got 15 minutes left here. Taylor, did you wanna just bring through a couple of the Q&A that we’ve seen bubble up throughout today’s conversation, and then we can answer those in real time.

0:42:38.7 S3: Absolutely, sure thing. So we got a question around integrations, and I can actually, I wanna expound on it, ’cause I too am curious. So the question is, were there any integrations that, Jake, that you and the team were using in Sales Cloud, that you had to migrate over to FSC? How did that go? Was it difficult to re-map those integrations? I.e. Discovery data, and then also, was it a clear cut… This is me adding on a little bit, was it a clear cut decision that you were going to bring all of those systems with you, or did you also have to re-evaluate those?

0:43:22.4 JS: So we didn’t have migrations to migrate over, we’ve had this sort of philosophy that we didn’t… For a long time that we didn’t want to have a lot of data integrations into Salesforce, historically, for a lot of reasons. One, to segment systems, because they were all cloud based it’s sort of easy to manage data across platforms. But having said that, we did create an integration from our performance provider during this project, and so we were piping in data, performance data, into Salesforce, and so that was a new project for us and required, as I mentioned, a lot of work from the performance provider as well, and so we had to spend a lot of time doing that. One of the things that I do think is important, getting back to testing and the build of this project, or as we build it, was that we actually did a test data migration, and I hadn’t talked about this yet, but I talked about putting test data in there. We did that sort of on a manual load, but we actually took a small segment of our data and did a test migration, as if we were gonna go live, and that actually found some things that we hadn’t planned or anticipated, and that helped in this integration format also. So I would say that that’s one of the learnings that I would put in my little pamphlet, if I had to print one.

0:45:00.5 JM: Taylor, thank you so much and Jake for that. It looks like we are reaching towards the end of today’s conversation, Jake, and we won’t belabor the point unless I’ll give one more minute to see if any other Q&A comes in, otherwise, that’s pretty much everything we had for today’s audience. Jake, thank you so much for taking the time out. We know you’re busy and taking time out to join us to speak to the migration. Any other closing thoughts you have for our audience before I wrap us up?

0:45:35.0 JS: No, thanks, J. P. I appreciate it. It was really great to be here and I always love talking about these topics, and it’s just amazing and challenging for all of us that wear the hat of technology, to keep up with everything that’s happening in our industry, it’s a full-time job to evaluate what solutions are out there and to sort through those solutions, and try to map how they might benefit your clients or your firm. So I feel for all the folks on the phone that are in the seat that I’m in, and happy to commiserate with anybody or share some stories at any time.

0:46:13.2 JM: Fantastic Jake, thanks again. And for those folks on the line, for more information on today’s session, the content will be featured on our website, so please reach out to us at consultems.com or reach out to me directly at [email protected], we’ll send across the recording, we thank everyone for your time this Thursday. Thank you so much. Appreciate the time.

0:46:39.4 JS: Thanks, take care.