In my October 2007 article I described a personal experience of how an integration failure between an organization and its BPO providers created a negative customer experience. In this article, I want to talk about some key steps that would have enabled a better experience. In short:
Apart from eliminating the internal accounting issues on the part of the technology supplier, I asserted that better integration between that organization and its BPO partners would’ve helped to mitigate the consequences of that failure. As I encountered numerous other shortcomings wading through the morass of disconnected processes and data, I decided to look at the next level of detail about how this situation could have been handled better:
Define Intended Outcomes – An intended outcome is the desired end-state of any interaction, together with the boundary parameters for achieving that end state. In other words, an intended outcome has dimensions of what, why, and, at least a high level notion, of how. Seems easy enough, but I’m still amazed at how often these dimensions are either not defined or are confused with the intermediate steps intended to produce the outcome.
Intended outcomes, for the purposes of BPO, have at minimum three distinct perspectives as held by the customer, the organization that “owns” that customer, and the BPO provider. When these perspectives are not aligned, problems occur. I won’t delve into the technology provider’s business or customer relationship strategies too deeply here, but let’s assume that in my case the respective views of intended outcomes were as follows:
How can I make these assumptions? Well, spending over four hours to resolve my issue with the technology supplier and its BPO providers is a pretty good indication that their views of intended outcomes were not aligned. If they were, one or more of these entities would have been able to step outside the bounds of their process silos and perform on-the-fly integration in order to solve my problem. Unfortunately, that task fell onto my shoulders.
The key for organizations and their BPO providers is to established a congruent model of intended outcomes at the outset, and then test and measure whether they’re in fact achieving those outcomes. Certainly I don’t mean to minimize the importance of minimizing call resolution or payment collection times, but achieving those goals at the expense of intended outcomes, and quite possibly customer loyalty, is a pyrrhic victory. This lesson has been taught frequently in the world of business, and the increasing leverage of BPO by organizations in many ways adds more complexity with several entities in the mix.
Incidentally, I believe this is an area where BPO providers can establish clear differentiation by guiding their clients through establishing, testing and measuring intended outcomes. If they’re successful, the client organizations might even consider charging a premium for a better grade of service … but being successful is the key. In my case, I paid a premium for better support and got the privilege of solving a BPO integration problem for my technology supplier, leaving me wishing for an optically-inserted spike to ease the pain.
Take The Test – When testing occurs in a BPO relationship, it’s very often focused around things like data transfers, process steps, SLA’s and the like. These are all very important and must be tested. What gets very little testing, as you might guess, are intended outcomes. Assuming an organization buys into the importance of defining intended outcomes, then testing them is just as important.
It’s difficult to define and test an exhaustive set of conditions around intended outcomes simply because there’s too many potential paths to the destination. An alternative, assuming the business process model is based on a foundation of best practices and tailored to an organization’s particular business goals, is that the process include instrumentation and exits for resilience.
By instrumentation, I mean the equivalent of “sensors” at various points in the BPO infrastructure where it’s logical to test whether the process is achieving the intended outcomes. A “sensor” can be many things, but in general it consists of automated and/or manual mechanisms to gather data that indicates progress toward intended outcomes.