Sales and marketing integration is not an easy project to tackle. Yet, it is a priority for sales and marketing teams tasked with finding ways to share key customer data throughout the organization. We put together a list of the top questions and considerations you may encounter as a sales and marketing manager.
1. Defining the source and target of the integration
Identifying customer data that needs to pass between systems can be one of the biggest challenges with integration. In addition to sales and marketing data that may be stored in a system such as Salesforce, organizations may need one or more of the following for a complete 360-degree customer view: quotes, proposals, project status, order status, invoices, cash receipts, customer service records and costing for products or services sold.
When gathering requirements for an integrated system, get to the bottom of what types of data and data fields each department needs and why they need it. Not all data needs to pass to all people. In fact, this will clutter your system and possibly decrease data quality and user adoption. You might also consider that new data fields may need created or existing data fields need changed to fulfill the objectives of what a specific team wants to do with that data. For example, your sales team can’t call on all prospects in the state of California if your marketing team doesn’t classify leads by state.
2. Defining the system that will aggregate the data
Usually, the most logical place to aggregate data from multiple departments is in the sales and marketing system. However, this system must be capable of aggregating the data in a way that teams can effectively use that data.
We usually recommend Salesforce because of its integration and customization capabilities that extend far beyond CRM. Salesforce is the No. 1 cloud solution for managing data for the whole enterprise and turning that data into actionable information through dashboards and reports provides a clear 360-degree view of the customer.
3. Defining the source of truth or system of record
Businesses need to determine the “system of record” for each type of data. The system of record is the authoritative data source for a given data element or piece of information. Clearly define in writing which application serves as the system of record for each type of data so that it can be considered the real source of truth.
For example: if your organization has a quotation system, it should be clearly defined as the system of record and source of truth. That means information entered in spreadsheets, emails or other ad-hoc storage system will not be recognized as the source of truth. In fact, we always recommend all data that can be stored in Salesforce or other system reside in Salesforce.
If teams are still using spreadsheets or other method to manage data, that’s a red flag you need to revisit system requirements and implement a new solution accordingly. You also may have different fields that are a record of source in the system but other fields that are controlled in a read-only format in another system. That has to be mapped and accounted for in the integration.
4. Connecting modern cloud systems with premise-based systems
Some applications are housed on “premise” and some are housed in the cloud. It’s not uncommon for sales and marketing applications such as Salesforce to be cloud-based while other systems are still premise based. Premise-based applications involve additional requirements and challenges for a successful integration because they are installed and run on computers on the premises instead of being accessed remotely through the cloud. You’ll need to determine how much control you need over the environment where the data sits. Banks, for example, like to have their data on premise because it needs encrypted, which is more difficult in a cloud-based environment.
5. Connecting Sales and Marketing system APIs with other APIs
Leading cloud-based sales and marketing systems have an open Application Programming Interface (API), which enables easier integration. Other systems may not have data services and an API that allows data to be passed between systems. Integrating systems that don’t have an open API requires an experienced data services and integration developer who can complete the development work necessary to enable the integration.
6. Deciding on an integration tool or custom integration
After data services and APIs are in place, the actual connection must be carried out. This is sometimes done with the use of a “middleware” integration tool such as Jitterbit. Businesses also can create a custom integration coded by an integration specialist. We recommend using a middleware tool whenever possible. A consultant can also help you determine which tool is best for your specific use cases.
7. Understanding availability of integration expertise and support expertise
Integrations are usually difficult; businesses need to make sure they have specialists in place for the development, implementation and on-going support required for a successful integration. The more applications involved in the integration, and the more data security requirements involved, the more complex the integration gets, which also increases cost. Failing to have an experienced, reliable integration specialist can have very damaging consequences.
Also, if you are connecting to another system and don’t have expertise in the technology, or it’s a proprietary technology that isn’t available for you to manage or edit, you may need additional support from vendors to support the integration.