BPO Only Works if You Pay Attention to It

By Mark Cioni

(Back to article)

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:

  • A customer, me, purchases computing equipment from a technology supplier.
  • The technology supplier fails to apply the customer’s payment correctly and believes the customer is delinquent, referring the customer to their outsourced collections department.
  • The customer, me, tries to resolve this mess via the technology supplier’s preferred business contact channel, itself outsourced to a provider different than the collections department.
  • The customer, me, spends over four hours resolving the problem … hilarity does not ensue.

    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:

  • Customer Perspective – Minimize time to confirm payment and close collection activity.
  • Technology Supplier – Confirmation of full customer payment; satisfied customer.
  • Contact Center BPO Provider – Minimize call resolution and total call time.
  • Collections BPO Provider – Minimize payment collection time.

    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.

  • It’s important to remember that the functionality and workflow inherent in the process is subordinate to the intended outcomes. In other words, if the organization and BPO provider execute the process, but the intended outcome isn’t reached, then that’s not success and it’s time to look at how the process needs to change. As we’ve seen, often the required changes consist of better integration.

    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. Let’s be clear, it’s 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, that’s 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 organization’s best customers tend to go out of their way to voice their opinions about the products and services they’ve 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 they’ve 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 couldn’t 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 they’re serious about intended outcomes?

    Here’s 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 hotel’s 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 hotel’s brands, and double my rewards points for my stay. The organization’s 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.

    That’s 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 mark@mvcioni.com.