Are Your Processes Ready for a Customer Experience Initiative?

A Guest Post by Esteban Kolsky, industry influencer (pictured left)

The great experiment continues. We are exploring and establishing the right questions to ask when undertaking a customer experience initiative.

So far we have discussed who owns the customer experience and the cultural (people) aspects of deploying a customer experience initiative. In this third post I’m going to talk about processes. (This sponsored research investigation into customer experience is brought to you via my good friends at Oracle.)

The format of this exercise is to pose four questions around the topics of people, process, and technology and explore the implications of each question. The questions, and more importantly your answers, should give you sufficient information to launch your customer experience initiative—or at least to build a framework towards it.

First, are your processes well documented?

I have very interesting discussions with clients when I ask this question. Of course, the initial answer is always yes—followed by something like “we spent x amount of time doing a BPO project and it is all documented.” My follow up question is always—are your processes updated? Most organizations fail to implement some sort of technology or workflow that will allow them to continuously update the documentation (or in some cases, even find the documentation after the initial project). Any minor change—a compliance requirement, a change in organization hierarchies, a departure of a staff member in some cases—can change the process. Even if the changes are slight, they can accumulate over time and translate into large changes.

Action Items: 1) Ensure that documentation exists and can be easily found, 2) Keep the documentation updated, and 3) Make sure the process changes you make can be introduced into the existing documentation.

Second, do you have flexible processes?

Most everyone believes their processes are flexible. After all, nearly all processes have been modified numerous times since their inception—and that clearly denotes their flexibility—right? Yes, to a certain extent. However, a large number of processes are inflexible because of their dependency with a specific person, channel, location, or even a system or solution (called external dependencies). This is not about dependencies between processes (I cover that below). This is about processes that have external dependencies and no inter-process dependencies. In reality, not having interaction with other processes is what makes a process less flexible, because some of the work and information is likely (or at least possibly) going to be repeated across different processes. Therefore, having rigid processes that cannot be replaced or integrated with new processes can create major problems.

Action Item: First, understand the dependencies between processes and external factors, such as people, solutions, and technologies—anything that is not a process. Second, find a way to replace the dependency with one that is more sensible. Then the process can be flexible enough to be extended or modified.

Third, do you understand the dependencies between processes?

There is no process that exists by itself, independent of anything else. As a matter of fact, the entire concept of creating and building processes exists because of their interdependencies—to ensure that the actions executed by those processes are leveraged in one part of the organization and then generate a result in another part of the organization. The question to ask is: are the dependencies between processes well documented so if (more likely, when) you make a change to a process, you know what other processes are affected and can quickly implement necessary changes?

Action Item: Ensure the interdependencies between projects are documented and that the documentation processes can accommodate new and different relationships between them.

Fourth, do you have processes for changing processes?

This might seem like a redundant question to ask; however, it is actually one of the most important aspects of changing processes—and all due to a single reason. When you change a process once, you will need to change it again. The benefits from a single change compound over time as more changes are made (from single adjustments to entire end-to-end reengineering). This is why you need to make sure you have a process in place to make the changes: nothing is once-and-done when it comes to processes. Furthermore, changes done for the purpose of customer experience are always going to have a shorter life than any other change, mainly because the customers’ needs and wants will change constantly. Other variables, such as channels, resolutions, or compliance, also will change, and there is going to be a need to revamp them often.

Action Item: If you don’t have a process for changing processes, that should be your first stop in the adoption of customer experience.

These are the basic questions you will need to ask yourself to undertake the process changes necessary to adopt a customer experience initiative. Of course, the project becomes more complex when you weave these answers with your answers from the previous post (changes in culture to deliver better customer experiences). And that needs to be done before you undertake the final set of questions (coming in the next post) on technology use for customer experience.

Until then, I would love to hear from you. Are these questions representative of the changes in process that you have experienced when undertaking a customer experience initiative? Is your experience different? What am I missing?

Note: You can respond via my blog or scroll down and post a comment.

Post a Comment:
  • HTML Syntax: NOT allowed

Features Oracle executives responsible for the Oracle Applications strategy in the market. Stay in touch with Oracle announcements, updates, recommendations and key trends.

Connect With Us


« April 2014