(Part 1 of 2)
Providing customer service, whether via self-service, performed through the web, delivered through a call center; outsourced or insourced is a business process...on that everyone can agree. And the specific types of customer inquiries can be grouped into a series of sub-processes related to providing customer service e.g. purchase a product, inquire about a charge, return or repair a product. And most customer service environments have figured out how to create prescriptive work flows (scripts and call aids) that are organized around these sub-processes.
However, most of the supporting content and information designed to support accurate and complete response to customer service questions isn't organized by process. It's categorized in information categories that don't align with the way an agent or a customer would expect to find them. So the most common approach to solving customer service content issues is to use enterprise search or to create a large knowledge base of Q&A that can be...searched. One problem with this approach is that as the body of knowledge and content grows, so do the search results...and instead of helping with productivity, this approach drains it by requiring agents and customers to wade through the mounds of content and Q&A returned in a search result before they can provide a hopefully, correct answer.
An alternative method for categorizing content is to do so around the processes, workflows and types of questions that are typically posed. This approach can reduce agent and customer "search" time by up to 50% on a per incident basis. The impact on quality is intuitively positive. The flow-through impact of answering customers more quickly and accurately is also obvious.
But where to start?
Wednesday, October 21, 2009
Friday, September 18, 2009
Contextware: In the Basex Briefing Room
As often happens, third parties looking from the outside-in find new ways to explain and articulate issues that Contextware addresses, and the article below from Basex, Inc., the world's foremost knowledge economy research and advisory firm is no exception. We think you'll find their review of Contextware interesting.
The article begins:
One of the missing pieces of a puzzle the knowledge worker faces in the course of performing knowledge work is context. Without context, the knowledge worker is looking at isolated bits of information that are, more often than not, of limited value. Most content doesn’t stand on its own; there is always important related and supporting information that completes the picture. Beyond a single document, what else should one read and whom else should one query? Knowing what to read next or which experts to contact completes the puzzle and increases the value of the content exponentially. Click to read the entire piece...
The article begins:
One of the missing pieces of a puzzle the knowledge worker faces in the course of performing knowledge work is context. Without context, the knowledge worker is looking at isolated bits of information that are, more often than not, of limited value. Most content doesn’t stand on its own; there is always important related and supporting information that completes the picture. Beyond a single document, what else should one read and whom else should one query? Knowing what to read next or which experts to contact completes the puzzle and increases the value of the content exponentially. Click to read the entire piece...
Wednesday, August 26, 2009
When do you stop?
Summer in D.C. is usually a slow period...people on vacation, oppressive summer heat and humidity, Congress out of session. But we've never been busier and as a result, we've neglected the blog a bit. Apologies.
I spoke at the SALT learning conference in Arlington, VA the other day and was asked the question by a knowledge manager in the audience, “when do you stop gathering process or business knowledge and implement your solution.” In other words, how do you know you have what you need to deploy?
I answered it this way. When you implement a training solution, you create a class or an instance of that training which is very modular in nature. You might review it annually or on some other schedule, but regardless, the content is not dynamic in nature. When you implement a BPM solution…you go to great lengths to define requirements, create workflows and integrate/code systems. But try to change it? Workflow is very brittle.
But business is ever evolving. Rules and regulations change. Content and templates change. Employees leave, new ones join. But most importantly, someone is always figuring out a better way to perform the job they’ve been told to do. And in Contextware’s world, we made the conscious decision to create a technology that allows for those improvements to be captured and conveyed quickly and efficiently. It is one of the biggest differentiators in the way we approach process improvement, knowledge and performance support.
I spoke at the SALT learning conference in Arlington, VA the other day and was asked the question by a knowledge manager in the audience, “when do you stop gathering process or business knowledge and implement your solution.” In other words, how do you know you have what you need to deploy?
I answered it this way. When you implement a training solution, you create a class or an instance of that training which is very modular in nature. You might review it annually or on some other schedule, but regardless, the content is not dynamic in nature. When you implement a BPM solution…you go to great lengths to define requirements, create workflows and integrate/code systems. But try to change it? Workflow is very brittle.
But business is ever evolving. Rules and regulations change. Content and templates change. Employees leave, new ones join. But most importantly, someone is always figuring out a better way to perform the job they’ve been told to do. And in Contextware’s world, we made the conscious decision to create a technology that allows for those improvements to be captured and conveyed quickly and efficiently. It is one of the biggest differentiators in the way we approach process improvement, knowledge and performance support.
Thursday, July 23, 2009
Process documentation for communication and collaboration
Yesterday Contextware announced the award of a new contract from the U.S. Army. The award is for software to help with capturing and codifying manufacturing process knowledge and information. That’s a great new client for us and also serves as a nice lead-in to an important point about process documentation.
There are a lot of software technologies classified as business process management, or process documentation tools. So why Contextware for the Army instead of a more classic (precisely defined) BPM or process documentation software?
The honest answer is that the Army uses plenty of process tools, but in this use-case, the answer lies in a specific Army requirement for this procurement: “the system will also facilitate communication and collaboration to conduct prototype and manufacturing process development efforts.”
The origin of documenting business processes traces back to the need to develop data models, data bases and automation of business rules…resulting in the creation of a common language to document processes. And based on these needs an entire industry of business process management software was developed.
Contextware’s focus is on the non-automated aspects of the business. And early on we determined that process documentation served a useful role, not just as a means to enforce business rules, but more importantly as a means to capture information about the enterprise and the way it does business. And then to serve as a means for communicating it and connecting to content relevant to those processes.
This is why the U.S. Army is working with us…because its challenges related to process have much more to do with understanding, accumulation of knowledge, learning and collaboration then they have to do with automation of specific activities or tasks.
There are a lot of software technologies classified as business process management, or process documentation tools. So why Contextware for the Army instead of a more classic (precisely defined) BPM or process documentation software?
The honest answer is that the Army uses plenty of process tools, but in this use-case, the answer lies in a specific Army requirement for this procurement: “the system will also facilitate communication and collaboration to conduct prototype and manufacturing process development efforts.”
The origin of documenting business processes traces back to the need to develop data models, data bases and automation of business rules…resulting in the creation of a common language to document processes. And based on these needs an entire industry of business process management software was developed.
Contextware’s focus is on the non-automated aspects of the business. And early on we determined that process documentation served a useful role, not just as a means to enforce business rules, but more importantly as a means to capture information about the enterprise and the way it does business. And then to serve as a means for communicating it and connecting to content relevant to those processes.
This is why the U.S. Army is working with us…because its challenges related to process have much more to do with understanding, accumulation of knowledge, learning and collaboration then they have to do with automation of specific activities or tasks.
Tuesday, June 30, 2009
Tough Subject Matter Experts
As a follow up to our June 17th post about capturing subject matter expertise, we thought we should take a moment to address a subject we're always asked about and occasionally run into.
How do you approach subject matter experts that are less than willing participants in the process of gathering/documenting their knowledge? These folks are different from SMEs that find it difficult to articulate their knowledge. This group simply tends to obstruct the process, don't necessarily buy into the project, and as we often hear "are trying to protect their jobs."
The initial trite comment is that you don't need them. In our experience, it's often the people that are most difficult to deal with that a) possess something that really doesn't have that much organizational value or b) have created such convoluted processes or approaches that you'd be better starting from scratch once they're gone (this response is often met with the nodding approval of the project leader or executive sponsor who realizes "Joe the SME" is really a liability to the organization, much less a team player.)
The kinder gentler answer of course is that you need to apply a combination of carrot and stick. Here are few to consider.
Sticks (we're not a big fan)
-incorporating knowledge transfer into performance review objectives or goals
-heavy supervisor/management intervention-peer pressure (e.g. publishing KM project progress to all involved and highlighting constraints)
Carrots
-Appeal to ego. Educating the SME on their role in the organization and leaving a legacy (most well intended people want their company to succeed in the short and in the long term).
-Appeal to laziness. A true SME is sought after frequently...to answer the same or similar questions over and over again...a well run capture project will reduce the amount of time SME spend answering questions.
-Financial or professional recognition. Everyone likes rewards, even non-monetary. Having some incentives in place for a KM project and as part of your project plan/budget can get more out of people
-Be reasonable and accurate in the time required from the SME. If you need more than 10-12 hours of their time over a couple of month period, you've lost them-Show them; involve them in the results of your effort. Most projects such as knowledge capture or process capture have very little near term gratification. Systems or projects that show incremental success and output have a far greater chance of convincing those involved that the project is worth the effort.
How do you approach subject matter experts that are less than willing participants in the process of gathering/documenting their knowledge? These folks are different from SMEs that find it difficult to articulate their knowledge. This group simply tends to obstruct the process, don't necessarily buy into the project, and as we often hear "are trying to protect their jobs."
The initial trite comment is that you don't need them. In our experience, it's often the people that are most difficult to deal with that a) possess something that really doesn't have that much organizational value or b) have created such convoluted processes or approaches that you'd be better starting from scratch once they're gone (this response is often met with the nodding approval of the project leader or executive sponsor who realizes "Joe the SME" is really a liability to the organization, much less a team player.)
The kinder gentler answer of course is that you need to apply a combination of carrot and stick. Here are few to consider.
Sticks (we're not a big fan)
-incorporating knowledge transfer into performance review objectives or goals
-heavy supervisor/management intervention-peer pressure (e.g. publishing KM project progress to all involved and highlighting constraints)
Carrots
-Appeal to ego. Educating the SME on their role in the organization and leaving a legacy (most well intended people want their company to succeed in the short and in the long term).
-Appeal to laziness. A true SME is sought after frequently...to answer the same or similar questions over and over again...a well run capture project will reduce the amount of time SME spend answering questions.
-Financial or professional recognition. Everyone likes rewards, even non-monetary. Having some incentives in place for a KM project and as part of your project plan/budget can get more out of people
-Be reasonable and accurate in the time required from the SME. If you need more than 10-12 hours of their time over a couple of month period, you've lost them-Show them; involve them in the results of your effort. Most projects such as knowledge capture or process capture have very little near term gratification. Systems or projects that show incremental success and output have a far greater chance of convincing those involved that the project is worth the effort.
Thursday, June 11, 2009
Tweeting for Business
Having created my own Twitter account a couple of months ago, I still struggle with trying to determine the business value of tweeting. Although there are plenty of anecdotal examples of how Twitter can benefit a business those examples are the exception and not the norm. And as a result it seems difficult to envision a systematic adoption of tweeting in a business environment. That said, here is an interest blog page from blogger Chris Brogan titled 50 Ideas on Using Twitter for Business. They aren't use cases as much as they are things to consider. Check it out if your looking for an excuse to dive in.
http://www.chrisbrogan.com/50-ideas-on-using-twitter-for-business/
http://www.chrisbrogan.com/50-ideas-on-using-twitter-for-business/
Subscribe to:
Posts (Atom)
Posts
