From Walled-Off Data to Customer Context: Designing a Unified CRM Information Architecture
A case-study article on translating fragmented customer data into a unified CRM information architecture, connecting research, operations, business prioritization, KnowMe Cards, and future assistant-ready workflows.
Lorraine Dukes
AI & Systems Strategist
From Walled-Off Data to Customer Context: Designing a Unified CRM Information Architecture
The hardest part of enterprise UX is not always finding the problem. Sometimes the harder part is proving that the problem is expensive enough to fix.
That was the real challenge behind the data architecture phase of my CRM work at The Home Depot.
Across Salesforce-based CRM experiences, I kept seeing the same operational pattern. Customer information existed, but it was scattered across systems, contact centers, channels, and permission boundaries. Associates were expected to support customers during live service calls, but they often had to work with only part of the customer story.
On the surface, that looked like a usability issue. The associate had to search too much. The customer had to repeat themselves. The call slowed down.
But after studying the pattern across teams, I saw a larger business problem.
Every repeat question created avoidable friction. Every hold placed on a customer added time to the call. Every transfer to another team increased operational cost. Every disconnected system forced the associate to become the glue between tools that should have been working together.
The company already had much of the information. The issue was that the information was not organized, connected, or surfaced in a way that supported the service moment.
That research finding became the foundation for a broader proposal: a unified customer data strategy inside the CRM. The goal was to move fragmented customer information toward a multidimensional customer record that could support better service decisions, context-aware interface patterns, and future assistant-ready workflows.
This was the phase where the work moved from observation to influence. I had to make the case that information architecture was not just a design concern. It was an operational cost issue, a service-quality issue, and a roadmap priority.
That argument helped shape the path toward the KnowMe Cards, the first visible phase of the strategy, and later toward Homey, the assistant concept that could build on top of that customer context foundation.
Problem Statement
Customer service associates were being asked to support complex customer needs with partial information.
The organization had customer data. It had account records, service history, call context, purchase signals, operational notes, IVR inputs, and information collected across different service channels. The problem was that this information did not consistently come together inside the associate’s workflow.
During a live customer interaction, the associate needed a practical view of the customer’s situation. They needed to understand who the customer was, why the customer was calling, what had already happened, what the customer had already provided, and what information might help resolve the issue.
Instead, the associate often had to move across disconnected systems, ask repeat questions, place the customer on hold, or contact another team to locate information that was already somewhere inside the organization.
The problem was not simply that the CRM needed a better interface. The deeper problem was that the customer record itself was incomplete from the perspective of the service moment.
The core question became:
How might we organize customer information into a unified, service-ready structure so associates can access the right context during live customer interactions?
That question became the foundation for the unified customer data strategy.
Research Finding: The Data Existed, but It Was Not Operationally Useful
One of the most important findings was that the organization was not starting from zero.
The information existed. The issue was that it was fragmented.
A customer might provide information through the IVR before reaching an associate. Another system might hold account or order details. A different team might own service notes. Another workflow might contain operational status. The CRM might show only one portion of that story.
From the customer’s perspective, this felt confusing. They had already interacted with the company, but the associate did not always have the context from that interaction.
From the associate’s perspective, this created avoidable friction. They were responsible for helping the customer, but the system did not consistently bring forward the information needed to do that work efficiently.
This is what made the problem operational.
The issue was not only where information appeared on a screen. It was how information moved through the service ecosystem. A customer journey can cross multiple systems before it reaches a person. If the information gathered in those systems does not follow the customer into the service workflow, the experience breaks down.
That finding changed the design direction.
The goal was not to create another screen full of data. The goal was to define a more useful customer information structure, one that could support the associate’s work at the moment of need.
The Business Case for Information Architecture
In enterprise environments, research findings do not automatically become roadmap priorities.
A team may understand that a workflow is frustrating. A designer may see the service breakdown clearly. Associates may describe the same pain repeatedly. Customers may feel the friction on every call.
That still does not mean the organization will prioritize the work.
To move the problem forward, I had to translate the research into business language.
The question became: what was this fragmentation costing the organization?
It was costing time. Every time an associate had to place a customer on hold and search another system, the call became longer than necessary.
It was costing labor. Associates were spending energy gathering context that the company had already collected somewhere else.
It was costing service quality. Customers were being asked to repeat information, which made the company feel disconnected.
It was costing operational efficiency. Teams were being pulled into calls because information was owned by another system, another group, or another contact center.
It was also costing trust. When a customer gives information to a company and then has to repeat the same information to a person minutes later, the customer does not experience the company as one organization. They experience it as a collection of disconnected parts.
That became the argument for prioritizing the work.
This was not a cosmetic CRM improvement. It was not only a better card layout. It was a way to reduce service friction by changing how customer context moved through the operation.
That is where UX, operations, and business strategy came together.
Data Architecture as Operational Information Architecture
In many organizations, data architecture is treated as a technical concern. It belongs to systems, integrations, databases, and backend teams.
That is partly true, but it is incomplete.
In service design, data architecture also shapes the human experience. It determines what an associate can see, what a customer has to repeat, what the system can surface, and what decisions can be supported inside the workflow.
That is why I think of this phase as operational information architecture.
Traditional information architecture asks how information is organized, labeled, connected, and accessed inside a product. Operational information architecture asks how information moves through the business so people can do their work without unnecessary searching, waiting, repetition, or escalation.
For this CRM work, the information architecture problem was clear: customer context was not traveling well across the service operation.
The IVR could collect information. Other systems could hold information. Other teams could own information. However, the associate taking the call still needed the right information inside the CRM, in a form that made sense during a live conversation.
That required a different kind of design thinking.
The work had to consider the screen, but it also had to consider the data model behind the screen. It had to consider how customer information was grouped, prioritized, governed, and made available. It had to consider which information belonged in a fast associate-facing summary and which information should remain deeper in the system.
This is where information architecture became part of operations.
The structure of the customer record affected the quality of the service interaction.
The Unified Customer Record Strategy
The strategy was to move toward a more unified customer record.
A unified customer record does not mean every possible piece of customer data is dumped into one place. That would create a different problem. Associates do not need a warehouse. They need context.
The goal was to bring together key customer signals in a structured way so the CRM could support better service decisions.
That meant thinking about the customer record across multiple dimensions:
This kind of structure helps the system understand the customer beyond a flat profile.
A flat profile may answer, “Who is this customer?”
A multidimensional customer record can begin to answer better service questions:
What is happening with this customer right now?
What has the customer already told us?
What recent activity may affect this call?
What context does the associate need first?
What information should be visible immediately?
What information should be conditional, protected, or escalated?
Those are not just database questions. They are product design questions.
The customer record needed to become useful inside the workflow, not merely complete from a storage perspective.
From Customer Data to Customer Context
There is an important difference between customer data and customer context.
Customer data is the raw material. It may include account details, service notes, transactions, call reasons, purchase history, and operational status.
Customer context is what becomes useful when that data is organized around the associate’s task.
An associate does not need to see everything. They need to see what matters for the current service moment.
That distinction shaped the strategy.
The unified customer data work was not about creating a giant profile that exposed every field. It was about defining how different pieces of information could be organized into a customer context model.
That model could then support the CRM experience.
It could help determine which information belonged in a high-level summary. It could support the KnowMe Cards. It could help a future assistant like Homey understand what information to surface or suggest.
Without that structure, the interface would only be arranging fragments.
With that structure, the interface could become more intelligent.
Why This Mattered for KnowMe Cards
KnowMe Cards were the visible product pattern, but they depended on the data architecture underneath them.
The purpose of the KnowMe Cards was to surface important customer context inside the associate workflow. That required more than a card component. It required a reliable way to understand what information should appear in the card, where it came from, and why it mattered.
A card can only be useful if the system behind it knows what it is trying to communicate.
The KnowMe Cards needed to answer practical service questions:
Who is this customer?
Why are they calling?
What have they already told us?
What recent activity may affect the call?
What should the associate know before asking another question?
What information can reduce hold time, repetition, or unnecessary transfer?
The unified customer data strategy created the foundation for those answers.
It helped move the CRM from displaying isolated fields toward surfacing service-ready context.
That is the difference between a component and a pattern.
A component displays information. A pattern supports a workflow.
The KnowMe Cards became more than a UI element because they were connected to a broader information architecture strategy.
Why This Mattered for Homey
The same foundation would have mattered even more for Homey.
Homey was the proposed assistant layer that would live inside the CRM and support associates during service calls. The idea was that Homey could help pull forward relevant information, suggest context, and support the associate without forcing them to search disconnected systems.
However, an assistant can only be as useful as the information structure beneath it.
Without a unified customer data strategy, Homey would have been sitting on top of fragmented information. It might have looked intelligent, but it would not have had a reliable context model to work from.
That is a common risk in AI product design.
Teams want the assistant before they have done the information architecture. They want the conversational layer before they have defined what the system knows, what it should surface, what it should ignore, and what must remain under human control.
That path creates fragile AI experiences.
The better path is to build the information foundation first.
For Homey, that meant defining the customer context model before expecting the assistant to make helpful suggestions. It meant understanding which customer signals were useful, which were sensitive, which required permission, and which needed to be presented with caution.
In that sense, the unified customer data strategy was not separate from the assistant concept. It was what made the assistant concept possible.
Moving the Work into the Roadmap
Recognizing the problem was one part of the work. Getting it into the roadmap was another.
That required framing the solution in phases.
The first phase could not be a fully realized assistant. The organization needed a practical starting point that could show value sooner. KnowMe Cards became that starting point.
They gave the team a way to surface critical customer context directly inside the CRM. They also gave stakeholders something visible and concrete to understand. Instead of talking only about data models and operational information flow, the team could see how better information architecture would improve the associate experience.
That mattered.
Enterprise teams often need a bridge between strategic architecture and visible product value. The KnowMe Cards created that bridge.
The longer-term roadmap could then point toward Homey, the assistant layer that would use the same customer context foundation to provide more proactive support.
This phased approach made the work easier to prioritize.
Phase one addressed immediate service friction.
Phase two created a reusable customer context pattern.
Future phases could extend that pattern into assistant-ready workflows.
That is how the work moved from research finding to product strategy.
Outcome: From Local Pattern to Broader Adoption
The outcome was that the work moved beyond a single interface improvement.
After the initial phase of the KnowMe Cards was released, the unified customer data model gained broader organizational traction. The strategy was accepted as part of the direction for Home Depot Canada, which showed that the work was not only solving a local CRM usability problem. It was creating a reusable foundation for how customer context could be organized, surfaced, and applied across service workflows.
That mattered because the original research finding had been difficult to prioritize. The gap was operational, not cosmetic. Customer information existed, but it was fragmented across systems and did not consistently reach associates at the moment of service. By translating that gap into a phased roadmap, the work became easier for the business to understand, fund, and expand.
The KnowMe Cards gave stakeholders a visible first phase. The unified data strategy gave the organization a larger foundation. Together, they helped move the conversation from “this screen needs better information” to “our service operation needs a better customer context model.”
For me, that was the clearest evidence that the work had landed. The research finding became a product pattern. The product pattern became part of a broader data strategy. The data strategy then became useful beyond the original team.
Key Design Questions
This phase of work raised a set of questions that still feel relevant to AI product design today.
What information should follow the customer?
When a customer provides information in one part of the journey, such as the IVR, should that information travel into the associate experience? In many cases, the answer is yes. Otherwise, the customer experiences the organization as disconnected.
What information should appear first?
Not every data point deserves equal weight. The system needs a hierarchy. It needs to distinguish between background information and information that may change the next step in the service interaction.
What information should remain protected?
Unified data does not mean unrestricted data. The strategy still needs visibility rules, permissions, and responsible access boundaries. Associates should have the information they need to support the customer, but the system must also respect operational and privacy constraints.
What information is useful to a person versus an assistant?
A human associate may need a concise summary. An assistant may need structured signals, labels, relationships, and confidence boundaries. Designing for both requires careful information architecture.
What should the system do when information is incomplete?
A mature service system must handle gaps. It should not pretend to know what it does not know. It should help the associate understand what is missing and what to ask next.
These questions sit at the intersection of UX, data architecture, operations, and AI readiness.
Real-World Application
The unified customer data strategy explored how fragmented customer information could become more useful inside Salesforce-based CRM workflows.
The work focused on the relationship between customer data, service context, and associate decision-making.
It considered how the CRM could begin to support:
This was not data architecture for its own sake.
The work was tied to the service experience. The structure of the data had to support the reality of the call.
That is what made the strategy valuable. It connected backend information organization to frontline associate work.
Why the Strategy Mattered
The strategy mattered because the visible experience could not solve the problem alone.
A better card layout could help. A cleaner CRM screen could help. A future assistant could help. However, none of those solutions would work well if the underlying customer context remained fragmented.
The organization needed a way to make customer information more coherent, more usable, and more available at the point of service.
That is why the unified customer data strategy came before the more advanced assistant vision.
It created the path from fragmented systems to service-ready context.
It also clarified the difference between adding intelligence to a product and preparing a product to become intelligent.
Adding intelligence is the visible part. Preparing the product is the deeper work.
That preparation includes information architecture, data relationships, access rules, workflow mapping, component strategy, governance, stakeholder alignment, and roadmap influence.
It is less flashy than an assistant demo, but it is far more important.
Without it, the assistant is just a polite interface sitting on top of a mess. It may smile while giving the wrong answer, which is arguably worse.
Looking Ahead
As AI becomes more common inside enterprise products, unified information architecture will become even more important.
Design systems will not only need to define visual components. They will need to define how information behaves across workflows.
CRM systems will not only need to store customer data. They will need to surface customer context responsibly.
Assistants will not only need to respond to prompts. They will need structured, governed information environments that help them support real work without overreaching.
That means product teams will need to ask harder questions earlier:
Where does the information come from?
Who owns it?
How current is it?
Who should see it?
When should it appear?
How should it be summarized?
What should happen when sources conflict?
What should the assistant be allowed to infer?
What should always require human judgment?
These are not only technical questions. They are design questions. They shape the user experience as much as any screen or component.
The future of AI-supported product design will depend on teams that understand this connection.
The interface is only the surface. The information architecture underneath determines whether the product can actually support the work.
What This Means for Designers
Designers working in AI, CRM, service design, or enterprise systems will need to think beyond the screen.
The designer’s role will include understanding how information moves through the organization, where it gets blocked, where it gets repeated, and where it fails to reach the person who needs it.
That work includes:
This is not a smaller design role. It is a more strategic one.
The designer is not only arranging information after decisions have been made. The designer is helping define what information should matter in the first place.
That is especially important in enterprise environments, where systems often reflect organizational boundaries more than user needs.
If the business is siloed, the product often inherits those silos. If the data is fragmented, the user experience becomes fragmented. If the associate has to compensate for that fragmentation during a live customer call, the service experience suffers.
Designers can help make that visible.
They can show how operational structure becomes user friction. They can connect service pain back to information architecture. They can design patterns that help the organization move from disconnected data to usable customer context.
Conclusion
The unified customer data strategy was a foundational phase of the CRM roadmap.
It sat underneath the visible product patterns. KnowMe Cards surfaced customer context inside the associate workflow. Homey extended that vision into an assistant-like future state. The unified customer data strategy made both directions more credible because it addressed the deeper question: how should customer information be organized so the system can support service work intelligently?
That is the lesson I carry forward into AI product design.
AI readiness does not begin with a chatbot. It begins with information architecture, business framing, and operational clarity.
Before a product can surface the right context, it needs to understand what context means. Before an assistant can suggest the next best action, the system needs a reliable model of the customer, the workflow, the permissions, and the service moment. Before a company will prioritize the work, someone has to show why the gap matters to the business.
The strongest AI-supported experiences will not come from placing intelligent features on top of fragmented systems. They will come from designing the underlying information architecture that allows those features to be useful, responsible, and clear.
For me, this work began with a practical CRM problem: associates needed better customer context during live service calls.
The solution required more than a better screen. It required recognizing an operational gap, translating that gap into business value, and designing a strategy for turning walled-off data into service-ready customer context.
That is where the real foundation was built.
Topics