If you’re reading this blog post, chances are you’ve also seen Scott Brinker’s annual Marketing Technology Landscape Supergraphic. Here’s a quick refresher on the state of martech tools as of April 2020:

There are now 8,000+ tools in the landscape, up 13.6 percent year-over-year. (So basically the same amount of days the pandemic has gone on, amiright?)

This growing abundance of specialized tools means that marketing departments are adopting more of them than ever before, with an average of 120 tools per enterprise-level department. For teams that don’t plan out tech stacks strategically, each new tool brings the risk of creating a data silo within that tool.

Why does that matter? Because each tool in your tech stack provides more value if it can share data with and receive data from other tools in your tech stack. It’s just a fact, and it’s why a system integration project should be part of your adoption roadmap for each new tool you add.

SpongeBob Sharing is Caring
What is a system integration project?

A system integration project entails connecting two disconnected technology platforms so that they automatically exchange data back and forth. These projects can range in complexity from a native integration that you can configure yourself in just a few clicks, to large-scale and fully customized integration that will typically involve your IT department and/or other technical outside resources.

In a nutshell, you need to determine a few things as part of your integration project. We’ll dig into the specifics here, but if you want more information you should check out what my colleague Brent Worley wrote about this topic. He leads our integration projects at SmartBug®.

Which tools are you integrating?

Have I seen system integration projects that don’t actually provide any business value? Unfortunately, yes—when I was a wee in-house marketer, my team uncovered that only one department used one field in our loathsome customer relationship management (CRM) platform. That was it. Just one.

Who knows how much was spent on creating those ultimately useless integrations. Learn from their mistakes, and make sure you can name the specific benefits your integration will enable before pursuing it.

Example: Connecting your CRM to your marketing automation system is a no-brainer. It provides both teams with the contact information they need: Sales can see contact history prior to being moved to sales, and marketing can learn which activities lead to sales success and receive leads back for more nurturing if needed.

Which data points are you integrating between systems?

Just because you have a bazillion fields in your CRM doesn’t mean they all need to connect to something in your other tools. Think about the role that a given tool has and which data points would enable it to have the greatest impact. Also consider which data points that tool gathers that would be actionable in other tools.

Example: Say you track how many times an existing contact visits your website. Once they reach a certain number of visits but haven’t taken the crucial next step, it might make sense to pass their information into your remarketing tool of choice for targeted ads. Alternately, say your sales team updates certain fields in your CRM during discovery calls. If some of the fields they update aren’t actionable to marketing, don’t waste time integrating those fields to other marketing tools.

Which tool is the authority on each data point?

This is more of a means to avoid unintended problems with your data post-integration. If a given data point should really only be updated by a specific tool, ensure that other tools don’t have the ability to change that data (even if they continue to passively receive that data from the source tool).

Example: Imagine that your lead assignment process occurs once a contact is entered into your CRM. The other tools in your martech stack shouldn’t have the ability to change the contact owner field, because it would overwrite your carefully planned assignment process and create confusion.

Why do we need a system integration? Can’t we just move data manually?

Most of the tools in your tech stack probably have export capabilities for most of the data, right? So you can probably just have someone on your team manually export data and import it into another system once a week or something, right?

Michael Scott Meme-1

Wrong. Eschewing an integration and having someone do it manually like this is a bad idea for a whole slew of reasons.

It’s error-prone.

Introducing more manual touchpoints as your data moves from one tool to another increases the likelihood of errors.

It’s time-consuming.

Is there really no better use of your team’s time than exporting and formatting the data one system provides so it will import correctly into another system? I bet they could pick out one long-tail, low-difficulty keyword and write a blog post targeting it in the same amount of time they’d spend fiddling with spreadsheets. Revisit it a month later, and see how many leads the blog post received compared to slinging data you already had.

It’s not in real-time.

When data takes hours or days to pass between systems, the time frame when that data is most useful can pass you by. If a high-value prospect visits your website, would you rather have your sales team reach out to them in five minutes or five days? The former is possible with real-time integrations, while the latter is possible in a recurring and manual data transference process.

Now get out there and tackle your system integration project.

To stay in the loop on the latest marketing developments (including developments with Operations Hub and all the system integrations it provides natively), register for our SmartTake webinar series today.