SPEAKER_00 0:02

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

SPEAKER_03 0:33

Welcome to the CRM Success Show. Today we're talking with Charles Van Fleet, Senior Director of Enterprise Applications at the Standard BioTool Tools. Welcome, Charles.

SPEAKER_02 0:41

Hey, thanks for having me. So, Charles, we'd like to start our podcast. Super simple. If you've listened to an episode, you know what I'm going to ask you already. Tell our listeners a little bit about Charles and also off the back of that, a little bit about standard biotools as well, boys.

SPEAKER_01 0:56

Yep, no worries. Yeah, so I guess, you know, from a history lesson perspective, over 20 years in the IT space in various companies, started way back in the 90s in basically database marketing before going to Verizon for about nine years. From there is really when I jumped into the work that I'm doing these days, which is enterprise applications and MA work. So I've been doing that for a number of years now, roughly 20 at this point. The enterprise applications that I work on, you know, from a high level are most notably CRM and ERP, and then the ecosystems around that, whether it be the integrations or the add-on applications that you need to augment the functionality that comes the box with your CRM andor ERP. Starting back then, that roughly 20 years, that's when I started getting my toes into the Salesforce ecosystem. Very basic initially, very simple implementation. I think it was done by myself and one person from sales, actually from Salesforce at the time, way back then. Over the years, I've done many different implementations on multiple companies. I mentioned that earlier, but the industries that I go, I was at DG, which is an advertising distribution company, TV, radio, online ads, implemented Salesforce there for their business, moved to Benefit Mall and did a very similar implementation, which was bringing two different companies together to utilize Salesforce as kind of that way to merge them together to see information from like customers on both sides. Benefit Mall is a general insurance agency that also has a digital platform to support independent brokers, CPAs, small businesses to do their health benefits, the quoting, the enrollment, and also payroll administration. From there, I went to Service Experts, did a very small Salesforce implementation there. Service Experts is a home services company, but for CRM, actually, what we ended up doing with the end because it was the right fit was a different application. It was very specific to the trades. So this small implement implementation of Salesforce was for a new greenfield business that we were starting. So we started out with Salesforce there until it grew and brought it into kind of the mothership. From there, I went over to for the most part where I am today. I say it because I went to a company called Soma Logic that's in the proteomics space, but we were acquired by Standard Biotools, which is where I am today. And just a merger of companies like companies, I guess I should say, where Soma Logic is very heavy into proteomics, very specifically. Standard BioTools has instruments as well that we sell and service as well as consumables, which was kind of the overlap there with Soma Logic. Outside of that, I did CRM consulting for a few years on my own and implemented and improved enhanced more so Salesforce orgs, but other like home builder CRM, those types of things for a few years. Awesome.

SPEAKER_02 4:23

Great intro. So it took a lot of the follow-up questions out of my train of thought. One one I did have though is obviously MA has been a big part of your career, Charles. Would you say you've been more so on the merger side or the acquired side over the years?

SPEAKER_01 4:38

Honestly, I would say it'd probably be half and half because I've done acquisitions, you know, straight up acquisitions, but also mergers. Here was a merger, and actually we're going through a merger again here. So kind of the second one here, but acquisitions as well. Acquisitions at Benefit Mall, at DG, going all the way back to when I was at Verizon and uh working on some of the acquisitions that we did there. Do you have a preference between the two? My preference would probably be merger, because most likely, I guess in that scenario, what I would focus on, I think is a little bit more interesting, especially when you're working with the different groups. And if there's different, if it's different product sets trying to be merged together because they're like customers, it makes it more interesting. And I just feel I've learned more about the business that way.

SPEAKER_02 5:32

I guess to not assume anything, how would you go about defining merger versus acquisition when it comes to your role in applications and leading application teams?

SPEAKER_01 5:44

Yeah, so it kind of I guess it depends on the situation, but from a you know, a merger perspective, although you may be coming in as a merger of equals, which is what uh standard standard biotools and Sonologic. So it was a merger of equals. There was a dominating company in that. But at the end of the day, when we started to dig into the work that needed to happen to bring the companies together very specifically in enterprise applications, there was a very defined process that we put together. So it wasn't we're just going to cram these things together. There was meaning to it, kind of going back to why I you know prefer, uh, would prefer a merger over an acquisition. There was there was meaning to what we were trying to put together when it's a merger like that. From an acquisition perspective, you may not, in my experience, but you may not be able to bring everything together at once. And what I mean by that is maybe it's a true acquisition business, you know, business model, which we we kind of set up here because that was the go forward at standard biotools, was an acquisition model. So creating a basically a CRM center of excellence to where acquired new company keeps running as it is, and we you know we use data cloud, etc. to pull the information into our CRM Center of Excellence, which is our core Salesforce org, to do out do the reporting until we can get to bring all the other acquisition into the mothership of that core org.

SPEAKER_02 7:21

I see. So four and a half years at standard bio tools. I'm sure, I mean, has it felt like four and a half years gone quicker than you thought, or has it really felt like four and a half years?

SPEAKER_01 7:31

It's yeah, there's days that it's felt like four and a half years, but it has really gone by fairly quickly. The the work that we've been able to do from a merger and acquisition perspective, but also the products we've been able to work on has been so vast. It's given not only me, but my entire team experience that we either did not have in certain areas or experience that maybe we wouldn't have sought out if we were just going and looking for another job. It made the time go by fast. And to be quite candid, kind of a shout out to my team. I have not put together a better team than I've got here at Standard BioTools. So it's the camaraderies made it much more pleasant to come to work each day when you're versus coming into a situation where you've got contention all over the place. It's gone by fairly fast.

SPEAKER_02 8:21

Good. That's great to hear. Now, I had the pleasure of meeting you recently in person at Texas Streaming not too long ago, and I was able to learn a bit more about standard biotools, what they do for the sake of those that haven't heard of standard biotools, just give us the high-level what do they do? What do they sell? How do they make their revenue? Tell us more. Sure.

SPEAKER_01 8:42

Basically, at the highest level, a life sciences company. Once you start to get below that, you start to get me into the weeds because of all the science. But basically, we manufacture instruments where tests are run to identify disease, uh, etc. So for research and all of that, we also sell consumables that you would utilize on those instruments to run the samples of blood and all of that. And we service the instruments in the field. So yeah, that's at the highest level what standard biotools is.

SPEAKER_02 9:21

They're a little bit different than AC and heaters in the prior role, right? Yeah, cool. So, in terms of Salesforce, now I know we're gonna talk a little bit about the implementation in great detail, but just let us know how is Salesforce used now today at standard biotools? Is it purely sales? Are there service reps in the field using the platform? Tell us about that.

SPEAKER_01 9:44

Yeah. Current usage is for sales service marketing. So we use marketing automation of Salesforce. Uh, field service was a big one for us, and we use it for customer support and then data and analytics. Those are the key components that we use that are used today with Soma Logic before we divested them. There were a number of other products that we used, such as HealthCloud. We were on HealthCloud at that company, and we when we divested the HealthCloud platform or org, I should say, went with them. So current just sales service, marketing, field service, customer support, and then of course reporting data.

SPEAKER_02 10:30

Still quite a decent amount, and that you said just, but still quite a decent footprint. Roughly how many users?

SPEAKER_01 10:36

We have approximately 550 licenses. The usage currently is significantly less than that. Probably let's call it about half of that due to the divesture of some logic.

SPEAKER_02 10:50

Oh, yeah. Okay. So I guess to set the scene for the Greenfield implementation, merger of two companies came together. When was this roughly?

SPEAKER_01 11:03

I believe the close was in January of 24th.

SPEAKER_02 11:07

Okay, so fairly recent, couple last couple of years basically. So yeah, tell tell us a little bit about the kind of were both sides coming in with it with Salesforce already in use? Was it an equal usage, good adoption on both sides, a similar kind of tech stack, or was it completely different worlds?

SPEAKER_01 11:26

It was both both companies used Salesforce as as their CRM. Some logic used it. Lots of similarities, but then there were some big differences between the two. So at merger close, we set up the a committee was set up to determine, okay, how who's going to own what? I was selected for enterprise applications and the biggest one at the time being CRM. And so the first thing we had to do was determine, okay, what CRM are we going to use? So that was the first question out of the gate. And I was myself, my team were put in charge of determining what this needed to be.

SPEAKER_03 12:07

So you were clearly on the standard biotool side of the merger. They had a Salesforce team, I would assume, Soma. So what happened, what happened with them? Were they pulled into your team, rolled up into you, and then you start making the decision-making process? Were there a negotiation there? Like, how did that work?

SPEAKER_01 12:28

The so I came from the SOMA logic side. We had a very experienced team. The standard bio tools side, they were running Salesforce basically in the business. It was the commercial, I think at the time, commercial operations. They had a few folks that managed the system. And then they would, if there were any large development efforts, they burst with a contractor to come in and help them out with that. Where on kind of our steady state at Soma Logic, we were all internal. That was the goal of the company that I was brought on to build the team to be all internal versus utilizing contractors as consultants for day-to-day. So to answer your second part of that, the commercial operations team became, I don't want to say true commercial operations because they were, but Salesforce came to my team and then we partnered heavily with that team, but ownership shifted completely to myself and my team.

SPEAKER_03 13:35

So yeah, the walk walk us walk us through that journey, right? You're being told of this merger, you're being told in okay, great, you owned a Salesforce org. Now we own two to figure out the pass forward. I I guess you can chalk it up for some level of luck that you're not competing with another power center. So it seems to be that there was a little resistance, at least on the other side, which I guess is a good thing. Yeah, so walk us through that journey. Okay, what's going through your head? What do you come up with a 30-day, 90-day plan? Were you given a mandate of a plan?

unknown 14:07

Yeah.

SPEAKER_01 14:08

We were given the so the the direction was uh initially the first the first part was determine what CRM we're going to use. The you take the the step down, and once we got a little bit further, but the next level of objectives were consolidate to one platform already defined, but then we want to gain efficiencies across sorry within all of the workflows, but then standardize processes that are similar or being consumed by where there were two teams, now it's one team. So standardize the processes as we build it out, and then a stretch goal at the time was cost reduction. So as both companies had Salesforce, but we were really both companies were really at an inflection point. They call it perfect timing for a project like this to kick off. But due to the expiration of both Salesforce contracts within a year of each other, it was okay, since we are we can start fresh, let's go ahead and open it up and at least take a look at the CRM landscape, see what's out there. Does it make sense to potentially move to another CRM? Does it not? So we looked at the landscape. I won't say that we dug into it in huge detail, but we, as an example, of course, looking at Salesforce, both ERPs in coincidence were D365. Okay, let's take a look at uh D365, their CRM process. And I had actually at service experts had implemented that at a couple of locations, both CRM and field service for them. And then the corporate ERP was D365. So I had an experience there. So it that was on the list of hey, this is a potential, and then HubSpot and Oracle.

SPEAKER_03 16:11

When we looked at those dynamics CRM, you're saying were they potential?

SPEAKER_01 16:16

Yes. Okay. And so we in looking at HubSpot, it didn't provide all the functionality. We wanted Oracle, you're we weren't embedded with Oracle, so it didn't make sense.

SPEAKER_03 16:29

Yeah, there's no need to justify canceling Oracle CRM off your list. We understand.

SPEAKER_01 16:35

And so then it was okay, do you look at or do we do D365 or Salesforce? The business had some preference with Salesforce. And in looking at D365, and based on my experience, yeah, we could have implemented it, but the ERPs were undergoing the same sort of project that we were, which was consolidating to one platform, one version of D365. There were complexities there and delays that had impacted it. So the decision that I made was okay, from a recommendation perspective, we go with Salesforce over D365. We don't have the ability, the time to wait for their journey to at least get to a point where it's stable enough for us to come in and start, you know, poking it or adding integrations and more complexity in what they were doing, therefore delaying their project. So ultimate recommendation I made was moving to Salesforce for, I should say, consolidating to one Salesforce, but made the recommendation as making it a greenfield implementation versus going from say the moving standard biotools to the SOMA Logic instance. It was a true greenfield implementation, starting fresh. And that's the way we got that approved by providing it to our C-suite and the recommendation with the backup as well as the ROI behind it.

SPEAKER_03 18:04

Though it sounds like you guys either didn't or very briefly considered, or not very briefly, even considered keeping two separate CRMs. That was completely not an option.

SPEAKER_01 18:16

It was in theory, yes, we could have done that, but from my perspective, no, it wasn't an option. One of the actually I guess the next step in our journey was determining which which CR, which sorry, which Salesforce org to go to. So as a part of that, we looked at the overall health of both orgs. I think I mentioned just briefly earlier the standard bio org had it was at its limits. It was not licensed correctly and was to the point where DevOps was not even possible. So there were that was a big issue for me. When you look at the Soma Logic side, Soma Logic had some very in-depth and I would say even overbuilt processes. So I made the recommendation to let's do a greenfield implementation, which will allow us to meet the actually the objectives that were set forward, which whereas the standardization process as well as cost reduction. And if we are able to get the budget approved, we'll hit that timeline objective as well. And so that recommend that's kind of the second piece of the recommendation. And we got that approved and started our true working journey.

SPEAKER_03 19:38

It's interesting that you went greenfield. Your ERPs are all Microsoft. I'm assuming you're an Outlook shop, which means Microsoft Teams. So everything is Microsoft. I'm not an expert on Microsoft pricing, but I'm pretty sure that when you're like a very big Microsoft enterprise, it'll almost give you dynamics for free dynamics here. And but integrates with Outlook better than Salesforce. And I think there's only one Outlook integration, not 15.

SPEAKER_01 20:15

So if you so you're asking me that question now. Back when we started looking at things, it I did not have evidence that the Microsoft platform was truly the way I would say integrated. So the different modules with within the platform that they have, my experience in the past had been it shows that you can connect, example, CRM to sales or what have you in to FNO, and it's out of the box, what have you. That is until you at the time, until you start to do customizations. If you're adding fields or what have you, you have to add them on both sides, you have to create the integration, etc. There was a much heavier lift in implementing D365 when I had done it at my company before. So I had that going in, and it was a big thing that was on my mind. And we had the Salesforce talent. So we made that recommendation. And yeah, D365, I just I wasn't comfortable with it for our users, and then definitely from a support perspective.

SPEAKER_03 21:25

Yeah, the the talent piece, the talent piece is a big thing. Uh me coming from the data side of things, you often get I often get asked the question, what's what's what tool should we integrate, what platform should we use? Informatica, MuleSoft, something else. And usually tell them the cost of the person to maintain it it almost outweighs every other decision on the on on the on the tooling because the pricing of the person to maintain it just when you have the skill in house and they're already doing other things, it will probably out probably outweigh everything else, even if it's not the optimal tool. Obviously, if it falls completely flat on its face for your particular use case, you're not going to do that, but it is a massive driver. It also strongly weighs in on the success of the project, right? When you know what to expect, even as a leader.

SPEAKER_01 22:18

Absolutely. And the results of the project at the end definitely prove proved that out.

SPEAKER_03 22:26

So from the the two companies, was there a big overlap in client base?

SPEAKER_01 22:31

There was, I'll say, pretty significant overlap. I don't have the numbers in regards to it, but I would say it seems like 30 to 50 percent of overlap in in customers was from I should say from a standard bio tool side, their customer count overlapping with what Soma Logic had. I believe that's how or what it was.

SPEAKER_03 22:54

Yeah, so that's probably also pretty pretty big driver into saying, okay, we should merge these orgs. Okay, great. Okay, great. Now what? So you say okay, we need to merge orgs, which means we have to unify processes or build two different processes, potentially with the same client base. So how did you how do you plan how do you plan this multi-org migration into a new org with a new code base?

SPEAKER_01 23:25

Yep. Initially, the first step was I brought in slalom to do a discovery and scoping session. Coming in fresh, we were just a a month or two in post-close. So bringing the organ two organizations, the business groups together to have a discovery session, get an understanding of the processes at a a high, or I should say, maybe a uh detailed enough level to be able to come up with you know some estimates of what it would take to do what needed to be done and what it would take to do it. So we went through discovery, got the the readout, and then put the the estimates together with slalom and brought that internal to socialize and I can make a recommendation to go forward. Ultimately, we went with slalom for the implementation of the project. So it was just a discovery session in the beginning, but to move to implementation with them. And it was basically we broke everything into different tracks. So, as an example, the sale, we had the sales team, we had the field service team, we had a data team, we had a customer support team, just a number of different tracks as we were calling them, and set that set out to do a requirement session within each one, get the detail requirements, which included okay, both sides. So the standard bio side that's on the side, and looking to okay, what's in common, what's not. Can we tweak things here to utilize one process? Maybe we need to, maybe a page layout is a little bit different, but we're able to use the same back-end fields, etc., between the two organizations to come up with those standardized processes. So did that within each track during the project.

SPEAKER_02 25:24

Sorry, just to take us aback for a second. Before you got to Slalom, even four years ago, it was a very crowded ecosystem when it came to partner selection, right? You've made that decision, you need the support of a partner, an SI, system integrator. How did you get to Slalom being the best fit for you? And was there a single metric that you were looking for when evaluating a vendor such as industry specialization, merchant acquisition environment, greenfield implementations, anything particular there, Charles?

SPEAKER_01 25:56

Yeah, the there were a lot of things that went into it. Was there a true like KPI or metric that went into it? No. I am huge on relationships. At Soma Logic, we had used Slalom previously. So they had a little bit of a leg up, and I said, let's bring Slalom in at a minimum to do the discovery so we can see what we're looking at here. So had had trust in them to do that and brought them in. And once we understood what kind of the big scope was, all the work involved, and I should add, we the biggest driving factors for the project were at the end of the day, the biggest one was timeline. And it had to do with those Salesforce contracts when they expired. And so we needed to get the orgs stood up both sides on it within when we started discovery within 12 months. That was the biggest thing. So that's why I was like, okay, this is an own commodity here. I've got, I can bring them in quickly, and we can do this discovery. They have background in the Soma Logic org, so we got a jump start there. We learned the SBI side of the house in the process and see how we can bring them together. When we got through discovery, the big question then was okay, do we do this with in-house resources only? Which my team could do. They've got all the skill sets across all the way across to do the implementation. The only thing there is there's no way we're going to hit it in the timeline because this was going to be a large effort requiring a lot of different specialties and a lot of different people. The other option is going to an SI or doing a combination of the two. So this decision was made: hey, we're definitely going to need an SI to hit the timeline, but I want to do a reverse staff AUG with my team so that they are actually working on the project. If they're working at development work, my developer was helping in those areas. We fully took on the data aspect of the project. So was a reverse staff AUG. And as we went and started thinking about okay, what are our options? The team got together and talked about past experience to determine, okay, but we should what should we look at? My experience has been using larger firms in the past has not been positive. I've used mid-sized firms as well and had some mixed results. I've even used some boutique firms that have had some mixed results there too. And so, knowing the success we had in the past with slalom, we asked them to put an estimate together from them on what it would take to get it done, and more so, probably how would could we accomplish this based on all this work that has to be done in this, what I thought was a very short period of time. So we looked at that and with the fact that we have used them in the past and had success, and they're they're the way that they work with me, I'm sure they do it elsewhere, but I just my experience, it's a constant conversation of okay, where do we need resources? Do we need all of these resources? If we don't need them, we're gonna take them off and we've got savings there, or we potentially need to shift that budget to another area because it's running higher than we anticipated. And so the fact that they worked with me in the past through those situations, I made the recommendation to go forward with slalom. So there was not an RFP done to go out, and the biggest reason timeline.

SPEAKER_03 29:39

Just briefly talking about timeline. So you did discovery. So how long did that take? So you had a year, right? Including the discovery. So how long did discovery take?

SPEAKER_01 29:47

I'll say discovery through getting the approval to go with slalom and all that, two months. So when we actually fast, yeah, through I'm sorry, once we actually started the implementation project, we had 10 months to finish it. And yes, that is very fast, and I have not seen the one move that fast at that phase either.

SPEAKER_03 30:10

Yeah, the cover we need to cover both Soma as well as standard bio tools. Check on the org plus understand the process and process unification, right? Yep. And potentially data unification, although you're doing that in-house. And did all that in two months in-depth, or you left in-depth stuff to do during the implementation?

SPEAKER_01 30:36

The one thing was that was done before discovery was the review of the two orgs. My team did that internally. So those those pieces were done. But then as we moved into it, yes, everything else that you had stated was what we got, let's say the high level scope, because once we got into the implementation and had the 10 months, we did do requirement sessions. So we would deep dive into, like I said, each of the tracks. And as a part of that, one of the the folks that was on the project within each track, basically over here, they're making some notes. These are all the fields that we need to look at. And then that's example, hand it off to another couple of folks that then do the mapping of okay, here's what it is in SBI, here's what it is in Soma Logic. It's going to come together and hey, perfect match. Or this one has by the pick list values.

SPEAKER_03 31:34

Yeah, I got it.

SPEAKER_01 31:35

Yep. And so work through all that in parallel with each track as it was going, as we were going through it.

SPEAKER_03 31:42

Yeah, so to be completely frank, sometimes what consulting firms do is they'll have a really short discovery phase, but really what it is, it's like it's like to come up with a proper plan and budget and estimate, you need some level of minimal discovery to produce even an SOW. Otherwise, you're just shooting blind in the dark, and it's just way too much work to give away for free, right? So that's what they do, they've kind of super surface level discovery, banging out in two months, and then you expect to do a second round of in-depth discovery during the build phrase, probably in some level of agile sprints, right? So you're doing discovery and build at the same time or in overlapping sprints or something. So that's exactly what that was. Okay, awesome. Did you put any teeth hold them to the contract? Because like if you miss that deadline, like that's hundreds of thousands of dollars in a renewed contract with Salesforce.

SPEAKER_01 32:37

Oh, I'm sorry. Say that question again because I thought you were talking to the slalom side.

SPEAKER_03 32:42

Yeah, so you guys put you put a contract together for slalom, and it and the contract says something like, Come hell or high water, we gotta go live in 10 months, otherwise, we're basically getting close to a million dollars. Let's say it has to be, right? You had 500 licenses that are gonna get renewed for no reason.

SPEAKER_01 32:56

So, yeah, how did you kind of guarantee that or at least that's the plan that we put forward? Obviously, we already talked about the 10 months. The way that I talk about it high level is there were two MVP releases in within those 10 months, and they were broken by the two different companies. We then broke the work down by those tracks within each of the two companies. Both companies participated in each, but you're focusing on getting the MVP out for the first round and then moving into the second round. And in theory, when we started going into that second round, you don't have as there's not as much lift because you've done a lot of that work already in the first round. So within that, it was very defined scope and sprints. The I can't say enough in regards to successing success and failures of CRM implementations and Salesforce specifically, because that's been the majority of mine, is if you don't have that leadership support, and I will say cheerleading through the process, you're not going to be successful because that lets the next level down stray, and then the next level down strays even more, and it goes on and on. Our leadership team from the very beginning were one-in-one, hand-in-hand support on the program. So I had that support and used it every meeting that I had, every steer, basically every steer code that I had, and then drove it when in conversation with folks. But in staying on track, we stuck to the MVP, which, yep, everybody says we're going to stick to the MVP, but then you don't. We did. We had to sacrifice some things as we went to stay on on track. And some of those we were able to make up in the end before go live, and but some of the things were pushed to after go live. And it was constant checking in. I worked every week on a it is either scheduled or impromptu with slalom. We would meet together, me and the slalom leaders, and talk about where we are within each track, the resources. Okay, we're burning hot in this area, we're really cool in this area. We need maybe we remove scope because something wasn't needed. So we've got this underrun over here. Okay, right now we don't need it, anything to fill that. So setting it aside for a little bit of a rainy day, but sticking to the MVP approach and working hand in hand with slalom to say, hey, this is what we have, this is what's upcoming. Here's where Slalom would come to me and say, This is where we can save you some. Let's let's reduce in this area. Or hey, your your guy on our data side, hats off to Brandon Struve, give him a shout out. He got ahead on the data piece of it. And so he took on more. And so that was able, we were able to shift some from Solemn more some more from Solemn onto to my team. So putting all that together is how we stayed on track, GP support, and just constant monitoring of excuse me, of re the resources and where we were to overall project.

SPEAKER_02 36:23

Charles, was this your first greenfield implementation or had you done a greenfield implementation prior? Yeah, I've done greenfield implementations prior, yes. So if you cast your mind back to that prior greenfield implementation or implementations, was there anything that you did differently this time around compared to before? I guess I asked for individuals that might be going through a greenfield implementation perhaps for the first time, they still exist. What would you what would your advice be to others going through that journey and maybe advice to yourself if you were going to do an additional one beyond in the future?

SPEAKER_01 36:55

Yeah, in in regards to like different two different greenfields that I did, including this one, the the previous one, I think it's in there, it was at Benefit Mall. And we did the greenfield implementation, bringing the two companies together, very similar, but the companies didn't use Salesforce at the time. We were admitting it straightforward. The I think where we failed the, I shouldn't say failed, because it was a success, but it got behind. So getting behind means it costs more. And there were some things there that where we had third parties involved, other third party CRMs actually, that we were integrating with that we did not know enough about from the from a technology perspective, which was okay, do you have this data? Yes, awesome. All right, now let's table that till we get a little bit further down the road and we're ready to work on the integration. Okay, we've got two, three months, whatever till go live, but and we're on this now. Oh, the data is not there. Yeah, we have it, but it's not available in the integration. They have their own platform that they've got the governance around and everything. It just wasn't something that was exposed. So you get into situations like that, and it can really burn time. And we burn some time trying to get exactly what we wanted. So it's being better prepared, it kind of trying to be better prepared in the unknown. So some more due diligence there. But I will also say that we had support from leadership, but it wasn't as strong and constant as it was here at Standard BioTools to bring them to both of those together. So overall, just doing a greenfield implementation, obviously it's fairly simple, no big deal. But as you get into these bigger ones, we had for our Go Live there at Benefit Mall, we I think we had 30 different data sources. So creating that the data warehouse and exposing and all of that at the same time. It's a that's a lot. So just making sure that you spend a lot of time on the data, especially these days, because what's the number number one reason AI initiatives fail? And it's because that data is no good. You got that data come coming in and it hasn't been cleansed, then you realized it much later back in the day, versus now where you're gonna notice it immediately. So a lot of focus has to be put on ensuring your data was cleansed. That's one of the things that we would have done a little bit different here at State of BioTools is forced the business to clean their data prior to moving it to the new greenfield platform. It caused issues. We cleaned those, the clean the issues up very quickly, but then the data cleansing has been ongoing ever since and it's hampering some of the agent force initiatives that we would like to go into.

SPEAKER_03 39:55

So besides besides the data being causing you headaches, what else? What else was the struggle during those 10 months that you were trying to raise to this deadline?

SPEAKER_01 40:06

Yeah, the so there were two the two biggest things that were issues. One was data, but honestly, from my team's perspective, we didn't know that it was an issue until after go live. So that's why I came hindsight, yep, spend uh time cleansing the data. It was a business decision to not cleanse it, but again, it's the business's data. We don't know how bad it is. And so hindsight, we would have saved a lot of time once, especially once both sides got into the org on all that data cleanse if it had been done prior. And then the second thing is we did an implementation of field service, and that was probably not probably, that was the least successful part of the implementation. We were going to timeline, we had MVP. The the biggest issue, or I should say one of the root causes, is they were coming from a system, but it was Salesforce, but that was very customized, and they had created some things in there to some to basically force some automation. And by doing that and us having to unwind it, previously they weren't able to use a lot of out-of-the-box functionality, especially as new things got released, because of those customizations. They liked the customizations, but the problem is one of our goals was to get as much out of the box as possible. And it was agreed to that some functionality would be lost due to those customizations. We hindsight, what we should have done is spent more time digging into the business processes. The excuse me, they weren't documented to the level that would have basically gotten us to the point that the project team to the point of understanding, okay, there's going to be some issues here. So we were too high level, which sounds weird because we spent a lot of time on it, but uh it just wasn't enough time. And three to six months after that, cleaning a lot of that up.

SPEAKER_02 42:20

So, Charles, I just want to go go back to to summarize basically don't take short shortcut steps when it comes to requirement gathering and then know what you're dealing with. The other, the other piece you touched on in terms of advice was exec support. The director as a VP. How can you influence that in terms of getting broader executive support and backing? Is there anything that like you that's in your control as a leader to ensure that you're getting maximum backing and that that voice is shared across the business? That then like if a CEO puts out a message or calls a town hall meeting and talks about why something's important, it filters down, right? More so sometimes than if you do it and you keep you're the one that keeps banging that drum. I guess that's where I'm going with that question is what is in your control as a leader?

SPEAKER_01 43:04

Yeah, and maybe that's one of the reasons that there was such success on this project. That sounds odd because I'm the one saying it and did it, but I always give all credit to my team. I did nothing, they did all the work, but you're right, that that is my responsibility, and that's I was out there fighting for that every day. And what I mean by that is I was talking to the leaders one-on-one, working sessions with some of them. So, like our chief, I can't remember if he was commercial officer or what have you, very involved in the beginning. So we had and we had weekly conversations, and so we could stay on track. Of course, we had the steer codes, but even actually my reporting structure was up to the to the CFO and talking to him, keeping him updated on everything and preaching, hitting home, the the fact that hey, we have to do this, we have to continue forward. If you don't do this, this is what's gonna happen. And I need you to go out and Get all of your peers to understand or to at least support what have you, so that we can keep this going. So part of my job was, as they say, managing up to make sure that they are all on the same page and supporting it as we move forward. And when there was some contention in regards to maybe a let's say the field service, there was some contention around that at Go Live time. And it was basic, it's basically me working with uh the leadership to say, okay, here's um here's what we need to do in regard because we're under this timeline, and what that means is post go live, we are going to be working on these 10 things or whatever to get it to a spot where the business users are happy. So it's just constant conversations that I'm having to help them or have them help me continue to drive the importance of the project and what it means for the company. How CEO send out emails giving an update and showing his support was another example.

SPEAKER_02 45:01

How much do you think experience is a factor? So you the example you gave, reflecting on your time back would benefit more. That was almost a decade before the standard bio. So do you feel like your own experience, you've got a decade extra under your belt, you've got a bit few more battle scars, you know what success looks like, you know what good looks like. Do you feel like naturally you were more in control of a new greenfield implementation? You were more focal, you backed yourself more. Do you think that was a factor? Just put quite simply that being more experienced, you were able to get more exec buy-in. Would it be fair to say that?

SPEAKER_01 45:34

Or I would say absolutely. So you go back to benefit mall. No, the the I guess my let me say that differently. My role at Summologic Standard BioTools, there it was, it is an elevated role. And it's basically decision making with informing. Obviously, if it's a 10 year million dollar purchase, I can't approve that transaction, but within the project, yeah, all the decisions were mine. I informed if leaders needed to be informed on a specific decision, but I ran it start to end. The one of the program managers over at Slalon was I've never seen an executive so involved in a project as you. And I think that comes from knowing all of the pitfalls that I've already gone through, especially when we talk about field service. When I was at Service Experts, that's a home services, very field service focused. Actually, it is field service. So it's technicians using that technology multiple times a day. So, yep, I did have more battle scars. If you really listen to the conversation that we've had, some folks might be confused as to that, that doesn't make sense. He said he implemented three or four different CRMs at one company. Yep, I did. So, because it's service experts, we were in a transition, we had got purchased while we were implementing one product. The company that bought us, they were in the process of Salesforce and SAP. There was a whole thing around that. Then we shifted and did a full analysis of SAP, CRM, if you can believe it, and field service, looking at Microsoft, looking at Salesforce, and then a uh trade industry specific Service Titan. At the end of the day, what's best for the company as a whole in that situation is was Service Titan because of what they did. There was so much out of the box. So implemented Service Titan, we did D365 implementation at a few centers, and we did for a greenfield business, lots of battascars there, especially from a uh discovery analysis perspective and vendor selection, going through that to where do I need to look at three or four different mid-size partners? No. What I can narrow things down much quicker, and then the ability to make the decisions and just inform definitely helped.

SPEAKER_02 48:05

Cool. So we spent a lot of this podcast reflecting, but we want to cast our minds forwards. The last few minutes, what's next for UN Standard Bio, any any future expansion of Salesforce, agent force, for example, anything like that on the roadmap for you for the rest of the year and going into 2027?

SPEAKER_01 48:25

Yeah, right now, what my team is working on is we've got some some time here because some of the changes that we've that standard biotools is going through. And so we're focusing on agent force and basically trials, POCs for agent force is what we're doing at the time. I should say currently, such as in customer service order entry, those things are what we're looking at to see if we can prove them out and what it would take moving forward to put those into production. So if we're working on those things uh right now, we continue the ongoing small minor enhancements, but right now the big things are the big thing is agent force and being able to get some of those efficiencies as long as the ROI is there.

SPEAKER_02 49:14

Amazing. And what are your general thoughts on AI and Salesforce? Maybe you've touched on agent force, but just in general, are you seeing you is that something that makes you feel excited? Is it something that makes you feel anxious? There's a lot of noise when it comes to AI. You know, where do you sit on that? What are your thoughts?

SPEAKER_01 49:30

All of the above.

SPEAKER_02 49:31

Yeah.

SPEAKER_01 49:32

We yeah, from uh a personal perspective, it's what I've seen and been hearing, Agent Force is working for, but from what I'm hearing, it's working for the big companies that have uh a lot of budget and can spend a lot of that and including ongoing to pay for it. I'm hearing that some some companies that have even been supported as they've built some of these things out are having to pull it back because it's too expensive or it's not meeting the business need. So, from my perspective, I think we're taking the right approach. My team actually took on the overall AI approach for the company, which included Salesforce, and we're we definitely have a preference for Salesforce. But just within Salesforce, you have proving out some of these small cases, but the big thing for us right now is still getting that data cleaned up, sure that these things are gonna work and they're gonna provide the correct information that they're truly looking for. That's the big thing. A lot of companies are running into the same thing. Yeah, we can build spend this time building these things, but as soon as we turn it on, it's incorrect because the data is bad. So I think you're hearing that across the board. But outside of that, getting the figuring out the the cost from a Salesforce perspective is very tough, at least in my experience. And I was talking to a a research firm recently, and I took away one of the quotes which was figuring out the token-based business model could be a career. Trying to get all that under control, but I think moving forward, it agent force is yep, it's gonna work. And more and more companies will be able to take uh advantage of it. I think there's just it's a longer road than some of the big boys that have the money to pour into it.

SPEAKER_02 51:22

I quickly wanted to ask your opinion on companies that are starting to look at uh in-house building their own CRM alternatives, vibe coding on lovable or other platforms similar to that. Do you think that's a genuine concern for Salesforce ecosystem? Or is it let them go and give it a go and they'll figure out that it probably won't do half the stuff that maybe a Salesforce off the shelf can do? What are your thoughts there?

SPEAKER_01 51:45

Yeah, when when I think about this, what immediately pops into my head is okay, we're back to the build versus buy decision in the enterprise application space, but we're just a development space overall. For I guess the way I see it is yeah, you can build your own CRM um by using all the DITL tools, and folks have, but is it going to meet the true business need? To me, as soon as you start to you've built your own, it's very basic, and now you got to start to add to it. And now you want it to integrate here. To me, it's just it's a lot of definitely upfront work. And then in theory, when you're supporting it, again, in theory, if you're not in building upon it, the support should be fairly, fairly easy. But you're not in a a true platform that has everything that you may need. And here's what here's one of the the areas that I see some of the companies and you know that I'll look at, they're really looking at D365 because it has all of those things already built in. You've got Copilot there, and back to what we talked about earlier and was brought up is the cost there and it being cheaper on the that platform versus Salesforce or some of the others. So I think there's a lot to figure out, but yep, it can be built uh in-house. I got a guy on my team that he's he built his own for his wife's business. So it's definitely doable. It's just how does it scale and meet the business needs?

SPEAKER_02 53:26

Perfect. Dreamforce. Um this episode will go live prior to Dreamforce, I believe. The plan is that you'll be there this year. Yeah, so absolutely. So if anyone wants to pick Charles's brain on the topics over a coffee or a beer, perhaps in in San Fran in in about a month's time, then reach out directly, I would be the uh the response. Fantastic. I look forward to seeing you there. And that's about all we have time for on on today's episode. So, Charles, thank you so much for uh for giving up your time to be with us today. We appreciate you. It was fun, I appreciate it.