The CX Business Blueprint

As you saw from the article “How CX Management Works,” the central working document is the CX Business Blueprint.

Some in-house CX teams tend to do this exercise alone, but we should always create cross-functional teams for this workstream. Why? Firstly, no matter how true and accurate a document like this is, unless people are involved in generating the content, they will not take ownership or notice of it. Secondly, the discussion and debate around the blueprint’s content provides valuable learnings in itself. Thirdly, the same teams will need to be involved in solving problems, so it’s best to involve them as early in the process as possible.

The components of the CX Business Blueprint are as follows:

1-Customer Experience: this part of the map is a traditional experience map, for which there are countless guides and formats. The goal here is to capture the customer’s end-to-end experience with the firm. The process should involve customer interviews and any voice of the customer (VoC) insights the team can acquire from the business units.

The most important principle of experience maps is that they cover the experience from the customer’s point of view. I’m always surprised by the number of experience maps or customer journeys that end up reflecting a company’s own processes or priorities (“acquire”, “upsell”). Customer experience maps need to show empathy for the person whom the firm is interacting with. The map should describe the customer’s “thinking-feeling-doing” throughout the relationship. Insights from Voice of the Customer, Voice of the Business, and Voice of the Process (KPIs) should provide hypotheses of Problems and Opportunities to address.

The other principle which is important, and sometimes complicated, is the idea of the persona. Many marketing teams use personas to represent potential targets to sell to, developing specific messaging for the same product or service. Experience designers use personas to describe different user needs and behaviours that may drive design teams to define specific solutions for them. This article from UX Booth describes Alan Cooper’s view of marketing, proto and design personas.

Each persona should have its own CX Business Blueprint, or at least all be represented on the same blueprint (although that becomes visually very complex and harder to use).

2- Teams: in order to facilitate creation of cross-functional project teams, and change management in a longer phase, CX leaders should document which teams are involved in each step of the experience. I recommend using the RASCI model to describe each team or person’s role.

• R – Responsible – who is responsible for carrying out the entrusted task?
• A – Accountable (also Approver) – who is responsible for the whole task and who is responsible for what has been done?
• S – Support – who provides support during the implementation of the activity / process / service?
• C – Consulted – who can provide valuable advice or consultation for the task?
• I – Informed – who should be informed about the task progress or the decisions in the task?

I’ve found a few things applying this model:

• People often don’t agree on who is Responsible for a certain task;
• People often forget to Inform other teams, leading to communication breakdowns and a broken experience for the customer;
• People forget that other teams can be Consulted on a customer task, leading to a missed opportunity to create value in an interaction.

The goal for this exercise is to formally document who does what, and call out gaps where a team interaction or process is not currently happening.

3- Business processes: this is a tricky part of the map. As we are working at an experience map level, the processes should stay high level to allow a deeper dive in step four. The point at this stage is to be able to quickly identify where to look for gaps or opportunities inside the business.

For example, if a customer currently has to wait three days after onboarding to access a service, all we need to know at this phase is that onboarding, access management, customer communications are all implicated. Once we turn that problem into a project, then we may learn that the delay comes from internal approval workflows or too many CRM tasks overwhelming the account manager.

So keep in mind the CX Business Blueprint view should serve only as a dashboard, indicating where an experience is suboptimal, and not the basis for new experience design, which happens in the next phase.

4- Datasets Used: here we want to help identify what type of data is used so we know what to work with. Typically in CRM applications data is either related to customer records (unique ID, assigned marketing segment, etc.), product information (SKU number, description, image), or usage data (login records, browsing patterns, product usage statistics etc.). Again, at this phase the intent is to map out where certain types of data are used, by whom, and by which systems (see 5-Supporting Technology).

Moving foward, the ultimate goal is to work out where connections could be made to create a holistic view of the customer, and which teams should own the data in the overall governance.

5- Supporting Technology: similar to the 4-Business Processes, the intent here is to identify key platforms to either call out gaps (e.g. we currently have no specific Search capabilities), or overlaps that might merit de-duplication (e.g. both X and Y systems do campaign management…do we really need both?).

As the list can get ridiculously long, it’s best to stick to documenting applications or platforms that have a major impact on the experience you’re addressing.

6- Metrics: there are two types of metrics to document here. As a baseline, we capture Key Performance Indicators (KPIs) that the business is already actively measuring (time to resolution, campaign ROI, etc.). However, it’s also good at this point to capture blind spots in the business where no consistent measurements occur (customer satisfaction, quick value ratings, other VoC or success metrics). Try to think about whether you need to measure efficiency, effectiveness, or both.

Missing metrics will drive a discussion about all the previous points. How do we know an experience is good/bad? Who should be responsible for measuring X? How do we measure it? What data should be captured? Using what tools?

Old but true: you can’t manage what you can’t measure.

TO CONCLUDE:

This workstream will probably require a few sessions with various stakeholders in order to come up with a relatively complete view. The important thing to remember is that this is merely a dashboard and delivers no value of itself.

Most of the business value comes through using the blueprint to know where to invest in improving the customer’s existing experience and design, and where to invest in delivering innovative new experiences.

The flip side: when used well and complete with business metrics, the blueprint is also interesting to what to prioritize, and what not to invest in (right now).