<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

Creating Value in Customer Experience Management

CXM-process-perspective.png

An organisation should be looking for ways to continually add value.At it's core Customer Experience Management understands what is of value for a customer, and how we create/deliver value, that will lead to actions that result in a good customer experience.

Value, in simple terms, is when the business offering meets the customer needs.

Defining ‘value’

Value is usefulness; value is utility; value is a problem solved. Value feels good.

Organisations constantly try to add value for their customers. In the past, there has been a siloed approach to adding this value. Each department put in an effort and attempted to give their best, only to find out that individual best does not necessarily lead to a holistic best, as sometimes the department’s direction is in conflict with others. A customer gets a good product and service when all the participants attempt to make the interaction value-added for the customer (not just the customer facing).

You may think that there is nothing new in this, and this is what people have always attempted. Every process-design effort undertaken in organisations has tried to achieve exactly that.

The key difference is that here we don’t need a stakeholder priority matrix to identify who to impress and who not to. The stakeholder is pre-identified—it’s the customer. The moment we say that every participant in the process is a customer, we are losing focus.

Here is where ‘product/service view’ comes into play. The following section is an attempt to reconcile the process and product/service views, and how that approach helps shift the focus from internal process participants to the customer.

Reconciling product/service, process and experience

Dr Michael Roseman, in his article Process management as service (2010), gave a very good description of process and service:

Process’ and ‘Service’ are complementary views on the same capability of an organization. As two distinct ‘sensitizing devices’, however, their associated viewpoints stress alternative facets of organizational capabilities. A process view sharpens the understanding for the operational model of a capability. It provides the required analytical foundation to reflect on the current and potential future performance of a capability as far as this performance can be impacted by the way it is delivered. As such, a process view can be seen as an approach to ‘white box a corporate capability’.

In contrast, a service-oriented (external) view on a corporate capability can be regarded as a ‘black box’ perspective. The emphasis is, as described above, on the conscious abstraction of the internal operations of this capability. Instead, the focus is on the overall value proposition (what can the service provide?), the related costs, the underlying governance model (‘what happens when the service fails, i.e., service continue management’), and further non-functional service properties as part of a service level agreement (response time, quality standards, etc.).

It is important to have a service (and/or product) view, because that is what the customer is ultimately consuming; the processes remain the mechanisms to deliver the service (and/or product).

For example: In a salon, the haircut is a service: take a ticket, wait, get a haircut and then pay for the haircut (make payment) is the process. The combination of a quick cut, easy payment and a nice hairstyling that gets you positive attention by your friends is good customer experience.

Product/Service is about benefits.

Process is about the mechanism to deliver a product/service. Experience is about the overall feeling that the customer has about the interaction.

Framework

Considering a customer as a single entity in a process design implies that all customers can be treated in exactly the same way. However, representing all customers in a similar manner oversimplifies and generalises the needs of the specific categories of customers. Customers with similar needs can be categorised together, and processes can be designed to cater for these different categories. These customer categories with similar needs can be called ‘persona’.

The following diagram depicts the perspective of aligning customer needs with the business offerings.

CXM-Value_Creation.png

Figure 1: Value creation and delivery approach

This diagram has two sections. The top section is where an individual customer is considered from the point of view of his/her needs. Patterns are matched and customer personas are generated, and these represent a group of customers with similar needs. These needs of the various personas are the needs that, when satisfied, creates value.

The other perspective is the organisation view, where the business goals are delivered through execution of business processes. Business processes produce outcome; they deliver products and services while catering to the needs of the customers represented by the personas. The value zone represents the interface where needs are fulfilled, and the customer gets a good overall experience.

We are aligning what the business has to offer with what the customer needs. Needs that have two components: the stated needs, and the unstated needs. Good customer experience is the combined effect of fulfilling both needs.

CXM-Components_of_CXM.png

Figure 2: Components of customer experience

To ensure the end user is in focus, we need to take a product/service view as well a process view. A product/service view ensures that the end-user needs are in focus, and a process view acknowledges that the outcome is a combined effect of multiple activities that span across the individual organisation entities.

Download Customer Experience Management Paper

Related Posts

The Ultimate Guide to Process Modelling

A new day, a new process modelling project. The project plan has been signed off, reference documentation was gathered, all stakeholders have been identified and now…now what? While process models increase in popularity and most businesses seem to agree that process models are indeed a good way of representing how an organisation creates and delivers value, there is little to no guidance on what a good process model is, how to create one and how to successfully go about executing a process modelling project. While this guide does not claim to be a silver bullet for all your process modelling problems (look at our Modelling Excellence framework for that!), it aims to be a guide for Project Managers and BPM Professionals in every stage of the modelling journey, regardless of whether you’re just kicking off a new modelling project, are in the middle of a major project, or are just looking for a refresh. Please note that this guide does not address steps to set up or configure a process modelling tool. It is focused on the activity of process modelling.   Let’s get started! This section includes topics that should be covered prior to kicking off any process modelling project. If a project is already underway, but struggling, we recommend revisiting this section to ensure the basics have been covered. If your project is already underway and going well, you may opt to skip ahead to the “Business Process Modelling” section. It’s all about the purpose… Firstly, ensure the purpose for modelling has been identified and agreed upon by all stakeholders. Whether it is communication, training, process measurement, improvement or configuration of a workflow tool, any modelling effort must serve a purpose. Major decisions such as “What modelling tool is the right one?” as well as minor decisions such as “Should I include this detail in my model?” can easily, logically and consistently be answered once the purpose has been identified. Consequently, if a clear purpose for modelling cannot be identified, no time and money should be spent on modelling as the models would end up being waste. The start of a process modelling project is also a good time to identify additional use cases for process models and pitch those to the stakeholders. The more use cases there are, the more robust the business case for process modelling becomes. Models that are re-used often are valuable to the organisation, rather than just useful for a one-off project. This does not mean that creating models for one-off use is waste. Although we generally recommend maintaining and re-using process models as much as possible, there are many valid use cases for and circumstances under which organisations choose to create process models that will be deleted once the project is completed. We do however emphasise that this purpose needs to be clearly identified and agreed upon, so nobody comes looking for the model two years later and needs to then kick off another modelling project since the former models are either out-of-date or nowhere to be found. Understanding the purpose of modelling will also help Modellers in the information elicitation and model validation stages of the project. They must always be prepared to explain what they are doing, why they are doing it and how it benefits the organisation. A strong pitch for modelling, tied back to the purpose, will help to keep stakeholders focused during workshops.

Moving From Continuous Improvement to Continuous Process Management

  Continuous process improvement is a common organizational aspiration, and it is one of the most difficult things an organization can attempt. The continuous aspect is quite a challenge, as is realizing business performance improvements—especially once the easy and obvious changes have been made. Organizations need an ‘internal improvement engine’ that replaces insistence with evidence.

Process Architecture vs the Organisation Chart

  In my working life I spend a lot of time working with client organizations to discover and capture useful models of their process architecture. In every country, industry sector, organization type and size, there is a common problem that bedevils every project. We all, and I include myself here, can too easily slip into the habit of the last 100 years (or you might argue 1,000 years) of visualizing the organization as its organization chart. Comments such as “What about the work they do in department X?” might just be a useful test for a developing process architecture, or they might indicate a lack of understanding of what the architecture represents.