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 wouldve 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 Im 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 wont delve into the technology providers business or customer relationship strategies too deeply here, but lets 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 theyre in fact achieving those outcomes. Certainly I dont 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 theyre 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, its very often focused around things like data transfers, process steps, SLAs 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.
Its difficult to define and test an exhaustive set of conditions around intended outcomes simply because theres 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 organizations 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 its 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.