BPO Only Works if You Pay Attention to Itarticle 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 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.
By exits, I mean the equivalent of getting out of the mainstream of the defined process and being able to address an exception directly. In my case, the fact that I called more than once about the same issue should have been an indication that the process, or its execution, was not producing intended outcomes. Lets be clear, its preferable to follow an established process when it makes sense, but when exceptions occur the process needs to be resilient enough to handle them, and if too many exceptions occur, thats probably an indication of a larger issue.
The takeaway for organizations and BPO providers is to mutually define how intended outcomes can be tested and then to do so. That means actually poking at the process by simulating not only expected usage but whether the process is resilient enough to handle the unexpected and still achieve intended outcomes.
Measure The Results I know that the concept of intended outcomes is relatively new to the realm of BPO. Yet one of the best ways to measure intended outcomes, that being direct customer feedback, has been around for a long time. An organizations best customers tend to go out of their way to voice their opinions about the products and services theyve received. Even sporadic and one-time customers can surface valuable insights about how to improve. All the organization needs to do is listen and ensure that the customer knows theyve been heard.
I spoke in my last column about the irony of getting customer satisfaction surveys from the technology supplier, contact center and collections function as result of my buying experience. The irony is derived from these surveys because they contained information that had to be shared between all three entities, yet they couldnt share any information that would have helped solve the problem.
Undaunted, I returned all the surveys along with detailed accounts of what happened and suggestions on how to fix the problems I perceived to exist. Guess what kind of response I got? Nothing, nada, null, zip. For one of them, not even an indication the message got through. Would you feel like theyre serious about intended outcomes?
Heres another scenario I encountered recently: On vacation with my family, we stayed in the mid-scale brand of a relatively well-known hotel chain. My kids were looking forward to using the pool, and when I confirmed my reservation at the front desk no one mentioned any issues, but when we arrived I found it was being renovated. Although annoying, we found other activities to placate the kids and avert a riot.
I provided feedback about this on the hotels Web site and waited. Less than 24 hours later, I had an apology from the property manager and her supervisor, a voucher to apply toward a future stay in any other property within the hotels brands, and double my rewards points for my stay. The organizations contact center is outsourced, yet their process and information integration enabled them to address the issue efficiently and effectively. I even received an email thanking me for helping to make the organization better, and asking whether I was satisfied.
Thats what I call serious.
Mark Cioni, president of MV Cioni Associates, has been helping global businesses to improve their decisions, operations and performance for over 25 years. He can be reached at firstname.lastname@example.org.