Join us for the recap of this insightful virtual session: “The Art of Discovery: Salesforce Consulting Wisdom from Brian Murphey!”

With an illustrious career spanning over two decades, Brian has been at the forefront of Salesforce consulting, particularly within the healthcare and life sciences sectors. This exclusive 45-minute session is designed to provide attendees with invaluable insights, practical strategies, and the latest innovations in Salesforce applications.

Brian Murphey is not just a Salesforce Health Cloud Architect; he is a thought leader who has transformed numerous organizations by integrating Salesforce solutions with cutting-edge healthcare technology. As CEO of The CRM PhD, Brian has led a team of experts in crafting custom solutions that meet the unique demands of healthcare providers and life sciences companies. His deep understanding of the Salesforce platform, combined with his passion for innovation, has helped countless clients optimize their operations and improve patient outcomes.

This session is perfect for end users, consultants, leaders, developers, admins, BAs, and anyone who wants to hear the Architect perspective on Salesforce in Healthcare and the Life Sciences. We promise you won’t want to miss this!

Let us know if you have any questions or if you have any requests for our next CAS Come and See Video!

SPEAKERS:

Brian Murphey

Shannon J. Gregg

VIDEO TRANSCRIPT:

Hello everybody and welcome to the Life Sciences Virtual Trailblazer Group, I’m Shannon Gregg!

I’m from Pittsburgh, Pennsylvania, and I’ve been heading this group up for about a year and we love seeing everyone who is coming from either the Salesforce side, admins, developers, architects, BAS trainers.

We love seeing people come from industry, so folks that are working somehow in the life sciences, whether you are in drug r and d, compound development, diagnostics, genomics manufacturing or if you’re like, I don’t know anything about the life sciences, but I really wanted to hear Brian speak . . .

You are in the right place today because my friend and now yours, Brian Murphy is smart, so thoughtful, so prepared, and so aware of all of the things that are happening in Salesforce, in the healthcare and life sciences industry. I am beyond pleased to welcome Brian to the Life Sciences Virtual Trailblazer Group.

Brian, thanks for being here today. Thanks so much, Shannon. What a warm welcome. That definitely makes my Friday and week a lot better, so really appreciate that. And ditto. Shannon is awesome and I love working with her and doing projects with her. So always excited to get asked to be involved in things that she’s up to.

I’m gonna go ahead and share my screen and we’ll just start going through it. I put together a deck going to present. Can you see presentation? Looking good. All right, great. So I’m Brian Murphy. I am a Salesforce guy. I’ve been doing this for a long time. I’m also a healthcare guy. Been doing that for a long time.

Shannon asked me to come here today to talk through a more high level part of what I do, which is just consulting 1 0 1. I really focus in on the healthcare and life sciences industries, and we’ll discuss some of that as part of this presentation. But I think a lot of what I’m gonna talk about here is applicable no matter what field you work in.

A lot of it is very targeted at consultants, but in my opinion, having worked as both an internal and external resource for lots of companies I feel like everybody’s a consultant, right? You’re always using these skills to move projects forward, whether you actively work for the company or whether you’ve been hired by them.

So it’s the intention of this is really to give everybody some tools to add to their toolkit and some things to focus on the next meeting that you go into, the next project that you kick off, whatever the case may be. So why should you listen to me? Like I said, I’ve been. A Salesforce guy for over 10 years.

I’ve been in the life sciences and healthcare industries for over 10 years. Spent that time as a systems architect, a solution architect, a project manager, a program manager, a product manager, you name it. So I’ve kinda worked across the board in lots of different tech and IT roles both, like I said, on the payroll of various companies and working as an external consultant.

I started in enterprise healthcare, got my beak wet, working with large healthcare systems and HIEs with national implementations, things like that. A lot of large data structures. And then progressively worked my way down to more of a mid-market space, which I enjoy more, and we’ll get into some of that later.

But I learned a lot of lessons early on about how enterprises operate. And then have used that to apply those ideas and learnings to smaller companies with the goal of them scaling to become enterprise at some point. So I try to look at everything through that lens. No matter how small you are, one day you want to be all grown up, so we should set the path ahead of time that makes it the easiest for you to get there.

I’m the founder and CEO of boutique Salesforce. Si called the CRM PhD. Been around for I think about three years now. I think our anniversary just came up. Work with a lot of clients, big and small. Very busy right now. Have clients standing global pharma national provider networks. I work med device, I work with CROs, CDMOs, biotech, you name it.

If it’s healthcare or healthcare adjacent, then I’ve probably done. At least a handful, if not dozens of projects in that space and have at least one or two irons in the fire Currently. I work across the board as a consultant. I get hired by some companies to come in as just an architect or consultant to help them get unblocked on certain projects to help companies understand what the next steps are they need to take.

And then I’ve also got a full team that works behind me to do full implementations, support managed services, that kind of thing. So I try to work with customers to help them get their problems solved no matter what those problems are. It doesn’t always necessarily have to do with Salesforce specifically, but I approach everything that I do with Salesforce, at the center of everything.

And the goal is to get everything that everyone’s doing rooted around that so that we’ve got that central console to work out at. My team is global, but. Mostly onshore. The global elements are usually people that I’ve worked with that are just traveling and living the whole freelancer lifestyle as opposed to the offshore thing.

But it’s great. I work with some of the best people that I’ve met in my career. They sometimes have full-time jobs working at big tech companies and still want to come over and work with me part-time and put in a few hours just ’cause we keep it fun and keep it interesting. So I get to work with a really fantastic group of people, both at my company and through partnerships with people like Shannon.

So I’m constantly learning, constantly getting exposed to new people, new ideas, and it makes it a really fun work environment and lifestyle. I have a lot of control over my schedule when I’m not completely swamped at work, which is usually it’s always interesting.

It’s always creative. It’s pretty much always fun, honestly. It’s very rare that I wind up in situations where I’m just trudging through grueling projects and being miserable. It’s usually a really enjoyable thing for me. So that’s part of the approach that I want to talk about in this presentation. And I’m gonna start moving to this a little bit faster at the beginning, ’cause I wanna leave time at the end for some q and a and things.

But the big thing that I wanted to talk about here is discovery. Discovery isn’t just a thing that you do as part of a project. Discovery is a philosophy that should underpin everything you do as a consultant or a resource that’s working on a project team. Discovery is your opportunity to gain trust and access.

It’s your it’s your time that you get to develop relationships with the stakeholders on your team, whether they’re on your team or whether they’re on the client side, or whether they’re on the third party. It’s where you get to prove your worth and show that you’re a serious person and get them bought in on what you’re going to do as early as possible so that when the time comes to make decisions and things get tough, that you’ve got a team that’s willing to come together and make those things happen for you.

Discovery is also where you set all of your expectations right from the second you start talking about a project to anybody on the team. You’re setting expectations of some kind. You always need to be hypervigilant about that. Always set expectations appropriately. Otherwise you’re gonna be walking back what you said and you’re gonna be looking like an idiot and you’re gonna lose that trust that you spent so much time building and it’s just gonna erode everything out from under your feet and you’ll never really get that back.

Discovery starts before the actual sale happens. This is more of a consulting thing than an internal thing, but discovery happens well before the project kick off. From the moment you first start discussing a project, you should be doing discovery. You should be finding out key things about what is gonna happen in this project, who the stakeholders are, what their concerns are, what their objectives are, and speaking to that and building towards that in every move that you make.

It’s not something that gets handed off by a sales team to a delivery team to take over and hope that they have it all, have everything that they need and can go ahead with it. And then discovery is continuous throughout a project. There isn’t a point in a project that I’m not still doing discovery.

There’s always more to be done. There’s always more to learn. There’s always expectations to be set. There’s always new goals and shifts, so it’s not like you have a discovery phase and then you’re done doing discovery and you move on. You should treat every project like you’re just constantly doing discovery and factoring that into what you’re doing going forward.

I put in this little, graphic here, cost for discovery, 68% of failed Salesforce projects can be traced back to inadequate discovery phases. I have no idea if that’s actually a real metric. It just sounded cool and underpins my point. I don’t even know how you would actually qualify that metric at an industry level, but AI said it so I’m putting it up.

There might be a hallucination, but it works. But the basic idea is most of the projects that I see that are having problems, and I get brought into a lot of projects that are already in flight, that have ground to a halt and need to get unblocked, most of it can come down to not having spent the time to do discovery and take this discovery approach throughout the project so that as these problems arise, you’ve already got a plan for how to deal with them.

And the things that I see whenever projects don’t take this approach, scope creep, we’ve all seen it. Budget ever runs, nothing gets done on time, nothing comes in at cost. User assistance. People going, oh, this isn’t what I thought it was gonna be, man, I don’t want to do it. Or, yeah, that seems nice, but whatever.

It’s not really that important to me. You haven’t spent the time building the excitement and building the buy-in to make it so when you launch, people are actually gonna get benefit out of it. Core principles. So I just a caveat, I generated this entire presentation out of ai, this really cool tool called Gamma App.

I am not shilling for them whatsoever. I was just blown away at how fast it was able to pop things together for me. And I just typed in a basic outline and it spit all this stuff out that looks really great. So some of this is gonna look a really corporate and cheesy. That’s because I just kinda let the AI say its stuff and I’m just gonna talk on top of it.

But I wanted to call it out because I’m using AI more and more in every single aspect of what I do. And tools like that are a great way of taking what’s in here and getting it out here as fast as possible so I can focus more on. What I bring to the table as opposed to the data entry and, organizational parts of the business.

Just calling that out. But core principles of effective discovery. The first one is active listening. And I know it sounds like something everybody knows, right? But the reality is I sit on calls with other teams, with other consultants all the time that won’t shut up. They sit there and just talk and the customer is sitting there listening and they don’t spend any time understanding what the customer wants, understanding what the customer’s afraid of, understanding what the customer’s risks are, understanding what’s happened in the past that would make a customer feel a certain way.

So much of any project is understanding how your customer, whether that’s an internal customer or an external customer, how they feel. I tell people that I’m 25% Salesforce consulting and 75% a therapist. I spend most of my time talking to people, reassuring people. Making people feel heard and understood, getting people that don’t talk to each other on the same team, to get on a call and actually hash it out in front of me.

There are times that I sit on calls and all I do is welcome everybody to the call and then sit there and record while they argue with each other. And that’s totally okay. That’s a big part of what we want to do. We want to encourage people to tell us everything, to just put it all on the table. I tell people there’s nothing, there’s no such thing as a bad question or a dumb question.

Ask everything, assume nothing. If you feel like there might be something you’re making an assumption about, ask the question. Ask the dumb question every time, and let them tell you in hard terms exactly what they mean. Otherwise, you’ll always be dancing in circles around each other, right? And so much of that is literally about just saying, why do you do that?

And shutting up and letting them talk, right? Fight the urge to be the expert or. Be excited and tell them you’ve already got a solution. Another thing, empathetic understanding. So yeah, delivering solutions is important and that’s a part of what we do. But I’ll tell you this, enterprise and down, most of the solutions that I implement for companies are really basic.

It’s pretty rare in any project that I do that I’m actually doing something that’s super complex. Now, when you get up into big companies, there may be like a part of the project that we need to do some complexity. I’d say 75% of any given project at any scale is mostly basic Salesforce stuff and just helping people understand how to use it better and make the most out of it.

A lot of what I get called in to do is undoing very complex stuff that other people have built because they’ve been more solution focused than they have been an understanding how to solve a customer’s pain point. And so what you want to do is. Spend time early on with your clients or your stakeholders, understand why they’re having this problem, understand what’s led them to making the choice to run this project.

Understanding who have been people in the past that may have been difficult to work with or done things that didn’t wind up working as well as they’d hoped. Understand. Have they had a history of projects going over budget? Have they had a history of consultants that were difficult to work with? Things like that.

These are all things that you need to know from the get go so that you can assuage their fears and get them to open up to you and tell you all that stuff in 0.1 about active listening, right? As long as they think that you’re an outsider and they think that you’re just some consultant that’s there to plug some things together for ’em, and you’re not one of their friends and colleagues and part of their team that’s there to help, they’re never gonna get to that next level to tell you the source of what it is they’re trying to solve for, and you’re never gonna be able to build a solution that actually wow.

And I guess the third one, collaborative partnership. It’s never a client consultant relationship. We’re always on the same team, right? You hire me to be a part of your team for whatever the duration is that you hire me. I’ll tell you, I have yet to have a client since I started my own shop, except for a couple of very small cases that isn’t still a client.

People rarely a trip with me because once we become a part of their team, they become an indispensable part of their team, and I do that. By taking ownership over the part of the project that I work on, but also becoming a part of the vision, a part of the goals and a part of the success, success metrics.

Taking that off their plate and saying, Hey, this is what I’m good at. You guys do your jobs. Let me do my job and I’m gonna come through for you and I’m gonna make sure that this stuff gets done to the best of my possible ability. And as long as you work with me and you give me what I need to move the ball forward, I will get your projects done on time, on budget, and with a little pizazz so that it looks good to your boss.

But that’s so key that I’ve walked into so many projects where there’s an adversarial relationship. The client’s upset because something didn’t get done on time. The consultants pushing back because, oh, I didn’t say that, or You misunderstood me. And no. It says this in the SIW. That’s death to a project.

It’s never gonna come back from that. And you’re never gonna have success no matter how good of a solution you build. ’cause they’re never gonna perceive it as successful. Project success is entirely about customer perception. It’s not about the actual physical outcomes of what you built. And then be confident.

This is the biggest one. I have been in so many calls with people that get asked a difficult question by a client they don’t know the answer to, and they make something up on the spot. And it is so obvious to everyone on the call, and we’re all like, oh my God, this person has no clue what they’re talking about.

And now you’re never gonna trust another word that comes out of their mouth or they clam up because a client’s getting a little heated and has a strong point to make, and they react to it and they start getting upset. And then you turn into the cycle of escalation, and now people are angry at each other, and now everyone is withholding information from each other and casting blame instead of collaborating on coming up with a solution to the problem.

So the best thing you can do. Anytime you walk into a project, when the first time you ever meet a client or a stakeholder is, be confident and confidence can come in many forms. Confidence. Confidence comes in. I have been doing this for a really long time and I do know what I’m doing. I also know enough to know that there’s a lot of stuff that I don’t know what I’m doing on right.

I am confident that there are a lot of things that I don’t have the answer to right now, but you know what? I’m also confident that I’ve got a big network of really smart people, and I’ve probably got at least one or two key people that do have the answer to that, that I can get on the phone later today and come up with a solution.

And I’m confident that I can get that solution for you and get it in place in time to make your project be successful. So if you come into it knowing that I am the expert, present as the expert, but never, ever fake it, never lie, never get caught making things up, own up to everything. You’ll maintain that trust, that maintains that collaborative partnership that allows you to have customers open up to you so you can have that empathetic understanding with them from these active listening sessions.

Because now instead of fighting you, they’re there to talk to you, right? So it all comes together and it’s the core of what it’s, but if there’s one thing that will sink a project or even a call, and I’m sure everyone here has seen it before, is someone pulling something outta their ass or someone getting wound up and pushing back on the client in the wrong way.

Doesn’t mean you can’t push back, and we’ll talk about that in a little bit, but the wrong way. There’s a right way and a wrong way to do it. And the right way is confidently help ’em understand that there’s a better path and help guide them to it instead of fighting with them to make them see your side, right?

We’ve every process, so there’s a standard process that I approach to every project. This is all like straight out of PMI institute, but. I will be the first to admit that in this world, agile doesn’t fully work. There’s agile principles that I apply to everything. The Agile Creed or whatever it’s called is like 10 lines about, being agile with projects.

It’s not actually this huge project management system that everyone makes it out to be. Consulting is more of a blend of agile and Waterfall used to be a straight up waterfall, and there’s still plenty of companies out there treating it that way. But at the end of the day, you’ve got a project, you’ve got deadlines, you’ve got a budget.

You can’t just iterate indefinitely for as long as you want to get things done. You have to actually get stuff done to a certain point and, put a plan a flag. So there you can’t approach things from a purely agile standpoint. Being said, you can apply a lot of these principles. So the main things, and this is stuff that everyone’s told you.

I do this religiously and I’ve got forms and things that I’ve built out and systems in place to underpin all this stuff. But happy to share about share with you guys offline. But first is pre-discovery preparation. Like I focus on my sub-verticals within the industry because that’s my niche and I have spent tons and tons of time understanding that space.

I understand the clients, I understand the industry use cases. I understand who the competitors are. I’ve worked with many competing businesses in the same space so I can understand what they need. I try to not step outside of that too much at this point, just ’cause I honestly get enough business and it’s hard to branch out from there after so long and try to become an expert in other dis disparate sub-verticals.

But no matter what you’re working on, that’s the first step is understand the business that you’re working on, understand who’s in it, understand the landscape, understand the things that are moving, understand their use cases, understand. Why they would be talking to you in the first place and the problems they’re trying to solve.

Define clear discovery objectives. This is really important. Basically, what are we gonna do in discovery to get what I need out of you? You have to tell people, I need this information from you and I need this information from these types of people on your team. The amount of times I’ve walked into projects and there’s been a single project manager that knows how it works for everybody and they’re just gonna talk to me and tell me what, how everyone does their jobs.

And then you build it and then you bring it to all the people that do their jobs and they go, this is nothing like what I do every day. Don’t let that happen. You need to get the people who do the job to tell you how they do their your job so you can help build it for them. And part of that is making sure everybody on the team understands that no, we’re not gonna move forward until I’ve had a chance to do that.

So plan now on getting you that access and that goes with assembling the right discovery team. Analysis and synthesis. Another AI title identifying key themes and requirements. I try to break everything up and this starts at the sales phase, right? When I first have a client come to me with a problem, the first things I’m trying to look at are what are the main objectives and themes that we’re trying to nail?

Is this a sales process and sales cloud? We’re trying to build out is this a service process? Is this some kind of workflow that’s health Cloud based? Is this an app integration, a third party integration? Start putting stuff in buckets and grouping in that way so you can start building an idea of how you’re gonna phase this out and get different processes moving in conjunction.

You wanna be building that from the get go and then refining from there. But from your first call, you should be sketching this stuff out in Discovery Docs and starting that top down refinement. Prioritizing needs priority. Should be part of every single discussion you have with a client. There isn’t a single call that I have with a client where I’m not making them publicly state what their priorities are so that I can hold them to them later on when they try and tell me their priorities have changed.

Or they’re trying to add scope creep. If you tell me that this has to be done on this date and nothing else is important, and then we’re a week out from that date and all of a sudden something else is important, I’m gonna play that call back for you and make you say, okay, we’re pushing out our go live because you told me this is the plan.

And then prioritizing or performing gap analysis, understanding where you’re at, understanding where you’re trying to go. Gap analysis for me is not about some detailed software diagramming process. Gap analysis is a conversation and understanding what we’re doing now, what we’re trying to do, what isn’t working, what is working, and where we’re trying to go in the future.

And as we get into the information gathering part of this, I have stakeholder interviews with key stakeholders that are touching these different themes that we’ve outlined. So service people need to talk to me about service salespeople, about sales, yada, yada. But what I want them to do is talk to me in a Salesforce agnostic way as much as possible, people will get lost on the technical, people get lost on the terminology.

I want people to define business use cases to me in their own terms and their own terminology. Teach me your acronyms. Teach me your product naming conventions. Teach me how your business speaks about your business. ’cause a well-designed system is gonna be written in your language, not in Salesforce’s.

And the amount of times I’ve walked into projects with someone that knows a lot about Salesforce and has worked on it for years, and they’ve decided that this is gonna be a lead and this is gonna be an opportunity and we’re gonna do a case workflow here. And I look at it and I go, yeah, you could do that, but that’s not how I’d do it.

If you start off the conversation that way, again, you’re always arguing over what the plan is. So as I go into discovery, I always tell people, stop talking about Salesforce. Stop talking about technical things. Oh, you want A-D-L-R-S roll up on that object. I don’t care. What are you trying to roll up?

Tell me what it’s you’re trying to do. Let me decide whether or not we’re gonna use DLRS. I actually had a client recently that was stuck on that and I had to have a long talk with them. Hey, we build our own code at my company. We don’t necessarily need DLRS, but the idea is get away from the technical and get people to speak their truth.

Get people to speak in their language about their truth, about how their business is operating and how their day-to-day job works. And then take that and document that in their words, because you’ll have a much easier time pointing back at their words and their statements in their own language when you’re further along in the project and they’re saying no, this isn’t what I wanted.

You can, it’s a lot easier to say you said in no uncertain terms, this is exactly what you wanted, so that’s what you’ve got. Whereas if you’ve got a bunch of terminology mixed in there, it’s a lot easier for ’em to say I thought it was gonna be a lead, so why isn’t it a lead? Reverse demos.

The, I want people to show me what they’re doing, not just talk about it. The amount of times I’ve gotten on a reverse demo with a client and they’ve started walking through a process that they knew in and out and could tell me without even sh clicking a button and suddenly, oh wait, I didn’t realize this thing was here.

Oh, wait, they must have moved this. Oh, why isn’t it doing that thing? These are dynamic environments we’re working in. These are startup companies that are constantly shifting. They have admins that turn over and decide to get sneaky and make changes in production without telling anybody. All sorts of stuff is constantly in flux.

No one in their right mind should be able to say that they know exactly how everything works at any given moment. E expect there to be something that’s gonna throw you off. So go through it, look at all of it together, decide on key points and make them understand where the actual pain points are and document that.

Get their existing documentation in front of you. I ask people for every spreadsheet they use, every document they use, give it all to me. You can take the client names or important business information out of it, but I wanna see how you’re handling your data, what that structure is. ’cause honestly, that’s the lowest thing you create, right?

A spreadsheet is a great thing to use to turn into Salesforce. Easy win. Spreadsheets are always a pain in the butt for your clients. They’re always easy for me to set up in Salesforce. Everyone’s stoked when you do it. Easy wins. Low hanging fruit. That’s what we live for, right? Makes people happy. Deliver it quickly and early and cheaply and yay, Brian fixed a huge problem for us.

Look how great Brian is now. Let’s see what else he can do. That’s how you build that trust early on and get people bought in and moving forward and excited and moving towards that final goal of your go live. And then detailed user stories gets back to that stakeholder interview piece. But again, use user stories, use acceptance criteria, use test scripting to again, take a few different approaches and I’ll talk about this in a little more detail in a second, to how you make them spell out what their problems and desired solutions are so that you’re always speaking to the same points together and there’s no room for ambiguity once you get further down the road.

Is there a question? Yeah. Solution development. I’ll get into this in a little bit more detail, but once we’ve gotten everything from the clients and we feel like we’ve really exhausted every avenue to ask why about a thousand times to every single person that we can think of, then we go and start thinking about how we’re gonna apply this to Salesforce.

Now, I’ve always got some stuff in the back of my mind when I’m working on a project and I’m doing discovery, I try to do everything in my power to avoid talking about that until I’ve had a chance to sit down and go through everything and map it all together. Again, it’s about setting expectations, and as soon as you tell somebody you’re gonna do something a certain way, that’s where their brain goes.

And if you have to walk that back later, it makes you look like an idiot. Even if what you’re gonna show them is something better, still makes it sound like you’re indecisive or you don’t know what you’re talking about. Erodes that trust so better to just not do it in the first place. Get all this stuff in business terminology.

Leave Salesforce completely out of it. As much as you humanly can get that all documented, get the client to approve it, then go map Salesforce on top of it. Outline your implementation approaches. How we’re, what features are we gonna use? Is this a build versus buy situation? Do we need to get middleware in for this integration versus building a custom connector?

Do they have the right SKUs? Do they have duplicate SKUs? I do a lot of this. Hey, did you guys realize you’ve got four programs that do the exact same thing and none of them integrate with Salesforce? Maybe we should consider buying one that does and get rid of the rest of ’em and save you a whole bunch of money.

Right? There’s a lot of things like that you wanna walk through as like, how are we going to fit all of these things you want to do into your tech stack? And do we have all the right things in place to get that done? Things take time. CTI, great example, getting short codes on texting or getting phone numbers moved over.

That stuff can take a really long time. If you’ve got a deadline, you wanna be out ahead of it and confident that we’re getting it set up on the right tool and they’re not planning to change that in three weeks and we have to do it all over again. So those are things that you wanna be crafting around your solution development at the beginning, and then identifying risks and mitigation strategies.

Where are we gonna fail? First one I would name is any place that we have to involve a third party. Anytime that you need a third party to come in and work on a project with you, a vendor, third party consultant, something like that. No matter how good they are, bless their hearts, it’s an opportunity for balls to get dropped.

It’s an opportunity for things to get misunderstood. It’s an opportunity for somebody to get sick and not be able to meet the deadline, and now everything has to get pushed back. And just be aware that in those situations, as a consultant, you will be held responsible for it. No matter if it’s their fault or not, you always will.

No matter what they say, they still hold you responsible. So get out ahead of that stuff and do everything that you can to flag that upfront and keep everyone’s eyes laser focused on where that risk is so that if it starts slipping, they know exactly why and who is the cause of it, so that you’ve at least got a story to tell.

Other risks are, like I said, contracting and licensing is a big one. Oh, we haven’t even talked to Salesforce about the fact that we need to get another 150 people onboard in the next four weeks. We should probably start that conversation soon, but I’m going on vacation for two weeks. I’ll do it when I get back.

Really but we have a hard deadline on the first. These kinds of things happen all the time. People don’t talk to each other, people don’t plan internally. The amount that I see, my clients just not communicating basic stuff like that to each other. Oh, I thought you did it. Oh, I thought we did it.

Oh, I didn’t even realize the marketing team already bought Marketo. We’re in, we’re halfway through talks on getting marketing cloud. We didn’t even know we had that. Those are all things that you need to be able to work around so that they don’t blow up in your face when it’s time to pull the trigger.

And get those out in front of people and discussed as early in the project, in the sales cycle as you can. I put this stuff in my sows before we even talk about signing for a project. Essentially discovery, deliverance, there’s three key things that I have for every project. I’ve talked to Kelly at length about this and Shannon at length about this.

So they’ll know what I’m talking about. But first one is, I call it a project scope document, but it’s really your weekly status updates that go out to. Executive leadership, and I saw this accidentally, but basically the idea is all that stuff that we did, identifying risks, identifying timelines, deliverables, milestones, key stakeholders, what I need from you in order to be successful, gets put into a easy to read document.

Tells me, tells them exactly what’s gonna happen and exactly what’s not going to happen in very clear terms that is sent out to them on a consistent, regular basis. So if they ever tell me they don’t know what’s going on, they have no leg to stand on, right? The key is ownership here. Force them to take ownership.

Make them respond to you and tell you they read it. If they haven’t, tell them if you haven’t read it, then I can’t commit to any of the things I’m committing to, right? You own this as much as me, so I’m doing everything in my power to make sure that you can make me be successful. If you can’t commit to that, then I can’t commit to your project being successful, right?

It’s all about ammo. To use when people want to turn things south on you. Discovery report forget this first one. I mixed it up, but this is really two key things. It’s user stories and acceptance criteria. So I wanna start those user stories that I talked about, spelling out all the requirements in clear business language as opposed to Salesforce language that the client has agreed on and signed off on.

And then acceptance criteria. What do we have to do in order for you to say that we’ve solved your problem? I want you to tell me exactly if we do these things that you’ll say, yeah, Brian met our needs and solved our problem. ’cause we’re gonna hold you to that when we get done building. And then I didn’t throw this in here, but I’ve started in the last couple of years writing test scripts at the same time that I do my user stories and acceptance criteria.

Just putting together a basic. Click through concept. I don’t show this to the client at the get go ’cause I don’t wanna set the expectation on how it’s gonna work necessarily, but I have an idea that, oh, we’re gonna need them to, open a new opportunity and navigate to this stage and that’s gonna send an alert and then it’s gonna automatically update to this thing and do that.

And just put those steps in as you go and then constantly iterate on it as you go through your build. And that’ll get you to a point where when you’re ready to go to UAT, you’ve got a really tight set of test scripts that you can get back to your client that is thoroughly vetted by your team and you’re not scrambling at the last minute to try and figure out what you did.

Really helpful to, to do that as a process throughout. I do process maps and architecture diagrams. Key thing of process maps. I’ve seen so many consultants show me process maps that seem to be more about demonstrating their ability to use lucid charts or whatever it is, than it is about getting the point across.

Process maps are, and wire frames are a great place for people to introduce unnecessary complexity and confusion. Lots of lines going all over the place. Lots of swim lanes and handoffs and all this stuff seems really cool and tells you nothing and makes it so people’s eyes glaze over and they go yeah, it looks right.

Cool. And then they sign off on something that they’re gonna come back at the end and go, I didn’t realize that’s what you meant, right? So process mapping is where you make a picture of the business process that you talked about and they signed off on in their terms. I have customers sign off on process maps in business language, not Salesforce language.

Now, I’ll put in a little bit here. Hey, this is gonna be your lead process. This is gonna be your opportunity process. This is gonna be a case process. But I don’t really get into anything deeper than that. Just handing things off through Salesforce, they start getting an idea of. The overarching pieces of how it fits together.

And I’m not talking about work, validation rules and automations and flows and triggers and all this kind. Like they don’t need to hear any of that. They need to see a pretty picture that looks exactly like what they’re expecting. That when I walk ’em through it, they go, yeah, you got it a hundred percent.

And be able to sign off on that. Otherwise, I’m gonna be in deep trouble later on in the project ’cause they’re gonna need to make changes. Another key thing about process mapping, use it as an opportunity to have there be a start and finish to everything that you do in the project. There should be both.

A beginning data comes in, someone starts doing something, and then that data goes somewhere and there’s a terminator. Every path you take should end somewhere that’s defined and then you know what happens at that end point. I see so many projects where, yeah, we went and we sat down and we built the workflow and.

Now when we’re in UAT, people start clicking buttons and it starts firing random things off and doing random changes and sending stuff into weird places that we didn’t plan for because we didn’t have a solution at the end of that workflow, right? So try to put caps on the end of every single place that data goes.

Data goes in, data has to stop somewhere at every outcome. Otherwise, it’s a gap that you’re gonna need to cover later in the project, and it’s gonna increase your scope and make it less likely you’re gonna be on budget. And the last one’s data dictionary. I only do this sometimes now. I used to be super diligent about it, but a data dictionary is just a great place to spell out all the fields and values that we’re gonna be using, labeling, stuff like that.

You want to, like I said, put things in their own business language. So what I don’t wanna do is give somebody a big spreadsheet with every single standard and custom field we’re gonna be using in the project and make them go through it. Check boxes and stuff. What I do wanna do is say, Hey, here are the fields that we’re changing and here are the things that I heard you say should be there.

Am I using the right value here? Is this the right language that people are gonna understand or is there a better way of saying it? Should I call this field something slightly different just so it’s clearer? Is there help text, I should add in there? That’s your opportunity to get down to the granular level to make sure that they’re giving you the little pieces that make the most sense to them so you don’t have to go back over that.

It’s less important to me in the way I do things now. I work in a more iterative way, and to me, I’d rather get the big slots of functionality outta the way and then have them go in and start testing and they be like, Hey Brian, like it would be better if we called this field this, remove this field here.

We add these two pick list values. So I do it a little less on a chart these days and a little more as part of my testing process, but it’s still a good tool to have in your tool chest, especially on larger implementations. Data migrations in particular, if you’re moving over from one CRM into Salesforce, especially something like Health Cloud.

There’s so many table mappings that need to happen. There tends to be a lot of customization and a lot of switching pick lists and stuff like that. So it’s a good place to just start mapping those things out so you’ve got a table of it that everyone can agree on and refer back to. It’s great documentation for the customer at the end of the project too, so they know what this field means and does, and then your project plan. I like to start project plans during the sales cycle and then constantly iterate on them as you go. You’ll see a big part of my process is iteration. Start with a big thing, whittle it down, and keep iterating and refining as you go through the project on all these aspects.

But from the first call, you should have an idea of how are we breaking this out into phases? Who needs to be involved in this? What are the key timelines? What are the key risks? Are there any set in stone deadlines? Is there anything that’s got some wiggle room, key priorities, all that kind of stuff, and just start mapping it out into a chart view.

What you do on a spreadsheet or you do it in a project management tool. It doesn’t really matter. But I’ve, I just switched my project management tool from one tool over to Jira at the same time, was kicking off two huge projects earlier this year and I didn’t have Gantt charting set up and I was so busy I didn’t have time to get it set up.

And oh my God, it’s been an absolute nightmare. It’s felt like I’ve been flying blind the entire time ’cause I can’t just see on a page where all the key deliverables are supposed to go. And that’s been a couple of hairy projects, so get that in place as early as possible and then keep it updated.

I tell project managers on my team, I want you in there updating their aid log and updating the project plan on a daily basis. I want to know every single day. What’s changed, what’s different? What’s being impacted? Raid log. You guys haven’t seen that? Risks, assumptions, issues, dependencies. Just a good thing to have in your project plan to keep track of stuff that’s gonna be going on that you review regularly with your client to make sure you’re on the same page.

You always wanna be calling the stuff out. You always wanna be putting it in front of the client, getting them to agree with you on it. Have your AI bot running at all times to capture that stuff. Spit out transcripts and be prepared to hand that stuff back to them when they try to argue. They didn’t say that, but these are all just opportunities to get that consensus and buy-in.

I know I’m running out of time, so sorry. And that’d be a good user story. I’m gonna skip over this. Oh, I’ve been going a little bit too deep. But good user stories really just take a format of, as a user, I need to do this in order to accomplish this. The, I’ve talked about this en enough already, but.

I want the users to tell me in their language what it is they’re trying to do and why. And then I want them to get it, to get them to agree with me on paper that yes, that I’ve spelled that out, acceptance criteria, same concept. Given a specific context. When a user performs an action, then a specific outcome is expected and do that at the same time as the user stories.

’cause that acceptance criteria is gonna be them telling you, this is what I expect to be happening. Doesn’t need to be super, super specific, like field level, but it needs to be specific enough to where the process is described and we should expect to be able to meet these process requirements. All right.

Wisdom nuggets before I run out of time. Never solution on calls. Number one rule I tell everyone on my team, I tell myself this every day because I find myself doing it still after over a decade of doing this stuff. All these things. You’ve done all this before. Especially in my line of work. I work with clients that.

It’s like the same thing over and over again. Regulatory environments. So they have to do it the same way. I’m like, oh yeah, we’re gonna do this, we’re gonna do that, and we’re gonna use this thing and blah, blah, blah, blah. It’s awesome. And then I go back after the call and I start digging in. I go, oh wait, they’ve had this one thing though, and that makes it like, I can’t do that and I gotta do something else.

And now I have to go back and go, oh, actually we decided we’re gonna do this. And even if it doesn’t change the budget and scope at all, it makes me sound like I don’t know what I’m talking about. And it sets an expectation that causes confusion. And that’s the key thing. Now they’re expecting something that I have to change, and maybe somebody from the last call isn’t on this call.

When I update them on that change, and now they’re thinking it’s the old thing and everybody else is thinking it’s the new thing. Now we’ve created a rift that’s gonna be hard to walk back from. So if you just stick to never solutioning on calls as a hard and fast rule, you never have to go back and explain yourself.

It’s like never telling a lie, right? It’s way easier to keep to the truth straight. And that’s a key consulting principle too. Never lie. Never bs. You can always own what you say and go back to it and know what you said if you’re not making things up under promise, over deliver. I know this is like old adage kind of stuff, but it’s so true.

And it’s not just about over promising, under promising and over delivering. It’s, I know for sure I can have this done on Friday. I know that if something happens, I can absolutely have it done on Monday. I’m telling the client I’ll have it by Wednesday so that if a hurricane blows through, I’m still gonna be on time.

And they will say it seems like that’s a long time. Can’t you commit to getting it done sooner? No, I can’t commit. I will probably get it done sooner, but I can’t commit to getting it done sooner. I’m committing to get it done when I know 100% I’m gonna get it done and that’s the date I’m putting on the book.

And we’re agreeing to stand your ground on that because they will try and get you to commit to it sooner. And then if something happens and you can’t meet it, guess whose fault it is and guess what happens? It’s a problem that was honestly created because they made you budge off of what you knew was the correct move.

So stick to your gut. Make those calls and stand behind them firmly do not budge on them. And I say that as someone that still constantly budges on it and pays the price. It’s things and you don’t necessarily do them. Speak to your audience. This is a big one. Know who it is on your call and know what it is they’re looking for.

So if you’re thinking to executives speak, executive talk, they’re thinking big priorities. They’re thinking long-term milestones, company level goals. They’re not thinking process maps and technical jargon and integration, API mapping, yada. And if you start talking about that, their eyes glaze over and they go, ah, this guy sucks.

And they start looking at Slack or doing something else and you’ve lost them. They’re no longer a key contributor. Another one comes with anybody that’s non-technical. I generally encourage people to avoid speaking in technical jargon on calls in general, even if the customer wants to speak that way.

It just makes it so there’s always someone on the call that’s gonna feel threatened or feel like they’re not smart enough and puts someone on the defensive and now you’ve got someone that’s not contributing as well. Another thing is always be reassuring. Like you’ve got a lot of people on the team that are under a lot of pressure.

You don’t necessarily know what that is. Maybe they have to wrap this call up and take their kid to soccer practice ’cause their wife’s sick. But like a big part of speaking to your audience is to always be reassuring, Hey, whatever’s going on, whatever we’re talking about, I’ve got this, it’s gonna be okay.

We’re gonna get this taken care of. Even if it’s not perfect, it’s gonna get taken care of. And don’t feed into that. A lot of people have this innate ability to make a really relaxing situation, become stressful. Don’t buy into that. Don’t let them turn you into one of those people. Always stay cool and calm.

And speak to their problems, right? And then master the art to know this is a hard one, but everything that I’ve talked about so far leads up to this. If you do all the things that I’ve talked about, every step along the way have involve the client and all the stakeholders and what it is we’re talking about doing, what it is they define, what we’re doing as what the timelines, milestones, risks, key stakeholders, licensing, all that stuff.

We’ve talked about this ad nauseum, documented all of it on recorded calls and paperwork that they have signed off on when they come in at the 11th hour and say, oh, we forgot to include the head of hr, who now has this whole thing that ties in, that absolutely has to get done. No, sorry. If you want me to do that, explain where in our project we can move something to make room for it because we’ve planned for all of this stuff.

This is a really tight timeline and budget. There is no room. So the only option at this point is to deprioritize something else and prioritize this instead. And honestly, if it’s new and it’s late in the project, you’re gonna be deprioritizing multiple things. ’cause we’re gonna have to run an entire project cycle on this one thing now, which makes it say, we can’t focus on several things that we already did this with.

So is this really that important or can I wait a couple of weeks? You know what, most of the time they go, eh, yeah, you’re right. This can probably wait a couple weeks. Easiest way to get people to understand the word no is get them involved in the process of understanding why you’re saying no. Help ’em own it.

And you’re not saying no to them. You’re saying no to the ask. And that makes it so you’re not fighting with people. Another couple nuggets. Start with the plan. Stick to the plan from the beginning. You’re building this plan. You’re building all this documentation. There’s always these moments where you’re like, ah, let’s take a shortcut.

Oh, I could get this done real quick and we could just knock this out and I’ll just skip this part of the process or part of the planning. Every time I have done that in my entire career, I’ve come to regret it. I don’t think there’s a single time I can think of that. I did that and was like, yeah, that was the right move.

Every time I’ve done it, I’ve come to regret it. So I still do it, right? It still happens. You’re moving fast. You’re like, oh, and you know what? I always regret it. So force yourself. Make the plan. Vet the plan. Know when you know it’s a good plan. Stick to the plan and avoid taking those shortcuts and stepping outside of it.

Otherwise you’re in uncharted territory and anything can happen in uncharted territory. Start the basics and iterate back to that concept of either stories, acceptance criteria, speaking in business language. Do the absolute minimum it takes to get something built. Save room in your project. There will always be things that use up that extra space.

But what you can’t do is go back after you put too much time into something and claw hours back to make space for the things you didn’t save time for.

Start small and then build from there. Discovery starts with sales. There is no such thing as a sales delivery handoff. There should be discovery throughout the entire process.

If you’ve got a sales team that’s working in a silo and they’re handing off projects to a delivery team, your projects will always be at risk. I say that unequivocally, having been on both sides of the fence, I’ve never seen that work in a way that results in the best outcomes for projects. Get someone from the delivery team that knows what they’re doing, involved as early as possible in the sales process to help scope it and make sure that everyone’s saying the right stuff and setting the right expectations.

Otherwise, you’re setting yourself up for failure and there’s just no hope at that point. It’s how you lose money. It’s like a guaranteed way to lose money and have unhappy clients. And then like back to the, starting with the basics, deliver the SAW plus a little bonus. This is like the key to me. Get exactly what I said I was gonna do, done with a little cherry on top.

Something nice that adds some ROI and value, preferably something a little flashy that looks cool that your stakeholders can take and show their boss. Love little flashy things that are simple to implement but look cool and are like, oh wow, that’s really hip. That’s the kind of stuff that makes your key stakeholders look like rock stars in front of their boss, which makes them love you, which makes everybody on the project O’Brien’s a rock star, Shannon’s a rock star and want to keep working with you, right?

But it’s key that you stick to exactly what you said you’re gonna do so that you’ve got a little room left to add those extra things. ’cause otherwise, if you don’t start with the basics, you’re gonna go over budget and then now everyone’s unhappy and there’s no matter what you do, you’re always gonna have gone over budget.

It’s never gonna have been a truly successful project. I was gonna get into case studies. We don’t really have time. We got five minutes left, so let’s open it up for questions.

I don’t have a Yeah, go. Go for it, Andrew. Yeah, Brian, I think my biggest question is like where do you get the confidence to say no? I think that’s one of them. I’m sure a lot of that comes with being, an industry expert of course, like yourself and being around a lot of different projects.

But what helped you get to that point where you were able to say no to people? Yeah, part of it’s just the experience that when you’re getting hired as a consultant, this is a key thing. People are hiring you to be the expert. They’re not hiring you to just come in and fill a seat. They want you to come in and tell them how to get this done properly and people will fight you tooth and nail on your responses to that.

And so you have to take the stance from the beginning. I am the expert, you’re hiring me to come up with a solution. Whether or not what you’re asking for may be a way of doing it. I’m, I’ll take what you consider into I’ll take what you’re saying under consideration, right? And like it’s not always a hard no.

Like I’ll, let me see what I can do a lot of the time, but at the end of the day, I’m calling the shots on this. I’m deciding how this is gonna get done, and you have to listen to me because that’s why you’re paying me. And if you hold that line, it’s way easier to say no because it makes their job easier to go and tell whoever asked them to do this thing.

No as well, right? Most of the time the ask isn’t coming from someone directly. It’s coming from their boss or someone outside of the circle and they’re like, Brian, they want me to do this thing. I need to arm you with the ability to go and tell them. No, sorry. Thanks Brian. Yeah. Anyone else? One thing you touched upon earlier on was like agile versus waterfall and not being able to just iterate and actually needing to get things done.

I think something that we come across when we’re working with new clients is we want to do all these roadmaps or gap analysis, but we also like actually wanna show that we’ve accomplished something with the hours that they’ve used. Yeah. So how kind of balance those things, especially when you can do great discovery, but until you get in the systems, you don’t always have the clearest picture.

That’s a really great call out and it’s something that I should have included in one of my slides, but back to that concept of the continuous discovery cycle. I tell all of my team, I want something for the clients to click on by week four of any project. Doesn’t matter how big the project is by week four, they need to be in their test environment, clicking on stuff and seeing results.

It’s how you get confidence and buy-in and you can talk about Salesforce all day and everyone will have a different picture in their mind. When you have something built for them to point at, then you get clear instructions. So it’s a really good call out. I try to get discovery done in kind of ways, get enough discovery done to where I can build a first draft of something and then get it in their hands to start clicking on it and giving me feedback and then iterate from there, right?

So there is an iterative, agile process to this throughout the course of the project. It’s more that I can’t build a beta and then have a release cycle and then oh, we reprioritize stuff we have to push for the next release cycle. Doesn’t really work that way. We don’t have just like an endless number of release cycles to work on.

But yeah, build something core, get them in there using it, giving you feedback. A lot of the time when I do that, they’re like, oh, this is perfect. I had a, I had plans to build all this other stuff. And they’re like no. This is great if we just get this, like we’re good to go. And that’s huge, right?

It’s a really good call out, get people clicking bi-week four, and then try to get new functionality in their hands on at least a bi-weekly cycle throughout the course of the project. And you’ll be able to be on the same page throughout the whole thing. Thanks. Hey, Brian? I have a question, or, yeah, I get the, I think it’s a question.

I know that previously you had talked about not necessarily being Salesforce centric, that where you conduct your discovery calls being technology agnostic. Along those same lines, Salesforce has something called like order of execution, right? The way things should be done, is there a technology agnostic tool roadmap, template, framework that also.

Follows a, an order of execution, if you will, like what things should be done first. And I’m specifically asking about implementations where, you know that you are stringing together a couple of different systems, right? So maybe the center is A-A-C-R-M, there’s also an ERP that they wanna look at, or even a marketing system.

Is there a way or a framework where it makes more sense to set things up a certain way? Yeah, again, all of the data, right? If you’re mapping your processes from a functional standpoint as opposed to technology standpoint and showing where the data comes in and where the data goes out, you can see where things bolt together.

You start with a little bit of data downstream and then it rolls downhill and becomes a giant snowball, right? So if you’re aggregating data across the lifecycle of a workflow. It logically builds from start to finish, right? You plugging other tools in on top as the data flows through the system and it’s adding more things and adjusting that data further and further.

And that’s how you build it out. And so if you start from that standpoint and get that map, then it’ll be pretty clear what needs to get built in order to inform the things downstream. And then you can take a look at it and say, okay, but like we need to plug this thing in on top. It’s not really, the data doesn’t need to get run through it necessarily in order for it to do its job.

So we can probably start working on that at the same time we work on this other thing, right? So you, it makes it really easy at that point to see where you can double up and have separate work streams that you’re working on at the same time. But yeah, follow the data. I tell people I work from left to right on the page.

I want to hear from where the data goes in and just work our way until where the data goes out. And then. I’ll move stuff around on my project team, depending on what we have access to and where we can start building that. We want to think about it logically in those terms. And it helps with rollouts too.

Phasing things, okay, we’re gonna do sales. Sales is gonna hand off to delivery is gonna hand off to support. We’re gonna build those things as separate phases, get those teams live, and succession naturally moves together and the technology bolts in on top of that in a very natural way as well.

Let me ask a follow up question along that. Do you have situations where clients have come in and said, Hey, we have maybe a support problem, or we want you to maybe work on this portion of the implementation, and then when you do the process map, you’re like, okay, I can, I see, and you’ve identified that as the problem, but that’s not the underlying issue because your data flow is what’s impacting the problem.

It’s more like a center. How do you have those conversations? Or can you give me an example of that? Because I think a lot of people on this call, what we get presented with as consultants and people that are working is, here’s the problem, right? And so of course we want to, it’s not just about solving the problem, but if the problem is actually a symptom of a much bigger issue, we’re still expected to put a snapshot, do you wanna put a bandaid on a bullet wound or do we actually wanna back it all the way up and go, okay, we have a much whole, a much bigger problem.

Yeah, I’d say that used to happen more early in my career and it still happens now, but if you start discovery in the sales process and you get people that are systems thinkers in there to start doing that scoping early on, I can usually catch, maybe not what the problem is, but that there’s a deeper problem that we need to have more conversations about it before we sign the papers.

So a lot of it’s that sniff testing upfront. Don’t be in a rush to get the deal signed just because they told you this is all they need. Listen for those cues that, hey, something about this doesn’t totally add up. I’d like to look a little deeper into what’s going on. Maybe talk to a couple other people before we move forward on this just to make sure that what you’re saying is totally vetted.

That’s the best approach to it, honestly. And that’s back to that discovery starts and sales piece, right? That’s where you catch that stuff and that’s how you prevent it. If, which still happens. You get into a project and you find out, Hey, you got a whole mess going on in here that I wasn’t aware of, and now I have to do something about it.

That’s a tough question. That’s change order sound. That’s, there’s two ways we can approach this. There’s, I can solve your immediate problem and it’ll work for now, but just know that we’re gonna have to go back and fix that other problem and then probably change what I’ve done is gonna cost you more and not get you where I want to be.

Or we can just, pull the, and talk about getting it all solved right now, but then you’ll know that you’re being good going forward. I’m happy to do both. Whichever way is better for you. One’s gonna cost a lot more and take a lot more time, but I want you to be aware of your options and what the outcomes and risks are gonna be so that you can make an informed decision and can’t say that I’m not doing my due diligence.

And that’s the best way to get into those conversations. Like I’m trying to help you here. These are the options. This is the best that I can give you based on my knowledge and you. I’m giving you the tools you need to make an informed decision. You make the call and I will do everything in my power to get the best outcomes outta the decision you make.

Cool. It sounds like we need to bring Brian back for a second session. That’s what I’m hearing. Oh my gosh. Please everybody join me in thanking Brian. Oh my gosh, this was incredible. I know I myself was feverishly typing notes. We did record this. We’ll share this with everybody. And Brian, we’ll talk to you about when we can get you back for a second session because I know that there’s a lot more for us to learn from you and we appreciate so much you sharing your time, your knowledge, your expertise and experience.

I don’t think there’s a person on this call that isn’t gonna walk away with a lot of things to think about. So many thanks to you, Brian. Thanks to everybody for coming and hanging on. Please make sure you’re registered for next month where we’re gonna have Megan talk about automating patient recruitment, using Life Sciences Cloud, which is gonna be a phenomenal meeting.

Happy Friday everybody, and have a great weekend!

⬇️ Join the Salesforce and the Life Sciences Virtual Group now!⬇️