Customer Journey Mapping: An Illustrated View

Written by Guest Blogger, Kelly Sewczwicz, Process Manager at Cox Communications. Part 2 of her latest blog series.

In my last article, part 1 of this series, I spoke about the recent initiatives we are undergoing to understand our process from the lens of the Customer. (You can read more about that here) To do this we have begun creating and defining our Customer Journey.  But this was just the beginning. It was also imperative to understand how our customers journey interacted with our internal processes and systems. I concluded with a desire to relate this to our current iGrafx ecosystem* and our process framework. In this article, we will explore that.

At the center of the ecosystem is a business process framework where we describe our business processes in a common language across the enterprise. Our process framework is called the World on a Page (WoAP) and it was created by combining elements from the eTOM/Frameworx and ITIL frameworks.

Each process we create contains information that may include: resources, external agents, IT architecture, performance indicators, risks (pain points), requirements, work products, and custom properties.  If the process is the center, it would look like this:

Let’s talk about each of these elements in more detail.

• Resources – A common set of roles that perform the process. We can also use resources to describe the channels where the work is performed or names of journey owners that are accountable for the process.
• External Agents – Capture our resources that are outside of Cox that include our customers, vendors, suppliers, and competitors that may play roles in our processes. 
• IT Architecture – Identifies what applications, servers, hardware, equipment and tools that we need to use in a process to get work done.
• Risk (Pain Point) – Risks are used to track our pain points of a process, along with information like the likelihood/impact of the pain point happening.
• Requirements – Requirements allow us to add requirements needed to implement proposed process changes.
• Custom Properties – Fields we have created that allow us to capture needed information that was not part of one of the other elements.  Some examples that we plan on capturing include process maturity and disaster recovery information. 
• Diagram – A visual representation of the process. 
• Work Product – Describe physical things, information or data that is exchanged between external agents and steps in the process. For example, a work product is a customer confirmation, a door tag left explaining that maintenance work is needed, or a customer notification sent as a reminder for an upcoming appointment.
• Performance Indicators – Defined measurements identifying if our process is functioning successfully. 

A process can be decomposed into lower levels of detail and all of these elements can be added at each level of detail. By connecting these elements, we can now create reports on the process and its relationships to those other elements. Additionally, since a process can be linked to other processes, we can also walk the relationships between processes and discover all the elements of each process. 

By having this information, we can connect our process framework to our customer moment architecture framework and easily navigate between the customer moments and the supporting processes that deliver those moments. 

*When we are talking about the iGrafx ecosystem we are talking about the processes in the process framework, the elements we associate to a process, and how a process is linked to the customer moment architecture.