Knowledge: Bashful Partner or Leader of the Dance?

Stanley E. Malcolm, Ph.D.

This article was published in slightly different form in Performance Improvement August 1999, pp. 20-22. Click here to download PowerPoint slides of my Performance Support '99 Conference presentation on this same topic (106k).

Abstract

This is the story of a recent project to support several customer service call centers that were being merged into one. Simultaneously, Customer Service Representatives (CSRs) were being asked to support a broader range of calls (i.e., various service plans, each with slightly different terms and conditions). As a case study, the project's evolution raises some issues critical to achieving the full potential of knowledge management in support of business performance.

Introduction

Surely you remember the old story of the city slicker in the fancy car who stops by the country store to ask directions. The weather-beaten locals confer among themselves as to the best route, rejecting several alternatives before concluding that "You can't get there from here." While I don't share this fatalistic view of the prospects for thoroughly integrating business knowledge and workflow into systems, the case I'm about to describe raises some important barriers that may make the destination seem almost unattainable. In fact, you may end up reaching some other destination, similar but not exactly the one you had in mind.

In order to preserve client confidentiality, I cannot share the name of the company described below, nor the specifics of the business they're in. Those details are not important anyway: it could be almost any company in any business. In fact, it could be your company!

A Brief Project History

I was called in by the training department manager. He was convinced that traditional training approaches would not succeed in the change initiative his organization was about to undergo. He had heard me speak about performance support systems and asked that I help him explore EPSS as an alternative. Having a client who "gets it," even if they don't entirely understand it at first, is an enormous advantage in a project like this. Other factors may surface as barriers to one road or another, but without support from advocates like this, you might as well stay home and save gas.

I was told that several geographically separate customer service call centers were being merged into one virtual center: employees would still be dispersed but would be asked to handle calls from customers in any of the original regions. Customer Service Representatives (CSRs) would also be asked to support a broader range of calls (i.e., various service plans, each with slightly different terms and conditions). As if that wasn't enough change, the computer system that handled the call center's transactions was being replaced with a modern one.

As is so often the case, we had a tight deadline driven by the transactional system's implementation schedule. Because the system was so far ahead of us but behind its own targets, we were told we could not influence it. Specifically, we could not build business knowledge or processes directly into the system, which instinct and experience told us we should do. While I'd characterize this new system as transactional at a detailed level, it was not structured along the lines of the overall process of handling customer calls. And, while it contained a "help" button, the help supplied was only traditional "systems help", that is, field definitions and so forth. Fundamentally, the "new" system was a GUI reinterpretation of the system that preceded it.

Under those conditions, the only viable solution seemed to be a separate on-line reference system supplemented with some diagnostic and calculation tools. Our reference system would coexist on the CSRs' electronic desktop but lack direct links between it and the transactional system. CSRs' could quickly toggle between the two, but not context sensitively. While we recognized that this was not ideal, we concluded that it was the best we could do given the time available and our inability to "touch" the transactional system. We interviewed and selected a vendor development partner and initiated a project.

Gathering the knowledge from business subject matter experts (SMEs) and CSRs surfaced just how inconsistently the existing call centers had been operating; that is, either not understanding and acting according to policy at the CSR level, or understanding but ignoring policy in favor of some more expedient set of behaviors. In a few instances, this led management to a consensus on the correct policy, which we then embedded in the knowledge tool. In other cases, the inconsistencies had to be accommodated because they reflected differences in opinion of the business sponsors for the various plans being serviced. Nevertheless, the process of gathering business knowledge is an often underrated benefit to the business resulting from this kind of project. Knowledge acquisition has the valuable side effect of bringing business strategy assumptions and day-to-day practices to light where they can, if necessary and if the will is there, be rethought and optimized.

As the project went on, the system failed to meet its target dates, giving us much more time than we thought we had. Unfortunately, because the dates slipped in small increments, we could never step back and reassess our decision to build a parallel reference system versus integrating knowledge and process into the transactional system. As I write this, the on-line reference system has been complete for several months but the transactional system is still at least three months from completion - a full year behind earlier estimates, assuming they meet their current targets.

Reflection

The on-line reference tool we built has already proven valuable to CSRs and their management. The benefits are obvious when compared to their previous "system" of sticky notes, taped up charts, and annotated binders of reference material. Call duration is down, CSRs are giving more consistent responses, CSRs are considerably less confused, and fewer calls are escalated for supervisor response. In that sense, the project is a clear success. But for those of us with a vision for what might have been, there remains a sense of "if only…"

If only:

• we had made a stronger case for our integrated, ideal solution versus the parallel systems approach we compromised upon.
• we had been aware that the system development targets would be pushed back a full year - at least.
• we had understood sooner the power of "essential use cases", described below, for understanding the role of knowledge in performing business tasks.

While we built a successful reference system on the premise that knowledge and system task performance were equal partners, we could have built a superb one had our team understood that in the call center operation business knowledge should have taken the leadership role. In other words, we should have made the knowledge tool the entry point - from which CSRs would, if necessary, be brought to the transactional system at a point contextually appropriate to the task (in other words, letting the knowledge of the customer's situation "lead the dance"). That understanding of the lead role for knowledge in the call center business process came when we developed an essential use case.

Essential Use Cases

At the Performance Support '98 conference in Dallas, September 1998, Lucy Lockwood described essential use cases as part of her presentation on "Software for Use: Models and Methods of Usage-Centered Design." The subject of essential use cases is too much to cover in depth here. I suggest instead that you visit http://www.foruse.com/ which is the home page for Lucy's company, Constantine & Lockwood, Ltd.

Essential use cases are similar to usage scenarios and other concrete examples, but differ is several key attributes: Quoting McMenamin and Palmer, Lucy said that an essential use case was "idealized, abstract, and technology free." Lucy said too that essential use cases were based on intent: what a user, in a given role, is trying to accomplish. Finally, she said that the best approach to defining an essential use case was to start with concrete examples, then simplify and generalize.

Let me illustrate the difference between detailed, concrete examples and essential use cases. Concrete examples can be expressed in the form of detailed scenarios. Lucy Lockwood used an ATM as an example. Scenarios for ATM use are familiar enough: to withdraw from your checking account you first insert your card and enter your PIN number, the machine confirms that you have an account, …and the process goes on from there. Other ATM transactions engender similar scenarios. Essential use cases for an ATM are much simpler. The essential use case for a withdrawal goes like this, expressed as a "dialog" between customer and machine (with machine actions in italics): Identify yourself; verify identification and offer choices; make choice; give money; take money. There you have it; process stripped to bare, "essential" bones.

When I apply essential use principles to the call center example above, the case looks something like this:

• A call comes in.
• The CSR gathers facts from caller and from the system, then…
• determines proper course of action, and…
• provides information to caller and/or performs system transactions.

The essential use case makes clear that knowledge gathering comes first, and that the system is first used in the context of knowledge gathering, versus the traditional view which assumes that everything occurs in the context of performing a transaction. In fact, the transactional aspect of the process comes at the very end, if at all! In hindsight, given that understanding, it seems silly to have let the transactional system take precedence.

Postscript

Okay, so we've gathered all this knowledge and put it into a reference tool to make the consolidated CSRs' job possible (not just easier), thereby meeting business objectives of faster call handling and more consistent, accurate (conforming to policy) results. Project complete? Not necessarily.

Wouldn't it make sense to get this information directly to the customers in such a way that fewer calls were generated in the first place? Of course it would. Fewer calls mean fewer CSRs! Unfortunately, we often get derailed by organizational issues. The people who run the call centers are not the people who create and distribute customer information. While we used (indeed rewrote for clarity) the customer materials so that they better served CSRs, in our project it turned out to be politically and organizationally outside our scope to influence the group who originally created these materials. So the customers are still stuck with confusing materials that generate "spurious" call center business.

Conclusion

While we provided a successful on-line reference system for a complex call center operation, we could have gone further had we better understood and acted on these barriers:

• Functional organizational definitions: systems versus training versus call center versus business client. These narrowed the view of potential, integrated solutions which could have achieved far greater business performance.
• System schedule over emphasized and taken as a given. We felt we had to work within the systems timeline - and then felt frustration when it slipped. Imagine what we could have achieved if we had known we had the full additional year that it has taken to build the transactional system.
• Failure to understand knowledge's lead role in the call center essential use case.
• Too narrow sponsorship (call center management versus their business clients), which limited our ability to fully exploit the business knowledge we captured.

Acknowledgements: Thanks to Lucy Lockwood, President of Constantine and Lockwood, Ltd. (LLockwood@compuserve.com; 978-948-5012) for an excellent presentation at Performance Support '98 in Dallas. Thanks too to my friends in the EPSS and Performance Centered Design community, and members of the STEP Consortium, for many engaging discussions of philosophy and design, both practical and abstract. Finally, thanks to my client on this project; it's people like you that keep the wheels of progress turning.

About the Author: Stan Malcolm serves as a coach to companies wishing to develop or review their strategies for performance support, learning technologies, and/or corporate learning issues generally. For eleven years prior to forming his consulting practice in 1994, he headed learning technologies and performance support initiatives at Aetna, Inc. He can be reached at Stan@Performance-Vision.com or 860-295-9711.