Ready to Scale? Building your Integration (Automation) Roadmap – Register2020-10-13T17:05:54+00:00

Ready to Scale? Building your Integration (Automation) Roadmap

Register Now

Mark Simon Mark Simon VP of Strategy
Matt Graney Matt Graney VP of Product

Whether you are just getting your A round or preparing for an IPO, scalability is critical. Automation is key for companies to scale effectively, and integration is a critical component of any automation strategy. But with the many business processes every organization needs -- quote-to-cash, procure-to-pay, hire-to-retire, marketing automation, reporting and analytics, and so much more -- it can be challenging to prioritize and build an effective plan to automate different parts of the business.

In this session, integration experts Matt Graney, VP of Product and Mark Simon VP of Strategy at Celigo, will share their expertise and insight to provide a practical guide for creating an integration roadmap to support high growth without requiring a significant IT investment.

Topics include:

  • Integration 101: Three integrations to build first no matter what
  • Our roadmap for automating quote to cash that helped us get to $25m
  • Why an agile approach to automation is important
  • How to start building your own integration roadmap

Watch Now!

Full Webinar Transcript
Welcome everyone. You’re welcome to turn on your video cameras if you like so we know we’ve got a live audience, but up to you. So my name is Matt Graney. I lead product management at Celigo. And I’m joined by Mark Simon. Welcome. I’m Mark Simon. And I’ve been a VP of Strategy and Operations at Celigo for the last two years, and in particular, regarding integration automation. I’ve been in the mid-market ERP consulting space and focused on automation and integration for the last 12 years before that. So, as a business are you ready to scale? That’s a question that gets asked very often from very early when it’s just a cluster of a few people together, feverishly building out a business, throughout the entire lifespan of a business. But especially a technology-focused business, we’d see this question, we ask this ourselves all the time. Are we ready to scale to the next level, to the next step? So we’re going to talk a little bit today about building an integration and an automation road map for your business. And look at what we did here at Celigo to get ourselves to our first 25 million in revenue, along the way. And then give you some tips and some pointers on how to go embark on that journey, and or, continue it yourself. So when it comes to automation, things really come down to business processes. That’s really what this focus is when we talk about automation. Finding a way to reduce the manual effort within business processes within a software technology company. And when we look at the landscape of those business processes, they’re highly dependent on where you are in your growth as a company. So, early-stage, you’re going to be focused in some areas, and some other business processes simply aren’t going to be on the radar, from an automation standpoint, until later on in the life cycle. And that’s natural. And things are going to– you’re going to have new fires that emerge in some areas and in others. But if you approach this with some thought and do as much as possible to plan ahead where you can, it can greatly help ease some of the pain along the way. One of the things with the business processes that we really see is, that when you start to examine those, to automate those, it becomes very clear that you’re going to have a focus on– you end up focusing on business systems. A modern company, especially a technology company these days, really powered by SaaS applications. And the proliferation of those over the last few years has been incredible. It’s amazing. There’s literally a best-of-breed application out there for almost everything you could think of in a business. And it’s growing by leaps and bounds. And that’s amazing as a growing business. It addresses some of the frontline needs around automation right away. But that also starts to present a set of its own problems. And we saw the same thing at Celigo in our growth, we saw the very same thing. So as you’re utilizing more and more SaaS apps to solve your business problems, you start to see some natural clustering, and that clustering occurs around your foundational applications, your CRM, your ERP. As you expand in scale, you start to see HCM coming into play, your collaboration issue resolution. You start to see this clustering, but business processes in your business don’t generally stay within those nice, neat boundaries. They span across those. And that leads to siloed processes, and it can lead to a very disjointed set of activities where you’ve got great automation in one place, great efficiency, and then you get gaps. And so then that naturally leads us to look at integration as a solution. And that’s what we see both in our organization and with our customers is that integration is key to solving quite a few of these automation issues, and it’s really at the heart of automation in a modern company. So the key to resolving those gaps and the goal that everyone should be headed towards becoming is this connected enterprise. And so with those business processes spanning across the apps, again, connecting those. And key to that automation is integrating and bridging the gap between those. So how do you get there? Let’s look at the options that are in place, that are available. And the first one that often comes up is some basic API-based custom coding. We still see this quite a bit, and that’s simply developing, wiring things together, literally coding by hand, connecting the systems where needed, and this has some benefits, but also has some big cons. This is probably what we consider the most legacy of the options, and it doesn’t scale very well. The next one that we see is point-to-point integrations or consultingware. These are often very, very quick to deploy, in some cases, but they can be a black box, and they don’t customize, and they don’t grow with your business very well. The next one that we see is vendor-built integrations. So these are packaged within some of the applications and particularly ones in a given– that are very tightly coupled to an ecosystem. We see this a lot, for example, in the CRM space where a lot of the apps, by default, have some connection to Salesforce, for example. While that can address a lot of needs along the way, it starts to run into problems as well at scale. And depending on your business, if your processes don’t quite fit into the standard that those apps expect, you can have problems. And that leads us to our last option, which is looking at iPaaS, or using an integration platform as a service to address those integration needs. iPaaS. So just that, a platform to build your integrations on. And this gives you– if you take this approach, this is really the modern best practice. And this does a lot to increasing the efficiency of your organization. And whereas, several years ago, we would only see that approach taken in larger organizations. It’s moving downstream as iPaaS solutions have become much less expensive and easier and easier to use and then if you pick the right one, able to be used by not only technical users but also by non technical users in your organization you can get tremendous automation benefits. It can really lead to a democratization of the automation effort. So it’s not just siloed in one spot and on one team. So you get faster build. It also addresses data governance and compliance, and this is something we are seeing rapidly changing in the technology space right now. The needs around that are evolving so quickly and the requirements to understand where your data is particular as it pertains to your customers, where it is, where it’s moving, what exactly is there is critical to meet the growing compliance needs out there. And then on top of that, by using a platform, you’re not reinventing the wheel, you get the gains of using some commonality and platform, and we’re pretty lucky it’s [inaudible] we’re in this in this business. So we are providing these services for our customers but a key part of our growth was being able to leverage this approach and use an iPaaS as we grew the company. So let’s take a little bit of time to talk about some of these automations that helped to get us to our first 25 million. And we’ll kind of go through and look at– do a kind of a high-level pass on some of the things, then we’ll dig in a bit deeper as we go through. So here’s kind of a summary view of our [inaudible] app landscape. And I think it’s something like this would look very familiar to a lot of you if you were to– if you’ve done this exercise before or whiteboarded the applications that you have in play. And this like I said, is simply a summary. We have over a 100 SaaS apps that we use in our business and that are critical to our operations. So again, this is just a summary. But even as an integration company, an iPaaS company, you’ll notice here some of these orange ends, we’re still leveraging native integrations in several several locations because like any company, you have to be efficient with your resources and sometimes the native integration is the best first step when you start using an application. So as you look at this you can have a lot of applications out there and one of the biggest things to do is take a look at that and make sure you have an inventory of those. And once you start looking at your data hubs, your SaaS applications, it really becomes clear that you have this clustering around them. Your data is focusing in those areas. So just like we mentioned CRM earlier, that happens across the board and each of these areas tends to have this foundational app that it becomes a hub. So for us as an organization, we see ERP at the center of that. That’s the nexus for us as a B2B software company and that’s typically what we see most often in the space but that can differ as well depending on your evolution within your business systems operation. So going through what did we do? How did we address this as we grew as a company? So at a high level, step number one for us was to integrate are our closed opportunities into our billing system in ERP. That’s typically the first step that you want to take. You need to get that cash in the door. Second step for us was automating billing. Again trying to maximize efficiency and some of these things, the urgency and timeline will definitely change due to the details of your business. But this was an important one for us. Then we automated cash collections and then we integrated payments and payouts reconciliation so. And the last one is financials with CRM to create sales intelligence. So let’s get into the specifics of these a little bit more and look at three areas which for us were absolutely critical on our path. So that first step is in automating quote to cash in price. These were the very first integrations that Celigo built as a software company. And this started by getting our data from our CRM into our billing and accounting ERP system. And this is an example of an area where you can start small and then you keep revisiting the integration and that expands and expands over time. We have dozens of integrations bidirectionally flowing between our CRM and our ERP at this point. But as a growing company early on, you get a tremendous amount of benefit just from starting and getting the first couple in place. Getting your accounts and customers synced, getting the closed deals across. Automating that leads to a great deal of efficiency and streamlining the process early on and gives you a much better visibility of where you’re out as an organization. And then the second step that we did here as well at the same time was we then integrated from our ERP which was also our subscription billing solution out to our product for licensing and entitlements. And so getting that fulfillment integration in place again was a key step to reduce manual effort early on. And there’s been a lot of evolution along the way but that was a key integration that helped us keep our operational staff lean in our growth. So after you’ve got the order to cash flowing and you’ve got some integration there what came up for us was getting more visibility into the customer and that’s going after the Customer 360 goal that we often see. And so this is an interesting one for us because this has been– we were able to build out these integrations with a bit more of a distributed model. And so our customer success team actually currently owns quite a bit of this, and they’re able to own and manage their own integrations. And this is where we’re looking at getting consolidation in a single location. And that could be in your ERP. That could be in your CRM. Could be in both and keeping that in sync. But getting product usage visibility, for us, that was a key step for enabling better expansion as well as better churn prevention, was getting some of that data in there in a location that was easy for either account managers or customer success managers to view and access along with getting the subscription data. So it’s clear to anyone interfacing with the customer, what is the customer entitled to, when is their renewal, what’s their annual contract value. And then along with that, getting an integration into your ticketing system, your support ticketing platform, in our case, Zendesk, to get visibility into tickets where it’s needed. Once you start to get some of this data, that really opens up a lot of potential for automation. So once you get an initial pass on some customer 360 visibility, that allows you to leverage the flexibility of your platforms to do things like automate the calculation of health scores and how to help have a calculated health score that pulls from, for example, all of the things we mentioned as well as survey data, for example. And then along with that, this really opens up a lot from the sales and intelligence standpoint. Now you can look and see where growth opportunities with your customers are. And that really helps you scale with that. And once that data is in one place, a little bit of automation goes a long way. We saw that for us, it being very important. So the next step for us then was to automate our cash management. So this area was owned and implemented by Finance. Some of the key integrations to start automating cash management are looking at your billing, at your payment expenses. For us, we had our billing solution embedded in our ERP, but it’s very common now that that is not the case or it will change during a lifespan of a company and during growth. And that becomes a critical integration. We weren’t as focused on that one but we were– in order to look at optimizing some of our finance metrics like reducing DSL, we added a customer payment platforms and then integrated those in leverage– and that was a hybrid leveraging built-in integration that they offer as well as customer integration to address some of the needs. In the same way as we’re growing, we had pains around expense management and choosing a dedicated best of breed expense management solution. Integrating that and utilizing that really helped reduce the burden on the finance team and other employees as well. And you get that automation in place, and this was very much an area, those in iterated process, for us as an organization. So different pieces were tackled at different times over the span of several years. But identifying where the next most important thing is, addressing that, as you grow, you start to see new problems refining, expanding. And we were able to definitely grow and keep our finance team at an optimized size and grow quickly without having to expand– [silence] Hey everybody. I think we– I think we lost you there briefly. Well, I’m going to have to make a joke about that, Matt, because I was presenting because I was the one with the stable internet. [laughter] Yeah, exactly. Yeah. So are you still sharing, no? Yeah, let me reshare. Thanks for bearing with us everybody. We figured we were– well, we were going to hope we didn’t have one of those Zoom bleeps but well, [crosstalk]. They’ll take that out and post as they say. I’m sure the recording will be pristine. All right. So I think that’s right on cue for a transition to me actually. So as Mike said, we evolve these, right? So as SaaS business people, we’re all now familiar with Agile and might have started in engineering and [product?], but it applies everywhere. So the whole point of Agile of course is to take working slices of something whether it’s shipping a working product and adding to it or in our case, effectively deploying a working business process in its infancy. But at least it works end to end and then over time, we refined it. So you already saw this slide. And for us at Sligo, the customer 360 was pretty basic to begin with. For Sligo, we use NetSuite originally as the customer success hub. So for example, we wanted those, say, account managers or growth account execs and CSMs to have access to the open tickets for the customers that they were trying to renew, pretty basic stuff. We also wanted them to have product usage information in our case coming from Splunk. Also captured in NetSuite so that they were able to get an idea of what was going on. So that served us well. I joined SLIGO three and a half years ago and that’s where we were. And over time, though, it’s evolved, again, with this agile thing in mind. And so if we build the slide, you’ll see how it’s changed. There are a lot more boxes in there. So now we’ve essentially introduced a new hub for customer success that’s Gainsight CS. We’re using something like FinancialForce to handle some of the professional services automation. We use Gainsight PX inside the product to collect telemetry and NPS data, Net Promoter’s core information. And some of those original apps like Zendesk, Splunk, Salesforce and NetSuite is still there, but we’ve expanded and refined. So, again, with this agile approach, none of this was added in one step. It was layer upon layer upon layer. But it meant that incrementally we’re able to get a better understanding, a finer grain understanding and therefore, a finer grain control of where we were with customers and transition from being purely reactive to being much more proactive in our engagement and ultimately, help us influence churn. That’s ultimately what this is about. It’s not for its own sake. We’re not making this stuff more complex just because we can. So there’s one example. And the other one on our next slide here is about data warehousing. So today we dump everything into a big Postgres database in AWS and it’s taking customer data like entitlement information out of NetSuite, usage data from Splunk. from Mongo, which is the database within our product. We also have a time-series database called InfluxDB. And it’s all in Postgres. And from there, it becomes sort of a system, a record that can be used to derive customer health information. Because there are a lot of different constituents. Again, if you’re a growth account exec you want to know, effectively, usage versus entitlement utilization. If a customer has bought X, what fraction of X are they already using, again, to identify upsell opportunities? And potentially, if you automate that, you can anticipate when a growth AE or a CSM can reach out to see about upgrading. So that’s where we are and it’s serving us well, but we can already see what the next step should be, will or may well be. And that is to go to a more dedicated solution. I mean, Postgres has served us well to this point, but there’s additional information that we might want to introduce to better triangulate where we are with customers. So, again, much as we’ve said before, maybe it’s opportunity data coming from Salesforce. Maybe it’s website data so we can get a better understanding of the entire customer journey even before they become customers. So, again, with this agile approach to integration, we are automating our insights layer upon layer and ensuring at each step that we have a fully working solution. Okay. So how do you go about doing this yourself? How do you build your own integration roadmap in order to start automating key parts of your business? Well, the first thing to think about is where you fit in in terms of integration maturity. Many of you have seen these types of maturity models across various things. I think they all stemmed originally from CMM. The capability maturity model. And here we’ve identified one where the it’s focused purely on a maturity. And organizations will evolve as they go. There’s no shame in being in any one of these steps, right? And you’ve got to begin somewhere. But the thing that changes over time is the number of cloud apps. If you’re just dealing with a handful of functional apps, as Mark mentioned at the beginning, we began really with [inaudible] as the center of the business along with Salesforce– as my gardener fires up the lawnmower, you can hear that. And then as we’ve gone, we introduced an HCM, and then tens of apps. So I’ve been in Silicon Valley for 20 years, and Sligo is the first pure SAS company I’ve worked for. Meaning not only do we sell SAS, but the entire business is SAS. I don’t think there is a desktop computer in the entire company which turned out to be quite convenient when the pandemic hit because it was just about everyone taking their machines home, and business continuity was actually built-in. I wouldn’t say it was by design, but part of that means we have this attitude to SAS where there’s a new app born every day or deployed every day within the company. So for us, we are well to the ride in this. We’re forced to be, in fact, because if you’re running tons of apps, and you need them integrated in order to automate the business process, you’re going to need to be somewhere moving along the integration maturity model. And so early-stage companies, of course, you’re just getting started, you would just do whatever you can to get it done. You’d be fairly ad hoc, and you would gradually move to the right as you go. So part of moving and getting started with the integration is to just leverage what’s already out there. So on our next slide, you can see the power, but also the limitations of out of the box or vendor built integrations. So vendor built integration, as Mike said, right? If you’re an app in the Salesforce ecosystem, and you’re just getting started. Of course, Salesforce isn’t going to bother integrating to you. It’s gonna be up to you to integrate to Salesforce. And that’s normal. So the key here is that any small app that you deploy is probably going to claim that they can integrate with one of these key hubs of the foundational apps and will often be a good place to start, but just be cautious because sometimes, they just check the box. If your use case matched perfectly with the way they see the world, it will work and probably work just fine, but it can often be a bit inflexible. So it was already on one of the slides. We still today use the Zendesk to Jira integration. Zendesk is the system of record for customer support. Jira drives our entire engineering team. It’s a great two-way integration. Support reps can raise a ticket directly from Zendesk. Engineers in Jira can send back comments so that support can then inform customers. And it works perfectly for us, allows us to handle custom fields and all that kind of stuff. So there’s no need for us to change it even though as an integration company ourselves, we could. So use what you can out of the box, but just be aware and know that your business process is going to evolve. As you saw in these previous slides about the agility needed, we’re essentially decomposing the business processes when we add more apps. And more than likely as you add, it’s no longer going to be point to point. It’s going to be a lot more complex, and out-of-the-box integrations might not be able to keep up. So that’s one thing, but then as SAS people, we’re working with teams of engineers. On our next slide, you’ll see you need to be where the lure of do it yourself. No doubt you’ll have engineers who’ll say, “Hey. Hey. This is just software. I’ve got an API here, an API there; we can take care of it. And no doubt they can. Well, they can for version 1.0, but what happens later? And integration is not trivial. You’re dealing with two completely independent systems you have no control over. You might have a system where you can pull data out of it faster than you can push it into the destination, so you’ve got to think about how you queue data, what happens if one of the systems is down or there’s some sort of error, how do you recover from that. Ultimately, you’ll find that this is not your core competency and there’s a high opportunity cost on the engineering resources that would [build?] that for you. So you have to just be aware of that. Again, in the early stages when things are a bit more ad hoc, you do what you have to do and you wire things together as you can, but as your business needs evolve, as the applications you’re using changes, their APIs change, you’ll find that this quickly becomes unmaintainable. So with those things in mind, you need to do for yourself what we did at Celigo. Again, this is repeated, but determine what your data hubs are, and the way to think of a data hub is, for a given person in the company, what is their system of record? What is the system that they go to, their dashboard, their cockpit for their daily job? For an account exec, it’s probably going to be the CRM; for someone in finance, of course, it’s going to be the ERP. But certainly at times at Celigo, where that go-to-cockpit is for a given role has changed as the tools have changed. So for example, our customer success team used to live entirely in NetSuite because that’s where we’d put all the information for them, but with the addition of Gainsight CS, they’ve moved. So you need to understand the lay of the land, essentially, your application landscape, and know which are the hubs and which are the spokes. You then need to think a little bit about the way in which you’re going to manage these integrations, and we can see here there are a few different criteria and themes here. So when we talk about managing integrations in a centralized or decentralized way– I think it should be fairly obvious, but centralized means, okay, you may be a more mature company, you’ve got your own IT team or maybe it’s done by engineering, but it’s all concentrated in one area. If it’s decentralized, then, well, maybe in the beginning, it’s a little bit like the Wild West where everyone is figuring out on their own. And on the right, we see maybe the model that we see evolving a lot more, which is distributed development, meaning that individual teams are empowered to build their own integrations, but it’s done in a common way with some sort of centralized management. So in an earlier slide where we showed, for example, the addition of a tool like FinancialForce for professional services automation integrated to our Gainsight CS, there’s an example where it’s done in the iPaaS, the integration platform, and yet the implementation was done by someone in customer success. So it’s a perfect example of where the development was distributed, but it’s all centrally managed. And then if you look down these rows, you need to think across various criteria. Is it about best practices for repeatability, making sure that there’s reuse across integrations, thinking about the total cost of ownership? TCO is really important when you think about integrations because you might build it once, but it’s got to last forever. It’s got to deal with changing requirements, changing data, actually, which is often the case. All too often, we see cases where, say, the owner of the CRM will mark a field now as being for example. And if no one else knows about it, then suddenly all the records that integrations are trying to create in the CRM are going to start failing because they’re missing some critical field. There’s also an aspect of allowing business teams to control their own destiny, so to not be entirely dependent on centralized development. And then about scalability, if you have a platform in place, it can really help to ensure the scalability of integration by decentralizing the development, essentially, and enabling you to move forward without needing very technical specialist integrators to come in and do the work for you. So there are a few different methods. But ultimately, it comes down to being organized and prioritizing. So on our last slide here – next slide; sorry, mate – yeah, is to think, just as we said, about being agile. Don’t try to do it all at once. Think about, when you look at your business and at your various points of friction, as you move across these different data hubs, the business processes flowing through them. Think about what are those agile slices that you can put down in place to make sure you at least get the basics going and then how you might refine them over time. And the way you should think about that is what the impact is of automating a certain step. Who is it going to benefit? What additional insights are you going to get? How is it going to, for example, allow the company to close the books faster or to improve the efficiency of an account exec or to allow a customer success rep to better anticipate when a customer might churn because suddenly they have all the health information they need so they can be more proactive? Think about the cost, about the cost of doing nothing as well as the cost of building the integration, and of course, complexity. Ultimately, though, it comes down to prioritization and thinking through it in this way. And I think what we’d done earlier in this presentation here is to give you a bit of a roadmap by sharing what Selego did itself in order to get to our first 25 million in revenue. And hopefully, there’s some lessons for you here as well. So I’ve got a gardener right out the door here, so apologies for any background noise, if you can hear that. Hopefully, the AirPods are taking care of that. But I think that was the end of the prepared material. And we can certainly open up for any questions that the audience might have for us. I think you can take yourselves off mute if you like. Hey Matt, before anybody jumps in with questions, I got an interesting anecdote from my experience in SaaS ERP that I draw as a parallel to that sometimes. And I remember, gosh, back 15 years ago and working with customers and trying to sell them on SaaS ERP when it was– that was a new thing. And SaaS itself, cloud were all very new concepts. And I remember, with a completely straight face, I’d be talking to a C team at a company, and the technologists there, the CIO, CTO, would say, “Well, if we can’t find the right solution or we’re not confident in it, we’ll just build our own accounting system or build our own inventory management system. ” And you fast forward a few years, and we all realize that, unless you’re in an extremely precise niche – and even then it doesn’t fit it – you would think they were crazy. And we’re kind of at the same point with integration right now, where or it’ll come up and it’ll just come up in conversation. And it’ll be like, “Oh, yeah.” I was like, “Oh, how did you integrate those? Oh, you just went live on X. How did you get that integrated?” “Oh, our IT team just coded everything together.” And we’re in the midst of that transition. In a few years, it will be assumed that if you don’t use an integration platform to connect your application, that you’re in the Stone Age. And I think that’s maybe one of the big things we want to leave everybody is that’s where the world is headed and there’s tremendous benefits in an organization to adopt that early. And we saw that ourselves and it’s really there for everybody. Very, very true, Mark. We have a couple of questions from the chat from Tuon. I don’t know if I’m pronouncing your name correctly, Tuon. But– Yeah, that’s correct. Matt [crosstalk]– Okay. Matt [inaudible] thanks for the session. Yeah, this is actually an interesting question. I have this debate all the time with our portfolio companies. How do you balance technical debt versus new features that are going to bring in new revenue, right? Sometimes the product is created sort of widget style and now it needs to be made enterprise-ready. What’s, in your opinion, sort of the good general rule? I have a lot of thoughts about that but I want to sort of remind you that our focus here is actually more about internal business processes, right? So less about shipping product even though, of course, our lay product that Celigo saw, I have a lot of thoughts on this. But our focus here has been more about the internal business processes of a SAS company and less so on on the product itself. Okay. No worries then. Don’t worry about it. I will [crosstalk]– Okay. –another time and have a conversation on LinkedIn or something, okay? Yeah, I’d like that. Yeah, sure. Thank you. Were there any questions? As Tuon did, you can take yourself off mute if you just want to chime in or write them directly in the chat. Hey, you said there’s three different implement– can you go back one slide? I was just curious about the three different implementation methods. So you have this centralized system. You didn’t build it yourself. You bought it and it works out of the box in some ways. How easy is it to connect it to all these individual software services? And how are these three different implementation methods different? Yeah. This actually refers more to how the work gets done. So– How the work gets done. Okay. So, yeah. The centralized column means that all the work is done so by IT. It’s centralized. And we’ve seen that in businesses that we tried to help where the line of business will say, “Yo, I need this integrated to that. And I’ve got to put in a ticket with IT and wait six months before anything happens,” right? So that’s centralized. Decentralized, as I said, is a bit like the Wild West where it’s like there is maybe early stage company. Maybe there is no central IT or at least beyond just keeping the lights on. And so it’s every department for themselves. So it becomes a bit of a mess. And what we’re advocating on the right here is to have a common way of doing things, centralize management using an integration platform but to empower the organization, even members of different lines of business to do the development themselves. So you get the development is distributed but it’s done through a single platform And therefore, the management of that is centralized. The error reporting dashboarding, all of that maintenance is all done in one place. So that’s the distinction. Okay, that’s what– yeah, I understand. Thank you. Yeah. So that distributed model, for example, IT or business systems group then becomes more of almost you consider it a center of excellence almost. So though they’d often provide oversight and coaching and guidance, maybe architecture guidance, they would review the marketing department, say, “Hey, we want to build these.” And they might come in and say, “Hey, you know what? Nobody on your team has experience yet with our iPass. Here, we’ll help you build out the first one and maybe train someone in marketing ops how to build out their first integration, maybe templatize it and give it to him.” And then from there, marketing ops takes over and runs with it. And now, they’re now enabled and you get that synergy of games from specialization in IT but without the bottleneck of always having to wait on one group. And then if you’ve got smaller groups that, say, don’t have the same resources, then maybe that centralized group is still building theirs. And so it ends up kind of being this hybrid model. As teams grow, they take on more. And we see a lot of companies going now even skipping over centralization and going from decentralized straight to that type of model, even. Thank you. Any final questions? Is there a reason why you’re not loading your leads directly in Salesforce? I’ve been through a Salesforce implementation a few– ERP implementations. I’ve heard of this platform HubSpot. Yeah. So Salesforce is where the leads live but HubSpot is the marketing automation platform. So if we’re running a marketing campaign, I think it also collects visitor information from the website. So think of HubSpot in the league of like a Marketo or a Pardot or one of those. So maybe you’ve heard of those. But the leads do live in Salesforce because, of course, that’s really the beginning of the opportunity lifecycle. It starts with a lead. Yeah. Yeah. And that’s a case where we use a hybrid approach with integration as well where we started out using the out of the box point to point vendor build integration and then augmented that and migrated to using some custom flows on our iPass. That makes sense. Okay. Well, I think we’ll leave it there. I think we’ve used up our time. But really appreciate your attendance. I think the recording will be published shortly. And if you have any follow-ups, you could track us down on LinkedIn or via Saligo dot com. And we thank you very much for your time. Thank you. Thank you