The CRM solution has long been used as the main customer base by companies. The CRM software, whether “Sales” CRM like Salesforce, or a “Marketing” CRM like Splio or Adobe Campaign, was used both as a customer base and as a customer relationship management tool.

Then a new family of software appeared: the Customer Data Platforms (or CDP), designed to play the role of customer database instead of the CRM. CRM softwares has structural limitations when it comes to database management. CRMs do not handle behavioral data, real-time data or multi-source reconciliation (which is essential for unified data). These limitations explain the rise of CDPs.

With the multiplication of tools, data sources and the growing importance of behavioral data, more and more companies are choosing to manage their customer base independently of their main CRM software. This new paradigm of decoupling the customer base and activation tools is made possible by the latest generation of CDP.

When looking to build or improve your CRM ecosystem, you need to ask yourself this key question: which system or tool should play the role of the primary customer base? Some companies still believe that CRM is able to play this role. Others, on the other hand, choose to equip themselves with a CDP. Most companies are a bit confused and don’t know what to think. If you are one of them, don’t worry, we have written this article for you.

In this publication, we will start by helping you to better understand the differences between CRM and CDP. We will then take the time to outline the requirements for a customer base to act as a customer repository. This will lead us to discuss the various reasons why we believe that CRM software is no longer suitable for this role.

Understanding the differences between CRM and CDP

First of all, it should be remembered that CDP and CRM are not competing solutions, but complementary ones. A company that is equipped with a CDP usually also has a CRM.

To begin, here is a table summarising the main differences between CRM and CDP:

CRM definition – Customer Relationship Management

A CRM software is used to centralise the management of customer interactions. There are four families of CRM:

• Sales CRMs, used by the sales teams, designed to manage the follow-up of commercial opportunities, drive commercial activity. This is the oldest CRM family.
• Marketing CRMs – or marketing automation tools – used by the marketing team, designed to manage customer segmentation, marketing campaigns and scenarios.
• Customer service oriented CRMs, intended for contact centres and used to manage interactions on customer service channels: tickets, telephone, livechat…
• All-in-one CRM solutions that manage sales, marketing and service interactions equally well.

The CRM is therefore a tool before being a database. Except that, as we recalled in the introduction, CRM has in fact been playing the role of a database for a long time. It stores :

• Cold data, essentially profile data and contact information: last name, first name, gender, date of birth, telephone, postal address.
• Conversational history: email exchanges, social media, appointment notes, etc.

Vendors have all developed connectors for CRM to accommodate other types of data, for example transactional data and, with much less success, behavioural/web browsing data. This has contributed to the evolution of CRM from an activation and interaction management tool to a primary customer repository.

Reminder – Customer Data Platform definition

A Customer Data Platform is a technology that is used to unify customer data, prepare it according to business use cases and, finally, redistribute it to other business systems (activation tools and reporting tools). It is basically a data management tool.

A CDP is used to carry out 4 main activities:

• Connect. It connects to all of the company’s customer data sources, with data flows that can be built via native connectors, APIs, webhooks, flat file uploads, etc.
• Structure. Data is organised in a customised data model according to the needs of the business. It is de-duplicated based on one or more reconciliation keys. Deduplication allows data to be consolidated, reconciled and unified around persistent customer profiles.
• Prepare. The data, once unified, is used to build audiences, segments, scores and other computed fields.
• Synchronise. Segments, audiences, scores are then redistributed to activation tools (CRM, Customer Service, Marketing Automation, advertising tools…).

The CDP Institute has identified some criteria for a solution to qualify as a Customer Data Platform:

• Integrate data from any source.
• Capture all the details of the ingested data.
• Store ingested data permanently..
• Create unified customer profiles.
• Share data with systems that need it.

Focus on the main differences

Let’s summarise the main differences between CRM and CDP here:

• The purpose. CRM is used to manage the customer relationship, CDP to manage customer data. CRM and CDP are both used, although in different ways, to improve customer performance.
• The users. CRMs are used by operational teams involved in managing customer dialogue: sales, marketing, customer service mainly. CDPs are intended to be used by rather tech-savvy marketing profiles and data teams. CRM and CDP are designed to be used autonomously by business teams (without the IT team).
• The data. A CRM manages cold data and relationship records (conversational, contractual, transactional) very well but poorly with hot data. However, a CDP manages all types of data, including behavioral data (web tracking…). CRM and CDP are essentially focused on first-party data, following the sense of history (end of third-party cookies).
• The mode of data ingestion. CDPs handle real or near-real time, either as input (connection to sources) or output (distribution to destination tools). CRM data is either ingested in batch or manually recorded by users. This is because CRM use cases do not require real-time ingestion.

What does it take to properly manage your core customer base?

The formulation of the differences between CRM and CDP already gives some clues to the question we set out to address in this article: which tool or system should play the role of the main database. Let’s continue our investigation. We will now define the main characteristics that a customer database must have in order to play the role of master DB or “Single Customer Repository”.

The main customer base must be exhaustive

The database should centralise all customer data that is of known or potential interest to the business. A company can store different types of data:

• Profile data.
• Contact information.
• The history of interactions, whether conversational or transactional.
• The preference data.
• Behavioural data: web browsing, product usage (within the software or the app)
• Engagement data, e.g. email behaviour (opens, clicks, etc.).
• Etc.

.

There are many ways to categorise different types of customer data. It does not matter here. The main thing to remember is that a customer database, in order to be exhaustive and play its role as a master database, must be able to handle all types of data: hot data as well as hot data, third party data as well as personal data, online data as well as offline data, web logs as well as phone numbers.

The main customer base must be unified

The main customer database is intended to aggregate all the customer data collected via the company’s various data sources. This aggregation necessarily produces duplicates, which can have 2 origins:

• A customer may be identified differently in two different tools. For example, a customer may be identified by email in the Marketing Automation tool, by a customer number through its personal account and by a phone in the customer service software. As a result, if you don’t use a matching key, you won’t be able to tell that it’s the same customer behind the three identifiers. You will have three duplicates, three unreconciled identities.
• The same tool can store the same customer in two different places. Example: if you use a CRM that uses email as a unique identifier and a customer uses two emails, you will have two contact records, two identities.

In both cases, the problem is basically the same: there is no identity resolution.

It is essential to be able to unify the data that reaches the main customer base. How can this be done? By setting up more or less complex deduplication rules, enabling data to be matched and records to be merged.

The main customer base must be clean

A clean database meets 4 conditions. The data it stores must be :

• Subject to a consistent and appropriate data model. The data model defines how the data comes to be organised in the tables that make up the database.
• Normalized. Normalisation refers to the way in which data is recorded and displayed. For the object “gender” for example, one can use the formats “F” and “M”, or “Female” and “Male”…For each object, one and only one format must be defined. This is what is known as the “normalisation” of data.
• Cleaning. Cleaning refers to the process of checking the accuracy of data and removing/updating inaccurate data.
• Regularly updated. Data cleansing, which is a one-off and periodic operation, must be complemented by the implementation of automated data flows allowing for regular data updates, even in real time in the case of behavioural data.

A customer database, in order to play the role of a main database, must therefore offer :

• One or more data models that are sufficiently flexible to meet the needs of the business and the characteristics of its data.
• Data normalization features.
• Data quality management and enrichment features.
• Real time or near real time management to be able to continuously update behavioral/heat data without delay.

The main customer base should act as a hub with other systems

The main customer base must be able to easily feed the company’s other systems, whether they are operational/activation tools (sales CRM, marketing CRM/marketing automation, customer service CRM, advertising platforms…) or analysis tools (BI, reporting, data science…).

It should be easy to “wire” to the destination tools, whether via native connectors, a robust API, webhooks or manual exports.

The structural limitations of most CRM / marketing solutions to play the role of customer base

Most CRM/marketing software are not designed to play the role of the main customer database, for the good reason that it is customer relationship management software, not customer data management tools.

Rigid data model

The data model proposed by CRM solutions is more or less rigid, often more than less. As a reminder :

• Lightweight CRMs (campaign managers or small Sales CRMs, for example) are single-table. All the data is organised in a single table.
• Intermediate tools are multi-table but “frozen”. The data model is organized on several tables (customers, products, orders…), but it is difficult to add new tables or to modify the relationship between tables.
• Advanced tools like Salesforce are both multi-talented and flexible.

The consequence is that updating the data model of a CRM is difficult, unless you have a very advanced (and usually very expensive) CRM like Salesforce. First limitation.

No multi-source reconciliation

In most CRMs, the email is the key. This means that if the same individual registers with two different emails, this will create two lines within the CRM, even if the individual has registered with the same phone, the same first name x surname, the same postcode…

The consequence is that this generates duplicates in the Contacts table, as we saw earlier, but also some difficulties in associating the contact with all its touchpoints. If, for example, an customer writes to the customer service department with a different email than the one they registered with, and if I cannot reconcile the contacts and the customer service tickets using several keys, then it will not be possible to associate the individual with the customer ticket.

To do this, the CRM must be able to manage multi-source deduplication rules. It is with this type of rule that we could tell the tool: “If two contacts have a different email address but the same postal address + the same first name, then the two contacts must be deduplicated and merged”.

No or little normalization & data cleansing

In a CRM tool, the possibilities for data cleansing are very limited:

• Normalisation. It is not possible to use “Find & replace” rules that allow, for example, all “FR” to be replaced by “France”, or all “Miss” to be replaced by “F”.
• Cleaning up important fields. CRMs do not, with rare exceptions, include a service to check the existence of email addresses or to make Postal Address Verifications

Therefore, data normalisation and cleansing must be done on the front end of CRM, using custom scripts that are complex to maintain.

No computed fields & scoring

A CRM tool is like Excel but without the formulas… In most CRM solutions it is not possible to add computed fields. Some CRM tools propose computed fields by default (average basket, cumulative, etc.) which are impossible to modify.

However, the ability to create computed fields is essential, especially when it comes to implementing marketing automation scenarios. For example, in order to exclude customers who have recently expressed dissatisfaction, we need a “status of the last customer ticket” or “number of customer tickets over the last X days” field. Creating this type of computed field (scoring or otherwise) is very difficult, and often impossible in a CRM.

No direct access to the database for reporting

A main customer database is used to activate customers, to “act”, but also to analyse the data and to do reporting. Reporting on a CRM database is not easy, because the reports available in the tool are very quickly limited.

Let’s take the example of automated scenarios. In order to measure their impact, we need to use cohort analysis. For example, if we want to deploy a new upsell scenario that consists of sending a sequence of messages 1 month after the first purchase, we will need to look at each monthly cohort of new buyers to see if the number of purchases after 2 months has increased.

How do you do this in CRM software? There is only one solution: export the data to a database/datawarehouse, and then connect your reporting tool to the database in question. It is not possible to connect the reporting tool directly to the CRM software, you have to go through the database…

History’s direction is the decoupling of the customer base and the activation of customer data

From the “software CRM” to the “ecosystem CRM”

CRM today refers to the management of all interactions and activations with identified customers. In most companies, CRM is no longer operated by a single software, as in the past, but by a set of tools, a combination of solutions:

• A campaign manager.
• A marketing automation tool (or CRM Marketing)

.

• A sales activity and sales pipeline management tool (or CRM Sales)

.

• A helpdesk/ticketing tool (or Customer Service CRM).
• Advertising platforms to retarget known customers with Ads.

CRM has become an environment, an ecosystem of software. This is one of the reasons why it is no longer really possible to use CRM as a customer repository: a company uses customer tools, but needs a master customer base.

The benefits of managing a customer base separately

If you have read all of the above, you are probably beginning to realise the benefits of managing a customer base separately.

Having a separate customer base allows you to :

• Connect all of the company’s customer data sources, in complete freedom, without limitations and in a simple manner (through connectors, APIs…). The connection capabilities are indeed slowed down when the customer base is built in a tool that belongs to a constituted ecosystem (Salesforce for example): the editor will often try to get you to use the other tools of its suite.
• Create a single comprehensive customer view, combining hot and cold data. This benefit follows from the previous one.
• Prepare data in one place. You centrally manage customer segments, audiences, scores, deduplication rules…You no longer need to do this work in every tool in your CRM ecosystem.
• Do not lock data into a rigid data model. You create a flexible, bespoke data model, tailored to your current and future use cases.
• Easily synchronise prepared data in the different systems that need it, in real time when necessary.
• Be able to use the customer base to feed activation tools but also reporting tools, and this directly, without having to go through an intermediate system.
• Staying in control of your customer data. The issues around data control are becoming crucial for many companies. Building an independent database allows you to keep full control over your data.

Small presentation of the approach proposed by Octolis

We have been Data / CRM consultants for many years. We have often been confronted with the limits of CRM in the course of our missions. Some of our clients had a unique customised Customer Repository, which was very flexible, but every change required technical intervention. Other clients had first generation CDP solutions, you have a nice interface to manipulate the data, but the downside is that you don’t have control over the data, and less flexibility on the data model.
It seemed obvious to us that we needed to reconcile the two approaches. A custom database, controlled/hosted by mature customers, completed with a software interface on top.

This is the way the story goes. The democratisation of datawarehouses is encouraging this hybrid approach. CDPs are leading the way, but we are starting to see other types of SaaS software that use the customer’s data warehouse as a foundation.

Some of our clients already have a main client base: in this case, we “plug” Octolis into this base. If you do not yet have a main database, Octolis will create one for you.

We wanted to create a self-service software interface, accessible to business profiles, usable by both marketing profiles (in “no code”) and data teams in SQL. As a new generation CDP, Octolis allows you to manage the 4 functions that we presented above: Connection, Preparation, Structuring, Synchronisation.

Here is a very quick overview of the solution. You are first asked to connect the different data sources. Among these data sources, of course, is the independent customer database.

It is on the “Audiences” menu that you prepare and structure the data: deduplication rules, normalisation, construction of audiences and segments, creation of calculated fields (indicators, scorings, etc.).

You can synchronise the data prepared and transformed in Octolis in your tools and in your main database at any time.