Chris Strom:
Welcome back to another episode of The RevOps Hero podcast. I'm your host, Chris Strom, and on this episode, we have my guest Erick Salvatierra, and we will be discussing the HubSpot Salesforce integration, different scenarios, standard integration versus custom integrations, how to do it, when to do it, what it looks like, and all of that. Erick got his start originally doing sales in the medical device area, and then over time, he found his way over to the technical and operational side, and realized that was the area he really loved to dig into himself. So Erick, yeah, tell us a little bit more about your background and how you got into RevOps and the technical operations side of things.
Erick Salvatierra:
Sure, yeah. Thanks, Chris, for having me. Again, my name is Erick, based out of Chicago. I got my career started in the medical device industry. Essentially, we're selling surgical equipment to doctors that was a basic instrument, so anything from laparoscopic scopes to surgical devices for kidney removals. Did that for a few years, and during that time, I noticed that we were still doing a lot of sales operations on Rolodex and business cards. About 10, 11 years ago, I got my first start in HubSpot, convinced the company to get HubSpot on as our CRM, to essentially house a lot of that data for marketing purposes, and that continued on for the first six years of my career.
And then, after graduate school, I started running into different scenarios and industries, where you needed to have a little bit more of a technical background, whether that was in fintech or for sustainability and supply chains. So I really dug in for about three years, into essentially building out custom code for backend integrations between tech stacks, and then found myself into this world of revenue operations, and have been building in the space for the last five years or so.
Chris Strom:
I know we had originally talked about HubSpot and Salesforce, some of the two most common systems out there in the revenue world, and the systems that we're running for basically all of our clients ourselves, and so I think this will be a great topic to really dig into here. First off, when you're working with a company, how do you help them think through and plan out their tech stack, and which platforms to use, and how they'll connect with each other?
Erick Salvatierra:
Yeah, so in most scenarios, you're going to be working with a company that already might have something in place, right? There's very rare scenarios where you have completely new startup and you're building from scratch. So essentially, you base it off of who are your people, who are your, essentially, operators within the spaces? That might be a marketing individual, a sales individual, and a finance individual, and you need to be able to have them talk to each other. Otherwise, you're going to be jumping between meetings to meetings, and never really accomplishing things. The main, the simple use case here is how do you transfer information from one individual in real time to the other one? And that's the base of the revenue operations when it comes to building out tech stacks for a CRM.
In those cases, it's going to be different based on the complexity of your organization. If you have a 1,000-person organization with a 50-person sales team, you're going to have a very complex system in place, when in comparison to a smaller team that has five, you might need something a little bit more basic, instead of standard build outs, and just really simplifying down what that sense of communication is between those teams.
So those are the scenarios I tend to work with, and then it really gets complex if you're building out integrations on other platforms that don't have a native build into Salesforce or HubSpot. But in these case, majority of the times, they do have some type of small native build that may transfer some very basic information, like your email, contact information. But then, as soon as you start building out custom objects, you'll need something a little bit more robust for scenarios, for like marketing data or a deal opportunity that might be a little bit more complex than a three-step process.
Chris Strom:
Yeah, it makes sense at a high level here. We'll start off with, from here, talking about what are scenarios where... So there's a built-in HubSpot natively supported HubSpot Salesforce integration-
Erick Salvatierra:
Yeah.
Chris Strom:
And then, of course, you can just build your own custom integrations as well. So when should a company just use the standard HubSpot Salesforce integration, rather than something custom built?
Erick Salvatierra:
Yeah, I would say a few scenarios you should be considering is based on how complex your data is, essentially how big of a database you currently have. I would say anything under 10,000, 20,000, the native integrations tends to be fine. Once you start reaching over the 100,000, you might need something a little bit different. Number two is based-
Chris Strom:
It's like a number of records in the system?
Erick Salvatierra:
Yes, number of records, and then properties attached to those records, or even objects associated to those records as well.
Chris Strom:
Under 100,000 total records between all the objects?
Erick Salvatierra:
Yes, I'd say under 100,000 in total records, contact records, the number of associated objects. So right out of the box, you might have a contact, a company, and a deal. In most business scenarios, you might have more, and that's where the custom integration needs to be put in place. The third one would be based on the complexity of a workflow that might be in place already. Most scenarios, most organizations have historical data in place. So really understanding what you have in place and what will happen if you bulk import or transfer data is going to be another scenario you have to consider.
And then, there's going to be a point where if you start with a standard integration, you'll start noticing some limitations with the custom field requirements. Out of the box, there are certain properties that HubSpot says you have to transfer to Salesforce and vice-versa, and you're going to come across, as soon as you start building out custom scenarios or properties, of course mapping those out is going to be one important piece. But the second consideration of it is how many associations you have across each of those objects. So just by any means, the complexity of what happens as soon as I transfer information over from one platform to another, you don't want a cascade of errors essentially happening, or people getting confused if you transfer information to them that might not be either clean or confusing if it's transferred to them.
Chris Strom:
Yeah, so those are some of the things to think about in terms of sticking with standard versus custom. When would you recommend that someone not go the custom route, and stick with the HubSpot native Salesforce integration?
Erick Salvatierra:
Based on how complex your company is, right? So if you have a small organization, perhaps under 20, I think the standard integration works well. In smaller business scenarios, so essentially you don't necessarily need to be transferring information in real time every single day, that standard integration works as well. That just gives you a little bit of room to fix things in case something goes haywire, or in scenarios where you're essentially just having to manage two different platforms between a marketing team and a sales team.
Now, with that being said, marketing and sales get very creative to accomplish what they need to. So there's a lot of those points where you're going to have to reach over a chasm, essentially saying, "Okay, we're running very interesting marketing campaigns. I would like to have that data on my card before a call on this individual." And that's the point where, essentially, you have a team deciding for you that you need to have a custom integration.
Chris Strom:
When the different teams start building out their own independent, custom processes?
Erick Salvatierra:
Correct, correct, or requesting just unique data points, right? "When was the last time this individual saw a page? When was the last trigger for this individual to request some type of information?" At this point, we live in a time in life where the attention span to information is super short, right? So sales reps are going to want to reach out to individuals who show a very small or medium-sized inkling of being interested in a product. And those are the times where you actually want to get on a phone call and have an educational conversation, or just a probing conversation with a potential customer, because if you don't get in front of them, there's likely a customer... Or excuse me, a competitor that's likely going to be doing that instead.
Chris Strom:
So let's go into some of the specific custom integration scenarios we talked about leading up to our recording here.
Erick Salvatierra:
Yeah.
Chris Strom:
Could you talk about a couple of some of the specifics you recommend custom integrations for?
Erick Salvatierra:
Absolutely. So the first one I can pull out here is going to be a detailed opportunity tracking across these platforms. Like I mentioned, it depends on your sales process and the industry that you're in, but you're likely going to have a need for custom integration, based off of unique sales stages that are not supported on a standard connection.
Most standard connections are just going to be prospecting, first call, demo, negotiation, and close. If you have a little bit more of a complex organization, where you have perhaps an SDR talking to an individual and then passing it to an AE who's going to close it, you're absolutely going to need a custom integration, because there is a multi-step approval process of essentially qualifying a lead and then closing a prospect.
Chris Strom:
So that's one scenario. Are there any other scenarios we should talk about for custom integrations?
Erick Salvatierra:
Absolutely, yeah. I can run down the list here. The second one is going to be marketing. We have so much data now that we are working with, and marketing teams tend to need that information to essentially provide great campaigns and informative content, right? You're going to need custom mapping for marketing touch points. So at one point, you want this individual to land on a website, right, or a landing page. At what point should a sales rep get involved in that entire journey? Essentially, it's going to be a point where you want to build a custom integration.
Advanced revenue contributions, most companies are very complex now, and we essentially want to know an ROI on what we're investing into. So you're going to absolutely need, if you're connecting Google Analytics, to your SEO, to a [inaudible 00:10:55], like a tracking a platform, you're going to want a custom field creation across each of those. Essentially say, "How are individuals tracking across our journey, and at what point can we essentially process this information over to that deal?" So those are the first two that tend to come up with revenue operations.
The other custom integrations tend to be industry specific. So if you work in health tech, FinTech, anything that's very specific where you are processing either private information or sensitive information, you're going to want a compliance data handling tool that is not out-of-the-box native for HubSpot or Salesforce. And now, I know HubSpot has had a recent feature where they are HIPAA compliant, but that's just one scenario where you are handling complex regulatory data in one platform. But if you're processing that over to Salesforce, you're likely not going to be working with just the standard out-of-the-box integration.
The next one would be real-time data sync. This is a scenario where you're processing a bulk set of data across a platform. There's a limitation window that essentially blocks out or essentially cuts out the API. It depends on their specific scenarios. I remember the last organization I worked at, it allowed about five contacts to sync over within a 10-second period, and that had to do specifically with how many workflows we already had functioning in Salesforce. So really understanding immediate data updates across platforms, and what that potential SIL is between teams is a consideration to really understand how quickly does someone need this information and can I process that information within that allotted amount of time?
Chris Strom:
Yep, you just need faster refresh frequencies than the standard integration allows?
Erick Salvatierra:
Correct. Yeah. I think, let's see here, the last organization I worked for, even this one, we had 20 to 30 properties, which seems like a lot in these scenarios, but when you're handling a set of data for one contact object, that might not be able to process a bulk, if you're essentially trying to process over 1,000 after a conference that may have occurred, and you collected 1,000 leads, and you want those leads in the sales rep's hands on Monday morning, and you receive the leads at 6:00 PM on a Sunday.
Really being able to make sure that everyone has the correct information, you're collecting data correctly is the first piece of it, but then also making sure that you can either do that in stages, where you're essentially able to process information of the most priority first, and then trickle down to those that might not be the most important. But essentially, you have an organization where you've built out a house of cards of properties, really understanding which ones are the most important, which ones are your minimal data requirements, starting there, and then build out your integration stack from there.
Chris Strom:
Yeah, that makes a lot of sense, in different types of scenarios like that, where it would require something where you can get much more hands-on in the specifics of the data moving back and forth.
Erick Salvatierra:
Absolutely, happy to go into more scenarios. Those tend to be event triggers, where you need to really understand what you're processing along. After trade shows, if somebody comes into your website and essentially requests information, getting a hand or somebody calling on somebody as quick as possible is important.
And that's the main reason why so many different organizations exist out there, like a Chili Piper or a Calendly, where you're going to want other tools in place that aren't features in these platforms, like HubSpot and Salesforce. Maybe eventually, as they continue acquiring other organizations. But for now, they stand as either data repositories, a source of truth, and you're going to want to build out other tools to essentially speed up your sales or marketing process, or even just your revenue process, if you're building out the full pipeline across all platforms.
Chris Strom:
All right, so those are some scenarios where you would want to build in a custom integration. And so now, I'd like to hear your thoughts on if someone decides they want to do a custom integration, how should they do it?
Erick Salvatierra:
Custom integrations are going to be based on a few scenarios. So every time I go into a new organization or a new project, simply assessing what the business requirements are, right? You might be in a scenario where the request is, "Hey, somebody told me I needed to have a custom integration." And the reality is, "You just need to simplify down your processes." So if you know you're going to have a complex business requirement where you're handing information off to a number of individuals, or you have a set of data that is larger than five minimal data requirement points, really understanding, A, the current status of your database, B, the current status of the workflows for the data, and then C, really defining the objectives of what we're trying to do, right?
In those scenarios, you essentially want to understand what the goal is before plugging in anything. Beyond that is do you need to have an authentication process in place? I currently work in an organization called [inaudible 00:16:13], where we're authenticating members into our organization, and then past scenario is if you're working with a community, you might need to have a guard door, essentially, before allowing someone into your community or access to your resources. So essentially, again, really understanding your objectives of the organization is going to be one piece. And then, the second piece is making sure that we're getting people to the right locations, or at the very least, having internal people talking to the right individuals at the right time.
And number three, as you're assessing all of this, really consider what your data mapping is going to be, and create comprehensive documentation. And when I say documentation, I've always gone through Google Doc, essentially, but here is [inaudible 00:16:56] documentation is what matches up. But get visual. A lot of people learn in comprehend things in different ways, so you can use a process like a Jamboard or a mirrorboard, or essentially just write it out on a whiteboard, to really get some input of essentially saying, "This is what you're doing right now. Do you need that information in the future state, where we're using this new platform or we're using a Salesforce, where we're processing information from one individual to another"? And that's going to really allow you to get ahead from any error handling scenarios where you're going to come across, or handle any other type of confusion points that teams might...
And number four is going to be a synchronization strategy. Like we mentioned before, the standard integration is a bi-directional sync, but sometimes you don't want information coming back into your starting point. And those are scenarios where marketing has a set of data that they want to process over to Salesforce, but potentially, you might have a rogue rep that changes data, because you left the field open as single line, and they change it, and the information process over to HubSpot, and it's incorrect. Really understanding ahead of time, "Do I want this information that somebody else tells me I need to have or not?" And really creating essentially a lane for each individual to essentially say, "This is the information I'm providing to you. Do what you want with the information," but at the end of the day, really understanding who needs information, what kind of information, number one, and then really simplifying that down to their view, so that they're not getting bogged down with information.
And then, lastly, you had mentioned error handling before, but really creating a robust mechanism to essentially say, "If I let this go in real time and not review it, what point do I need to come back and audit information?" And that might be at points where your sync breaks down and essentially says, "Process too much information," or you're missing data points that are required, those tend to be scenarios for error handling. But I like to have a weekly or a monthly audit that essentially goes through and says, "Okay, this is the starting point that we were assuming. Did all those data points make it to our end point, yes or no?"
And that creates more trust across your organization. Otherwise, you're starting to build into a scenario where you can process information in, and the information handled or received might not be fully correct, and that breaks down the trust of your function as a revenue operations professional in the organization. So those are the five, assess, really understanding who your individuals are, who's handling and looking at that data, mapping out that data, having a synchronization strategy, and really understanding if something breaks down, how can we move quickly to fix it?
Chris Strom:
And then I'd like to take a couple of minutes to talk about the technical nuts and bolts of setting up an integration as well. I know a lot of times, people talk about using a third-party integration platform as a service to do an integration. Sometimes, people just want to do a pure, custom-coded mini app themselves that they build to connect to the APIs of both systems. Can you talk through briefly, what are some of the options for an integration platform as a service? And then, if you want to go the totally custom-coded route, what you would do for doing that?
Erick Salvatierra:
Yeah, integration middlewares tend be stuff like Zapier, MuleSoft. We are currently using something called Make.com that essentially is a beautifully UX designed platform that works as a middleware. Those scenarios I recommend when you have teams that are not as technically or developer friendly. That's not a bad thing, right? You have very basic code that you can work off of. If you know your way ins and out of your documentation, use that route, because that's going to be your fastest route to build out your integration. And then, you can create documentation or videos to essentially teach team members to own that piece of data. And that essentially says, "We have a goal to reach, full integration in three months. That's going to be the fastest way to get there."
And the most robust, right? Most revenue operations teams might have a little bit of a technical background, but I would assume that most teams, you might have a very technical individual that's really bogged down in certain projects, where if you need an integration today or yesterday, use the middleware platforms. They're going to get you there quickly. And a lot of their support from those organizations are very good, in my opinion. You brought up the custom code. I think those are going to be based off of your technical advantages. So if you need more precise data control, enhanced security, a way to essentially optimize your performance, or even adhere to compliance roles like in your industry scenarios, those are the scenarios where you're going to really have to get super customized.
And in the past, I've taught myself Python and some JavaScript, and work out of building out APIs over the last six years. And you can either build those out through an additional feature that HubSpot has, Operations Hub. It's been a fairly good one to build out of, or you can use another middleware platform like a GitHub or a Postman, where you're essentially building out a brand-new API framework, and that gives you a little bit more flexibility as well.
I haven't dealt with those in as many scenarios, because we tend to have a technical team that supports me as well. I'll build out the framework to what I need right now, and then I hand it over to them to essentially fill the gaps for those technical requirements, whether that's data control or security. But what I'd recommend, if you're in the field of revenue operations, is just know enough to be dangerous within some documentation, so that you can change things without having to go through another team to get something approved. And those are the barriers to essentially reduce any type of complexity or challenge in building out integration between Salesforce, or even any type of integration platform to manage your tech stack.
Chris Strom:
As we've been talking through this, some people might say, "Yeah, wow, this is a lot of complex stuff we're talking about here. Sounds like it sometimes could be a lot of work to do. Do we really need to do it?" So why would you say that systems integration is important in general?
Erick Salvatierra:
I would say it's important based off of the scenario of your organization. Every scenario, every organization is different from each other. Every organization's going to want to scale or ramp up speed, to essentially close out deals. So it's really going to depend on the goal of how quickly you want your organization to run, in how complex of an organization you're building out. So getting back to it, really, how strategic and how quickly do you want your organization to run? And coming in as a resource, as a tool I think in revenue operations gives you a little bit of a hands up in a leadership role, of essentially saying, "Look, this is how we're doing our processes. It can be done better, it can be done faster, it can be done more precise than what we're doing today."
And if you're already at that point where you're an organization that's very complex, and you're seeing that those are tension points, those tend to be scenarios where those custom integrations come super handy. You don't want marketing or sales teams pointing at each other and saying, "This data information is wrong, I don't know what I'm doing," which is commonly what happens in sales teams. Being a champion of data and providing information or resources for those or other teams, so that they can be champions of their own data as well, is a true path for leadership within revenue operations.
Chris Strom:
All right, so that gives people some good things to think about when they're thinking about, "Is this a good use of our time and budget to implement some of this stuff?"
Erick Salvatierra:
Absolutely, yeah. And revenue operations teams, I think they tend to get pigeonholed into spaces of task takers or monkey task makers, but they're true leaders of the organizations, because they're handling everyone's information. They have the keys to the kingdom, as they say. Come into an organization, be able to set your boundary, and then just coordinate and communicate, or collaborate with the other team members. Make sure that you understand what their pain points are first, before you build out, and then give them a pathway to be quicker, faster, and better at their job. Ultimately, why I think revenue operations are necessary across most organizations, big or small.
Chris Strom:
Yeah, I agree. Well, cool. This has been really great, talking through all this with you here, Erick. I really appreciate you taking the time to come on here and share your learnings from your experiences, and all the projects you've done over the years yourself.
Erick Salvatierra:
Thank you, Chris. I appreciate it. I know we've gone back and forth for some time. I appreciate the invitation and opportunity to come speak, and if you're ever interested in reaching out, I'm on most social platforms, LinkedIn, Instagram, so I'd be happy to share out those handles to you, so you can share out to the community as well.
Chris Strom:
Yeah, absolutely. Cool. Thanks, Erick.
Erick Salvatierra:
Thank you.
