Writing the specifications for your Customer Data Platform (CDP): guide & template to download

In a Customer Data Platform implementation project, a specification serves as a reference document for all project stakeholders. It describes the project’s objectives and specificities, and will serve as a basis for interacting with the CDP editors that you will call upon. It is the culmination of the preparatory work, not the starting point of the project, contrary to what you might think!

Indeed, the most important thing is really the process that leads to the document. The methodology must be structured, to ensure that you choose a solution that is adapted to your needs and to encourage the support of future users. In this article, we detail the steps that lead to the creation of your CDP specifications.

As a bonus, we provide you with a free downloadable specification template, with the main document, and above all the appendix which lists the use cases and functional requirements. So save time in producing your CDP specifications and use our template!

Find our CDP specifications grid template for free download

📕 Sommaire

Step 1 – Prepare a CDP project
Step #2 – Qualify the needs and use cases of the CDP
Step #3 – Define the target architecture
Step 4 – Formalise your CDP project specification

Step 1 – Prepare a CDP project

Writing the specifications should not be the first step in the project that leads to the deployment of your Customer Data Platform. On the contrary, this document is the fruit of a process of qualification of the current situation, as well as the expression of your needs.

Diagnosing the current situation is an essential exercise in order to choose the right tool for your needs, and then to deploy the most relevant use cases for your business. The possibilities offered by CDPs are very wide, without a precise framework you risk getting lost!

Starting with the existing situation means defining the context, the challenges and the constraints specific to the company. To do this, you will need to define the reasons why you want to set up this project. For example, it may be difficulties in using customer data in its current state, or a disconnection between customer relations tools.

Like all good specifications, the specifications for your CDP project start with a general presentation of the company and its challenges. Don’t be too quick to skip this step, although it may seem obvious to you, it will be very useful to stakeholders outside your organisation. Even internally, you may get slightly different views from different departments and people.

This business context definition should contain

An overall description of your organisation: staff, missions, geographical scope.
A definition of your business context: what are the strategic issues facing your company that may be impacted by digital or data marketing issues? For example, the desire to conquer new markets, the desire to accelerate the deployment of digital projects or to make your business teams more autonomous.
Lastly, and without doubt the most important point, you need to take stock of your current customer IS or data marketing system.

This will help you define the overall framework of the project. Then, go into detail through the following aspects:

Objectives

Here, the idea is to specify your expectations for the implementation of this new tool. What will it allow you to achieve in addition to the existing one? Is the deployment of the tool part of a wider context?

Specify here the expectations of this new CDP, what will it allow me to do that was impossible before?

Some examples of objectives to help you formalise

Extract, unify and cleanse my data (potentially for RGPD compliance)
Reconcile my customers from multi-channel sources: create a unified online/offline customer profile
Create complex scenarios (email campaigns, retargeting, real-time interactions)
Build a frictionless omnichannel customer journey
Customer personalisation: product recommendations, predictive, preference matrices

Role of stakeholders

Involving multiple stakeholders and specifying their roles in advance will improve the efficiency of the project. The 3 teams you should definitely involve are: Marketing, IT and Data.

Be careful not to reduce your CDP project to a purely “tech” project, the involvement of the business teams, from the outset, plays a key role in the success of your project. You must think of your CDP project as a business project, because of its direct impact on your business performance.

This is the difficulty of carrying out such a project: the essence of your CDP is to improve your customer experience and, to this end, it involves changes (to a greater or lesser extent) to your data or IT system. It is therefore necessary to involve all the departments concerned by the customer experience (marketing, support, sales, digital, BI, etc.) as well as IT, of course.

As customer relations are at the heart of your company’s global strategy, it is also necessary to involve the managers of the departments in question, very often “C-level”.

Planning

Defining a schedule for the deployment of the CDP is essential to the smooth running of the project. This involves specifying a roadmap that establishes the key stages and the final production launch objective, including the time when user tests take place, for example, after the deployment of each use case.

In addition to this schedule, which is purely linked to the technical dimension of the project, it is necessary to plan a period of training for your teams and for getting to grips with the tool. Depending on the editor you select and the maturity of your business teams on these subjects, this period will be more or less important.

Level of budget required

Here you can specify the estimated budget for the project, without going into too much detail. Generally, the cost of a CDP is composed of 2 aspects:

The deployment of the CDP**: definition of use cases and functional requirements, installation, configuration and user training.
The operation of the CDP**: software and hardware costs.

Costs can vary greatly from one CDP vendor to another, and may depend on the metrics used (number of data sources to be connected, volume of data stored, etc.).

How much does a CDP cost?

In addition to the cost of the software, you must anticipate the costs of maintenance and upgrades, as well as the costs of training users. To estimate the cost of your project as accurately as possible, read our complete article on the cost of a CDP.

Understanding the types of solutions available

Finally, you also need to understand the environment of existing CDP solutions on the market. Step back from the customer data management tools in your current stack: what functionality do they provide? How do they interact? Do their interactions require tools to bridge the gap (e.g. iPass)?

Globally, there are 3 types of Customer Data Platform, differentiated by their functional scope:

CDP dedicated to data unification**, these are the most common. Data is collected from different sources, processed and unified before being made available to business applications.
Analysis CDP**, which is used to analyse customer behaviour.
Customer Experience CDP**, which combines the functionality of the two previous CDP types, allowing the management of the most complex customer journeys and the creation of personalised campaigns.

Now that you have a complete overview of what exists, you can move on to the second step: qualification of the need and use cases.

*Understanding the different types of CDP

We have written a comprehensive article about the different types of CDP offered by the market. It details the 3 families of Customer Data Platforms presented earlier.

Step 2 – Qualify the requirements and use cases of the CDP

Define a list of target use cases correctly

Before defining the functional requirements of the CDP, it is fundamental to get a sense of perspective and to think about the use of the tool within the organisation. To do this, ask the following question: what can’t I do today but would like to do tomorrow with my CDP? In summary, you should start by listing and prioritising the use cases for your CDP.

This exercise will serve as a basis for the functional requirements that you will define later, and which will derive directly from the use cases. These use cases translate the raison d’être of each expected functionality, and give its structuring points. Each element must highlight the problem that the functionality will solve.

All stakeholders should share their respective needs on the COP, and agree together on priorities. By bringing together members of several departments to write the use cases, you will be able to get buy-in and ensure that everyone agrees with the direction of the project. This should allow for a concrete comparison of possible solutions.

The format of your CDP use cases

The final format of your use cases is simple: a table with a prioritised list of requirements. Find here our Excel template for an annex to the specifications – use cases and functional requirements.

While the format of your use cases is simple, the method of arriving at them is not. Here are some of our tips:

Start with the customer journey, and identify opportunities at each stage that would improve customer data management.
Conduct interviews with everyone who works or could work with customer data: CRM teams of course, but also Procurement, Customer Service, IT, BI, etc. Try to include at least one person from each department involved in the product development, including the customer.

Step 3 – Define the target architecture

It is only at this stage that the technical part comes into play! Indeed, the technical specifications of the project are the functional translation of the use cases listed in the previous step.

Integration of the Customer Data Platform into your existing IT environment

How will the CDP be fed with data? How will it integrate with other company tools?

Existing data will need to be documented so that it can be supported by the CDP. The CDP will be fed continuously from different data sources. Most of the time, data ingestion is done using native, off-the-shelf connectors, but there are of course exceptions that your technical team must anticipate in order to develop these connectors.

Choosing the architecture and type of solution

If you have carefully read our article decrypting the main families of Customer Data Platforms, you know that not all CDPs position themselves in the same way in your customer IS.

Modern CDPs will be able to plug in on top of your data warehouse which then becomes the operational foundation of your customer data, whereas traditional CDPs create another “single source of truth” by storing your customer data alongside your DWH.

Evolution of customer IS over the last decade

Anticipating challenges and pain points

The deployment of a CDP will be a challenge for your entire organisation, and these changes should of course be identified and anticipated as soon as possible. We have already mentioned the human challenges: qualifying the required and missing skills in your company. Will it be necessary to recruit or outsource certain positions? There are other potential obstacles to anticipate:

Relationship planning: developing a programme based on the capabilities of the new tool
Integration: connections to data sources, development of connectors, database transfer
Change management: creation of tutorials, training of employees in the new tools
Data exploitation: creation of reports, BI
Tool maintenance: need for a dedicated CDP manager

To sum up, the definition of the target architecture of the CDP project includes technical, organisational and human aspects. It is an integral component of the CDP selection project framework. It is now ready to be inserted in the specifications that we will formalise in the next step.

Step 4 – Formalise your CDP project specification

Finally, you can now move on to the last step: writing your CDP specifications. To do this, find our predefined templates to download, as well as our best practices to follow in producing the specifications.

CDP specifications template: main document and annexes

A CDP project specification is generally divided into 2 parts:

A main document describing the company and the project, in Word format
Two annexes presenting the use cases and technical functionalities, in Excel format

This document will serve as a reference for the rest of the project. It must therefore be as clear as possible, which means above all that the document must be well constructed. It must also remain objective and functional, without seeking to promote one CDP solution over another.

Main document

The main specification document should contain a first part with a general presentation of the company, its activity, a business context and an overview of the Customer IS. Also introduce the reasons why you are considering a new CDP solution.

In the second part, you can go into more detail about the project with the objectives and expected benefits, the challenges, the different stakeholders and the schedule.

Finally, you can add a third part with the planned tender process, its organisation, selection criteria and schedule.

Annex with use cases

In this first appendix, we focus on the qualification of the need. We will find the prioritised list of the project’s use cases.

To formulate them, a good practice is to construct sentences in the first person. For example: “I can easily connect my customer database to existing reports to make them more reliable and enrich them”. This makes the situation more concrete for readers. You can also illustrate each use case with an example specific to your sector of activity.

Annex on functional requirements

This second part of the appendix contains the functional requirements of the CDP project, which are directly derived from the use cases. A priority can also be assigned to them.