When companies start working with AI and customer data, the first step is often to connect the model to the systems that already contain customer information.
A CRM is an obvious place to start. Depending on the use case, teams may then add data from billing, customer support, product usage, marketing platforms, or a data warehouse. Modern AI tools make these connections increasingly easy to build, and it is tempting to think that once the model can access all of these sources, it has everything it needs to understand the customer.
In practice, this is rarely the case.
The difficulty is not usually a lack of customer data. Most established companies already have plenty of it. The difficulty is that the data has been collected by different systems, at different times, for different purposes, and often using different representations of the same customer.
Before an AI system can make good use of this information, those differences need to be addressed.
Customer data is distributed by design
Consider a company that has been operating for several years.
Customer information may be spread across a CRM, an ERP or billing system, a customer support platform, a product database, one or more marketing tools, and a data warehouse. Website and application events may be stored separately again.
There is nothing unusual about this architecture. Each system has been introduced to solve a particular problem, and each one has its own model of the customer.
The CRM might identify a person through a contact ID and email address. The billing system may use an account number. The product database might have its own user ID, while the marketing platform maintains a separate contact record.
Sometimes these identifiers can be connected directly. Often they cannot.
People change email addresses, create multiple accounts, or appear under slightly different names. In a B2B environment, the situation becomes more complicated because people and companies have relationships with each other. A single organization may have several accounts, subsidiaries, domains, offices, buyers, administrators, and users of the same product.
As a result, the same person or organization can appear several times across the company's data landscape.
This has always been a data management problem. The difference with AI is that the consequences become more visible when an application starts using this information to answer questions or make decisions.
Connecting AI to the CRM is not enough
Suppose an AI assistant has access to a customer's CRM record.
The record says that the account is active. The assistant can see the contact details, recent opportunities, and perhaps some notes from sales.
But the billing system shows a different part of the story. There may be an overdue invoice or a recently changed subscription. The support system may contain several unresolved issues. Product usage may have declined substantially over the last few weeks.
All of these pieces of information can be correct.
The problem is that they are maintained in different systems and may not be connected in a way that allows the AI application to understand that they refer to the same customer and how the different events relate to one another.
This is an important distinction.
Giving an AI system access to more sources does not necessarily give it better customer context. If the underlying identities are inconsistent, adding another source can simply add another version of the customer to the picture.
For example, a customer-service assistant could respond to a question based on an active CRM record without taking into account a recent support issue. A sales assistant could recommend an upsell without knowing that the customer has recently reduced usage or is considering cancellation. A marketing application could treat an existing customer as a prospect because the relevant records were never matched.
These are not necessarily failures of the AI model. They are consequences of the information and context provided to it.
Identity resolution becomes part of the AI architecture
This is why customer identity deserves to be considered as part of the architecture of an AI application, rather than only as a data-quality task.
Traditional customer data systems were largely designed around operational and analytical needs. A unified customer profile might be used for reporting, segmentation, marketing campaigns, or synchronizing information with other applications.
AI introduces some additional requirements.
An application may need to know not only which records belong to a customer, but also how those records were connected, where the information originated, when it was last updated, and what has happened over time.
This becomes particularly important when identity resolution is not completely deterministic.
If two records are matched because they share a unique identifier, the relationship is relatively straightforward to explain. Other matches may depend on several attributes and on rules or probabilistic methods. In those cases, the resulting relationship is part of the context that an AI application may need to understand.
The same applies to the information associated with the identity.
A customer profile should not simply contain a collection of values. It should retain enough context to understand where those values came from and how they relate to the underlying customer history.
That is what makes an AI-ready customer profile different from simply adding more fields to a CRM record.
From source systems to an AI-ready profile
A useful way to think about the architecture is to separate the systems that produce customer data from the representation that applications consume.
A simplified version might look like this:
CRM -----------┐
Billing -------┤
Support -------┤
Product -------┤
Marketing -----┤
Events --------┤
Warehouse -----┘
│
▼
Identity Resolution
│
▼
Customer Data Foundation
│
┌─────────┼─────────┐
▼ ▼ ▼
AI Apps Analytics
The source systems remain important. They continue to own the operational processes for which they were designed, and the original data should remain available.
The customer data foundation provides another view of that information. It brings together the records that belong to the same customer or entity and adds the context needed to use them consistently.
Depending on the organization, this can include identity relationships, source information, timestamps, historical events, relationships between people and companies, and governance information.
The implementation can vary considerably. Some organizations may build this layer directly on top of their data warehouse. Others may use a dedicated customer data platform or a combination of data infrastructure and identity-resolution services.
The important part is the separation between the original sources and the customer representation consumed by applications.
The problem with almost-correct data
One of the more difficult aspects of customer data is that the most problematic records are not necessarily the obviously incorrect ones.
Imagine that the CRM shows an active customer, the billing system shows a valid subscription, and the marketing platform still includes the same person in an audience created several months ago.
None of these records has to be wrong.
At the same time, the support platform may contain several recent complaints, while product data shows that usage has fallen considerably.
The difficulty comes from interpreting these pieces of information together.
A person reviewing the situation can recognize that something may have changed and investigate further. An AI application may instead receive a collection of apparently valid facts and produce an answer based on them.
This is one reason why data quality for AI cannot be reduced to checking whether individual fields are valid.
The relationships between records matter as well.
So does the history behind a value. A customer's status may have been correct yesterday but no longer describe the current situation. A contact may still have a valid email address while no longer working for the company associated with the account.
An AI-ready profile therefore needs to provide more than a current snapshot. It needs enough history and context to make the information meaningful.
AI does not necessarily need more data
There is a natural tendency in AI projects to focus on giving the model access to more information.
For customer applications, that approach has limits.
A company may have years of transactions, support conversations, website events, product activity, and CRM records. Making all of that information available does not automatically improve the quality of the resulting answer.
In some cases it can make the problem more difficult, particularly when different sources contain conflicting or outdated representations of the same customer.
The more useful question is usually what information the application needs for a particular task and whether that information can be trusted in that context.
This does not mean that raw data or historical events are unnecessary. Quite the opposite. They are important because they provide the evidence from which a customer profile can be constructed and, when necessary, reconstructed.
A possible flow is therefore:
Raw customer data
│
├── CRM records
├── transactions
├── support interactions
├── product events
└── marketing activity
│
▼
Identity + context + governance
│
▼
AI-ready customer profile
│
▼
AI application / agent
Keeping this distinction also has a practical advantage.
If identity-resolution rules change, or a source system introduces new information, the customer profiles can be recalculated from the underlying data rather than becoming another independent data store whose contents have to be maintained manually.
That is particularly useful as AI applications evolve and require different views of the same customer data.
Where does the CDP fit?
This naturally raises the question of whether a Customer Data Platform is the right way to implement this layer.
A CDP can bring together information from multiple systems, resolve customer identities, create unified profiles, and make those profiles available to other applications. These capabilities can provide an important part of the foundation required by Customer AI.
There is, however, a difference between having a unified customer profile and having a profile designed to provide reliable context to AI applications.
Many CDP implementations have historically been centered on marketing use cases: segmentation, audience creation, campaign activation, and personalization.
Those use cases remain relevant, but an AI application may have different requirements.
It may need to understand the relationship between a person and an organization, distinguish current information from historical information, trace information back to its source, or understand why two records were considered to represent the same entity.
For this reason, when evaluating a CDP for AI use cases, it is worth looking beyond the number of connectors or activation destinations.
The more fundamental question is how the platform represents customer identity and context, and whether that representation can be reliably consumed by applications outside the traditional marketing workflow.
Trust in AI also depends on the data foundation
Discussions about enterprise AI often concentrate on the model itself: accuracy, hallucinations, security, evaluation, and governance.
Those are all important areas.
But for customer-facing applications, there is another layer underneath them. The application needs to establish that the information it is using actually describes the right customer and that the information is sufficiently current and contextualized for the task.
That means being able to answer relatively practical questions.
Where did this information come from?
When was it updated?
Which identities have been connected?
Why were they connected?
What happened before the current state?
Can the relationship between two records be explained?
Can the profile be rebuilt if the underlying data or identity rules change?
These questions are primarily data and architecture questions, but they have direct consequences for AI applications.
A model can reason only over the context that is made available to it. If that context is fragmented or ambiguous, changing the model does not necessarily address the underlying problem.
Building the foundation for Customer AI
For organizations working toward Customer AI, the data foundation is therefore becoming an important part of the architecture.
It needs to bring together information from different systems, resolve identities, preserve the relationship with the original data, and provide applications with a consistent view of the customer.
In practice, this means being able to:
- collect customer records and events from different systems
- resolve identities across those systems
- preserve source information and historical data
- maintain relationships between people, companies, accounts, and other entities
- provide sufficient context around customer information
- apply appropriate governance and permissions
- expose reliable customer profiles to applications that need them
A CDP can be one way of implementing these capabilities, but the architectural requirement exists independently of the product category.
As AI becomes more involved in customer service, sales, personalization, and other customer-facing processes, the quality of the underlying customer representation becomes increasingly important.
The challenge is not simply to make more data available to AI. It is to make the relevant customer context consistent enough that an AI application can use it without having to reconstruct the customer's identity and history from disconnected records every time.
That is the role of an AI-ready customer profile.
And in many organizations, building that profile may turn out to be one of the less visible, but more important, parts of the Customer AI architecture.
Top comments (0)