How to Tie the Customer Journey to your Process Framework
Written by Guest Blogger, Kelly Sewczwicz, Process Manager at Cox Communications.
Most BPM experts seem to agree that there is the need to merge together the work of customer experience and process improvement teams. Last year I had the opportunity to tag along on a customer journey mapping project to understand how they built the journey and related deliverables. My goal was to figure out how our BPM tool, iGrafx, could be leveraged to tie together customer journeys and processes in our process framework. Would there be value in adding this information? How exactly should the details be related together?
The first thing that the team created was a service blueprint which is a process flow from the customer’s perspective. This tool was first created in 1984 by G. Lynn Shostack. This diagram describes the front stage or visible actions to the customer and the back stage or invisible actions to the customer, along with the supporting processes and tools for one path through the process. Think of a service blueprint as the table of contents of the people, process, and technology to achieve a specific customer outcome. This document was created in one session with subject matter experts from across the organization using colored sticky notes and butcher-block paper. At the end of the day, we reviewed the document with our executives. This document highlighted how different well-meaning organizations were negatively impacting our customers.
Next, we created the service blueprint in iGrafx using very simplistic shapes. We also added a row at the top of the service blueprint to capture existing projects that were addressing certain steps or data that we had collected. For example, we had NPS scores to explain which parts of the process were the most challenging for customers. We also added a row at the bottom of the service blueprint to describe the operational processes that supported the steps and extended the box to show how the steps aligned to the blueprint. This blueprint is very useful because every time a new person was added to the team, we had one place to show them to ground them in our customer journey.
When it came time to develop the desired state customer journey, we created a customer moment architecture. This diagram attempted to overcome several limitations of the service blueprint. The service blueprint represented one customer’s path through the process and most processes have multiple channels for how to serve that customer and have multiple ways to fulfill the service to the customer. We wanted to create one view of the different moments a customer can experience and describe how each channel would support those moments. In our project, we heard that customers were frustrated because the experience was very different depending on which channel they chose to interact with us. We wanted to define the moments to be the same regardless how our customers choose to interact with us.
We also realized that some of the moments we were defining could be reused from one customer journey to another, so we needed to make sure that we could understand all the places a moment could be used. This is where the power of a tool like iGrafx really helps. Every customer moment was setup to be an enterprise process object and the swimlanes of the models represent the different channels where a customer can experience the moment. We created custom shapes for the moments to make it clear that it was not a process map. Off the moments we added work products to describe the customer interaction that we wanted to take place or mock-ups of what the digital experience might look like. We had tested some of these mockups and customer interactions with customers to fine tune the ideas.
Next, we mapped the customer moments to our underlying process framework. iGrafx provides us the ability to say that for any given moment, these are the processes that support it. This allows us to talk in two different languages (experience or process) and we don’t have to worry are we talking past each other. The ability to connect two frameworks together allows us then to walk the relationships. Now I can understand how a moment is supported by what processes, roles, applications, and policies/rules. As soon as I saw this, I immediately began thinking all the other things that we could connect together to build an ecosystem to support customer experience, process improvement, technology, and operations. In the next segment, I will talk about adding on the next set of objects and the added power it brings.