Design versus Discovery: Following the Data, Whereever it Leads
Wednesday, July 21, 2010 at 01:48PM As we all know, contact centers are among the most complex systems that any enterprise must manage. The mix of technology, people, often conflicting goals, complex organizational relationships, and even channels of communications pushes each of us to our limits. So much is going on in the modern contact center, especially those that service many types of customer needs, that it is very difficult to get a grasp on what is really happening. The need to do so is pressing, and many technology solutions are being proposed in an ongoing flood of innovative solutions to the "business intelligence" problem.
As is often the case when things are so demanding that we do our best just to keep our heads above water, there are some common implicit assumptions that tend to push us back down under, struggling for each breath. One of these is the implied notion that the right way to understand what is really going with center performance is to ask structured questions that are driven by the design of the center. This is so deeply embedded a notion that it probably does not even make sense on first reading (of course, that could also be due to my writing!). It seems self-evident – of COURSE we would want to ask structured questions to measure whether our design is achieving what we intended. But it turns out that self-evident, common knowledge can often lead us astray, and this is one example. In fact, there are many important questions we should like to ask about our contact centers but typically don't.
To clearly see why this is so, consider call flows. In most contact centers, considerable time is spent designing call flows to handle all the differing customer needs in an efficient fashion. Often very large call flow diagrams are developed, and then these designs are coded/configured into routing strategies, ACD vectors, voice/IVR applications and so forth. Many a contact center war room has walls festooned with detailed call flow diagrams... Then, in order to measure performance, detailed reports are designed that measure the performance of each of the call flows. These reports are built up from very structured data that enables the counting of calls that took each flow, as well as the time spent in each leg of the flow (and often the business outcome from the call).
So far, so good. But, this approach does not measure things that you did not plan for, except when we are lucky. Unfortunately, unplanned flows are commonplace in contact centers – how it could it be otherwise? Customers do not care, and should not have to care, how we define our call flows. They do what they want to do, and the more freedom we give them, the more they will like the experience we provide. The situation is even worse on web sites, where users are quite proficient in using navigation tools (back keys, favorites, history lists, etc.) to traverse web sites as they see fit.
These realities call for a different, complementary approach to analytics. This approach is based on discovering and measuring all of the patterns that occur, rather than measuring only the patterns that are designed in. In web terms, this means studying the paths people actually take as they traverse our web site, rather than analyzing the paths we designed in. This is somewhat familiar in the web world, but it is far less so in the "call flow" world. But the difference in results can be startling. In one real world contact center where I did some consulting, there were two dozen call flows set up. Reports were set up for each of them, and these were reviewed by many people. But, when I asked the question "What are all the call flows that actually occurred, regardless of whether you designed them in, and how often did each occur?", no one could answer it.
In fact, new tools and a new approach were needed to discover all the flows that occurred. Again, for emphasis, this is quite distinct from measuring all of the flows that were designed. In the real world contact center situation, there were over 500 distinct call flows that actually occurred. Not surprisingly, most of the calls were accounted for by counting the most-used flows (the 80/20 rule held, more or less). However, one of the top ten flows was a completely undesigned – and unmeasured – one. A very meaningful fraction of callers to this company were ending up in the "Hotel California" queue -- you could check out any time (by abandoning), but you could never leave (that is, get an agent)! Because the reporting was designed around planned flows, this unplanned flow remained undetected, and these customers remained unserved (if they remained customers or not could not be detected...).
A similar situation likely exists with agent work patterns. Many centers rely heavily on hard scripting or rigid rules about how to handle calls, and these centers usually also maintain significant investments in highly structured reporting to measure compliance with these designed work patterns. Analyzing performance using only these "as designed" reports is doomed to miss many important features of agent work patterns. Some of these might be bad ones – ways that agents might mistakenly or otherwise fail to accomplish what is desired – but many will also likely be good patterns that will not be detected and amplified (by teaching them to other agents). We too often rely on chance to detect these unplanned flows -- someone following up on a complaint (or a kudo) discovers that things are not, after all, going as planned.
The good news? There are techniques for performing unstructured data analysis. Many techniques are well-established today, and we are adding some new ones right now at Aria, in our Strategic Consulting Group (ping me and we can discuss them!).
But even without these cool tools, it is all about attitude and the approach to data: business analysts should approach their task, and their data, in the spirit of discovery and not in a legalistic search for compliance and deviations.


Reader Comments (1)
your site is very good I really like your site