Customer Service Via Knowledge Management
By Chris Derossi, ePeople, Inc.
Amidst the sizeable investments companies are making in CRM systems,
knowledge management systems, workforce management software and other
technologies in the quest to deliver superior customer service and support,
there's some irony that shouting over the wall of the cubicle, calling
around the organization or e-mailing others for assistance is a key
component of the customer support process.
This ad hoc collaboration, which is repeated daily by support analysts
seeking assistance with complex questions, has become an accepted component
of the support process. In fact, informal collaboration occurs on over 80
percent of all requests, according to a January 2002 study conducted by the
Service & Support Professionals Association (SSPA). Unfortunately, this
informal collaboration happens outside of the standard support processes and
systems, which means that the information exchanged isn't captured in any
CRM system or knowledge base. Therefore, that incredibly valuable knowledge
is lost for reuse unless that same support analyst recalls it during another
interaction. The bottom line is that when a similar question arises, the
same time-consuming, inefficient, ad hoc process takes place all over again.
The Costs Of Informal Collaboration
Consider the typical scenario in the life of a complex support request. The
issue comes into the support department and the support analyst, who takes
primary responsibility for getting the issue resolved, most likely doesn't
have the entire set of knowledge or skills to answer it since the level of
complexity is so high. Once the analyst has exhausted all existing sources
of research and knowledge, he or she needs to tap other experts to help find
Typically, when a support analyst needs additional assistance with a
complex question, he or she will simply ask a colleague for help. However,
that person isn't necessarily the 'best' person to help solve the
problem. If that person can't help, then the support analyst embarks on a
search via e-mail or phone for other assistance. This inefficient searching
for the right resources has a negative impact on the performance of both the
support analyst and the support organization, impacting service levels and
other key performance metrics.
Once the right team for the problem at hand is finally located, it is
probable that the team does not have a formal, structured place in which to
work together, forcing informal collaboration. Trying to work together
without a shared workspace consumes a lot of time and energy because the
problem must be continually re-explained each time a new participant is
contacted. When finally all the communication has occurred and the support
analyst has the information required to respond to the customer, all the
preceding interactions, which are arguably as important as the final
resolution, are never recorded for future use.
Now add to the mix a complex issue that requires participation from
outside the support department, such as the development organization, or
from outside the company, such as a channel partner, other vendors or
outsourcers. The SSPA study reported that up to 80 percent of re-quests
requiring collaboration received help from outside the support department.
The inefficiencies and costs of informal collaboration quickly get
magnified, resulting in an increased backlog of requests, reduced service
levels, lost information and, most important, unhappy customers. In fact,
SSPA estimates that 75 percent of companies feel their current ad hoc
collaboration negatively impacts customer satisfaction.
The large volume of information exchanged through informal collaboration
is certainly very hard to measure, track and capture. But don't throw out
the baby with the bath water. Collaboration is not only required for
resolving complex issues, it can be a very strategic process for the entire
company ' when done correctly. By putting a formal, structured process and
targeted technologies around that collaboration, complex issues can get
resolved more quickly and accurately. Knowledge can be harnessed and reused,
and customer satisfaction will soar, resulting in the ultimate measure of a
company's success: customer retention.
The True Value Of Structured Collaboration ' Rich, Reusable
The value of collaboration goes well beyond just allowing two or more
people to communicate. By its very nature, the collaborative process itself
contains an enormous amount of valuable information ' the process that
occurs throughout the resolution contains very rich knowledge. Obviously,
the resolution itself is critical information to capture. But so are the
roles of the people involved, as well as how they worked together to best
achieve successful closure of the issue. To maximize the value of knowledge,
you must first broaden the definition of knowledge. Knowledge is not limited
to 'what' was the answer to a specific problem, but also includes 'who'
participated in the resolution and 'how' the resolution was achieved.
Most people think only about capturing the end result ' the ultimate
solution to a specific question ' as content to add to the knowledge base.
For simple issues, this is probably sufficient. However, when collaboration
between multiple people is required to arrive at a resolution, it is also
very valuable to capture the dialog that took place throughout the
interactions. The complete transcript contains not only the final answer,
but also the path that led there, often revealing critical aspects of the
context for which the solution is valid.
In addition to the 'what,' the content people contribute while
resolving an issue, it's important to know who said it. By knowing who has
worked on certain types of problems, and contributed to their solutions,
those same individuals can quickly be identified in the future when related
problems arise. This is particularly crucial with complex problems, where
subtle differences between situations may make it impossible to apply the
precise solution from one problem to a similar, but not identical, new
problem. In those cases, quickly locating the right expertise may make the
difference between making or missing service-level targets.
Frequently, more important than the actual names of the contributors are
their characteristics, such as their skills, qualifications, department or
company. For example, one of your major customers has a performance problem
with your company's enterprise financial software when it interfaces with
their ERP system from another vendor. While resolving the issue, it is
discovered that the root cause of the problem was lack of an index in the
database table ' something not immediately obvious. However, until the
primary support analyst invited a database administrator to participate as a
member of the problem-solving team, the problem could not be properly
If all of this trial and error, on-the-job learning could get captured in
a knowledge base, the next time any support analyst had a performance
problem with that particular application, they would know to invite a
database administrator into the collaborative team to expedite problem
Equally important in the collaboration process is the 'how' ' the
process by which a timely resolution was reached. What steps were tried
before the right answer was found? How many people did it take, and at which
point in the resolution cycle were they brought in?
For example, a company may find that, after analyzing past collaborative
issues for certain customers or issues, their most effective approach has
been to involve a broad set of people and skills up front in the support
process. Other companies may discover that, for one of their major
customers, the most effective way to resolve issues is to include the
customer only at the end of the process. Learning how to best approach the
resolution process for each situation can become key to most effectively
deploying valuable personnel and resources.
By capturing this information in a knowledge base, a company can develop
a more effective support process going forward. By capturing and analyzing
the complete interaction, trends emerge which can lead to improvement not
only in the customer support process, but also for the rest of the company.
For instance, it may be discovered that there are new product enhancements
that would reduce a persistent issue or opportunities for the sales force to
sell new service and training offerings to the customer. Knowledge about the
entire process can be valuable because it enables management to tune the
whole company's performance.
Improving Your Knowledge Base For Better Customer Service
A company's knowledge base is its brain trust. Support analysts may
come and go, but a knowledge base containing their interactions remains.
Herein lies the information that can help expedite complex customer issue
resolution, the goal of every company and the hope of every customer.
But a knowledge base is only as good as the information it contains.
Capturing all the interactions, the 'who,' 'what' and 'how,'
from all participants involved in the resolution of a complex issue is
imperative for improving customer service and support. Knowing when people
joined and left the interaction, the order in which things happened, when
critical insight occurred, when the transition took place between
understanding and solving the problem, and the final resolution ' is all
This wealth of knowledge enables not only the reuse of solutions to sets
of similar problems, but also the identification of the people and skills
that are most effective at solving new problems when they arise. By
capturing and examining the successes and shortcomings of the support
processes, this broader perspective of knowledge can be the basis for
continuous, companywide improvement and, ultimately, better customer
Chris Derossi is founder and chief technical officer of ePeople (www.epeople.com), a provider of
Internet-based, collaborative CRM solutions. Prior to founding ePeople,
Derossi served as director of the Magic Cap products division for General
Magic, where he led the team that built the operating system and
applications for personal communicators shipped by Sony and Motorola. He
spent six years at Apple Computer, where he was chief architect of Macintosh
[ Return To The
May 2002 Table Of Contents ]