CVMBoK

Customer Value Management heavily relies on software and latest technology because of two requirements: scale and personalization. CVM operates at the level of millions of customers, necessitating efficient management of initiatives, campaigns, resulting data, and handling thousands of customer interactions per second. Customers expect interactions to be personalized, aware of their individual needs, circumstances, and demands. Consequently, CVM demands personalization at scale and utilizes advanced technology such as artificial intelligence, digital channels, and modular platforms.

CVM Technology Evolution

CVM requirements can be fulfilled by various architectures, and there is a vast diversity of approaches followed globally, both now and in the past. A short historical summary illustrates the key trends, pros and cons of different architectures.

The 3rd generation CVM architecture reflects the evolution towards a more capable and maintainable solution that addresses key recurring challenges in CVM. These common challenges include:

1. The number and variety of channels and touchpoints are rapidly increasing. Ten years ago, most companies relied on traditional channels like stores and call centers, supplemented by a few digital channels such as email and websites. Nowadays, mobile apps, IVR, USSD, social media, chatbots, and other digital channels have become mainstream, supplemented by assisted channels such as tele-sales, on-premises installation specialists. No single monolithic platform can fully cover all channels.
2. The amount and variety of customer data are rapidly increasing. Today, every single interaction with the customer is logged, stored and analyzed. Customer data often represents the largest data set in the business, creating significant data storage, manipulation, and integration requirements across various systems of record.
3. The ever-increasing need for personalization supported by AI/ML. Today, every customer interaction is ideally fully personalized with AI, resulting in a better customer experience, faster service, and higher conversion rates. Achieving full personalization requires a vast set of customer data records, thoroughly analyzed and enhanced with AI and ML algorithms.
4. The need to identify what works and what doesn’t drives significant requirements for A/B testing, comprehensive tracking, and reporting across the full tool stack. This introduces parallel CVM processes that share significant portion of logic, data, and AI/ML, while differing in minor details.
5. Operating seamlessly with existing legacy systems is crucial, as organizations navigate compromises related to these systems, large tools, and edge cases.
6. Agility, flexibility and speed are top priorities, as CVM managers cannot afford to wait 6, 12 or 18 months for platform transformations. By then, the market will have moved on, and opportunities will be lost.

Conceptual CVM Architecture Blueprint

A conceptual architecture can be defined that addresses the challenges.

Figure 5.1. Conceptual CVM Architecture Blueprint

Reference CVM Architecture Blueprint

This reference CVM Architecture Blueprint translates the conceptual schema in section “Conceptual CVM Architecture Blueprint” into a real-life architecture (see Figure 5.2.). For easier interpretation, it is presented in four colors, each corresponding to the four areas mentioned before: light blue for channels integration, light grey for data integration, dark green for central customer data & state hub, and light green for automated decisioning and business process capabilities.

Figure 5.2. CVM Architecture Blueprint

Below, the numbers from the figure are explained and defined:

1. ELT / ETL orchestration platform

Purpose: Handles the loading of data to/from the general enterprise data platform from a variety of source systems.

Comment: Normally, this goes together with the data platform and is owned by the BI/Data engineering team.

2. Data Platform

Purpose: Stores and provides raw and transformed data to a variety of use-cases across the company, including data needed by CVM.

Comment: The CVM stack upstream takes in the majority of data via data platform, reusing all its integrations with various data sources across the enterprise. The CVM stack can also export data back to the data platform for data points collected within the CVM stack.

Normally, the data platform is owned by the BI/Data engineering team.

3. Data Mart for CVM Reporting

Purpose: Provides transformed, reporting-ready datasets that integrate all campaigns, CVM activities, AI/ML model scores, channel logs, and other existing information like financials and costs into a coherent data model suitable for CVM reporting.

Comment: While it may be possible to have complete CVM reporting somewhere in the CVM tech stack, a much more efficient approach is to reuse the data platform to serve this need as it is used by the whole company. The CVM data mart can enable many stakeholders across the company to conduct self-service reporting about the CVM area. This reduces proliferation of separate mini data platforms and simplifies the BI landscape.

Normally, this is owned by the CVM team in the role of data stewards/ data product owners, but it can be implemented by teams outside CVM, for example, the BI team.

4. Visualization/Reporting Tool

Purpose: Provides generic data visualization, exploration and export capabilities for CVM reporting.

Comment: Reports about CVM activities are typically delivered via a generic reporting/dashboarding tool that itself does not store or prepare the data but only provides the ability to render it nicely and explore it easily. By using the same tool in the CVM area as elsewhere, the organization reduces tool proliferation and complexity of the BI landscape.

Normally, this platform is owned by the BI/Data engineering team.

5. Data Integration Layer

Purpose: Consolidating all input/output of data in a single data integration / API layer.

Comment: As the scope moves beyond BI/Data platforms, there is the option of adding this component, which brings improved observability, maintainability, and control across all data integrations. This is typically an API gateway for real-time requests and a batch file exchange gateway for files.

Normally, this is owned by the BI/Data engineering or DataOps team.

6. Customer Data Platform

Purpose: The Customer Data Platform is the core of the CVM architecture, serving as the central customer state and historical information hub for all other components, including campaign management, AI/ML, and business process integration.

Comment: It provides a central routing point where historical customer data, inferred/predicted data from AI/ML modules, and inputs to/from business processes are handled and made available to other parts of the architecture. By providing dedicated functionality designed to collect, store, process, integrate, and retrieve customer data, it reduces the complexity and cost needed to create, run and maintain cutting-edge CVM initiatives.

Normally, this is owned by the CVM team.

7. AI Models & Generative AI Solution

Purpose: Generative AI solution provide the capability to translate, process, summarize and generate text using large language models. The capability is used in campaigns, chatbot, and other channels as well as internally to process historical customer data.

Comment: Generative AI technology is rapidly becoming increasingly important in CVM due to its ability to generate highly contextualized and personalized responses. The GenAI solution wraps individual AI models into production-ready microservices and supports their lifecycle.

Normally, this is owned by the ML/AI or CVM team.

8. ML Models & MLOps Solution

Purpose: The ML/MLOps solution provides the capability to predict, classify, score, rank, and recommend, and supports the full development lifecycle of AI/ML models. This fulfils a number of crucial tasks for CVM needs, such as calculating a churn score or recommending a product.

Comment: The ML/MLOps solution wraps individual ML models into production-ready microservices and supports their lifecycle.

Normally, this is owned by the ML/AI or CVM team.

9. Campaign Management / Orchestration / Real-Time Decisioning Solution

Purpose: This element is known by many names, including campaign management, and fundamentally serves to integrate all channels that the organization needs to support.

Comment: This module consists of a central internal integration layer with additional microservices that integrate with every channel, old or new, bidirectionally or unidirectionally as needed, and brings them all under a single API, UX and conceptual framework. The campaign orchestration solution runs real-time decisions at the individual customer level, as well as batch model campaigns targeting various customer segments across all channels. It takes data from the Customer Data Platform rather than storing it internally, using AI/ML models and business process capabilities provided by other parts of the architecture.

Normally, this is owned by the CVM team.

10. Customer CRM View / Info Widget

Purpose: This is a small module that provides a consolidated data view to assisted channels that need to see detailed customer data, historical campaigns, and more.

Normally, this is owned by the CVM team.

11. Channel Integration Layer

Purpose: In the diverse world of multiple channels, there is the option of consolidating all input/output under a single channel integration/API layer, providing improved observability, maintainability and control across these integrations. This is typically an API gateway for real-time requests and a batch file exchange gateway for files.

Normally, this is owned by the CVM or Channel IT team.

12. Customer Facing Channels

Purpose: This includes a variety of channels that are either used by the customer in pull mode, such as self-service or mobile app, or in push mode, to send messages to the customer, such as emails, SMS, or mobile notifications. Some channels are interactive, like chatbots.

Comment: Each channel has a specific micro-service or sometimes a full IT system supporting it and providing the full capabilities of the channel.

Normally, this is owned by the Channel IT team.

13. Assisted Channels

Purpose: Assisted channels are those where the customer interacts with a human agent (supported by AI). Each channel has specific IT systems underlying it that provide the user interface to the agents and the rich capabilities of the channel.

Normally, this is owned by the Channel IT team.

14. Other Systems

Purpose: Several additional capabilities are often closely integrated with CVM architectures, namely the product catalogue, which provides a full list of all possible products and their attributes, and the order fulfillment system, which handles the physical or digital delivery of the product to the customer.

Normally, this is owned by the corresponding IT teams.

15-19. Business process specific systems

Purpose: Several other business process-specific systems are often integrated with the CVM stack.

Normally, this is owned by the corresponding IT teams or the CVM team.

Working with the Reference CVM Architecture

No organisation today starts with a blank slate for their CVM architecture. Many pieces are often already in place; some are fully adequate for the task, while others need to be replaced and modernized. By understanding the full CVM reference architecture and shaping the different modules into more sharply defined roles, improving loose coupling, and bringing coherence to the overall architecture by following a clear blueprint, organisations can dramatically improve their CVM technology capability without replacing everything. It is prudent to take this target architecture as a vision to work towards, identify which pieces are missing or not providing all desired capabilities, and then begin a series of transformation steps towards the target architecture.

A crucial element in this journey is strong internal leadership and ownership to ensure overall micro-service-oriented architectural integrity. It is too easy to fall prey to implementing things in the wrong place because many solutions in the market provide duplication of capabilities. For example, having a generative AI model embedded in an email management platform seems great initially, but what happens when the same model needs to be used in the chatbot? Or what happens when the assisted channel cannot access information about which segment the customer belongs to because it was sent only to the ML model?

Having such choices is great, but it is crucial to apply architectural discipline and implement a capability in the right place architecturally. This way, organizations gain rather than lose agility and flexibility in their CVM technology stack over time.

Previous: Where to Start?

Next: Cross-Functional Collaboration In CVM