Knowledge Normalization — the Destination
By Livia Wilson

It’s easy to find information on knowledge management (KM) – how to build systems, manage processes, reduce costs, and address challenges. The stated ROI examples are compelling. It’s almost like diet ads showing great results and offering step-by-step programs (except without the money-back guarantees). Like those diets, you have to follow the program to get results. What we find consistently is the KM diet is missing a key ingredient and the weight always comes back. How many KM environments can you walk into and find that after two years, they’re still showing an increasing level of efficiency (i.e. not high hit rates – real efficiency trends with every new problem)? The missing ingredient is managing the relationship of the content -- the relationship to the business demand, problem causes, expert resources, and back to the content itself. The Knowledge Normalization makeover program addresses the issue of the relationship of content to demand and root issues the content is meant to address.

Knowledge normalization is a process that enables content to become self-organizing (not just searchable) so it creates a measurable, optimized relationship between the customers’ experience, the problems introduced through our products and the operational environment, and the root cause of those issues. The relationship is called a “Resolution Path”. When support interactions travel along these Resolution Paths (instead of being resolved by someone using logic off the top of their head or a random knowledge search or both) the trip is much shorter. And, because the trips along these paths are measurable and lead to defined destinations, they consistently improve service delivery performance.

By using Resolution Paths, you can sustain your efficiencies over time. You won’t build up excess content or find navigating a knowledge system more tedious than asking someone else for help.

A case for normalization
In one case, the knowledge content was up over 20,000 records. It was useful but the “it solved my problem” rating was under less than 50%. The time-to-resolution measure was static. The system showed a significant decrease in time-to-resolution initially, but more than two years later, that metric had become static and had even started to increase. Internally, people weren’t using the knowledge content unless they were stuck and had started to use generic content to comply with the rules. They still used a variety of individual resources as they tried to address customer needs (e.g. email threads, product guides and alerts, past cases, etc.). The organization was facing a big ramp-up in business and couldn’t afford to hire added headcount. More efficiency was needed from existing resources.

What we did
For this client, we implemented the Knowledge Normalization makeover program which seeded critical product areas with Resolution Paths to get to a 10% level of maturity. That means that 10% of cases are solved by the normalized paths. We didn’t need to do much more than that up front because the rest could be done in the day-to-day workflow. The project took a focused four weeks, with a couple of subject matter experts, to complete.

What the client got
These results were immediate. We didn’t tell people to use a new workflow or set any numerical goals for what we were doing. We wanted to see if people would just get cases resolved better within the areas of normalized content. The measured returns were:

Median time to closure contrast:
Not normalized – 14 days
Normalized – 2 days

Time to Relief (when a proposed resolution or workaround is given but has not been validated or closed yet)
Not normalized – 12.5 days
Normalized - .5 days

Customers on the web gave very favorable comments on the normalized system and the internal support staff found it improved their understanding of the expert-level knowledge tremendously.

The effort will continue using an integrated workflow (i.e. qualitative feedback has been initiated internally, and the product experts act as knowledge champions to complete paths as the generalists define the context for them). The results are dramatic and the workflows ensure the improvements can be sustained.

The overall process for the Knowledge Normalization makeover program was described in the July 27 issue of SSPA News. Perhaps the most important consideration to illustrate is the content structure used to ensure the content creates the Resolution Paths.

The basic structure comprises the following dimensions (each should be designed according to the business requirements). This is a simple example about cookies.

While this example is very simple, it reflects a contrast between organizing the content, managing it, and using it. The three dimensions have to come together to enable an effective system.

Space
Space is a topology of related issues, usually around a supported product or service.

Metadata
Is sometimes reflected in the content and therefore is often only used in un-normalized content for tracking activity. When the purpose of use is reflected only in the content, it often doesn’t sufficiently differentiate the relevance of the content. The relative connections to how the content should be used in a specific situation are insufficient. Subsequently, the system starts to operate much like a text retrieval system and users wouldn’t necessarily realize stale cookies had a relationship with an old delivery schedule for hotel chains. At the management level, the delivery schedule couldn’t be easily categorized in enough ways to indicate the relationship across the content for managing costs. The system also couldn’t drill down through the content to drive relevance to a situation to help users find the content – and if they did, they may not realize that it might be relevant (users may not think to ask about deliveries related to dry cookies).

The metadata, in addition to creating relevance, enables relationships to be managed by associating the users’ perceptions with the underlying problems and their associated costs (how much are these outdated schedules costing us?) You may know how often people are asking about dry cookies but you still need to know it’s the schedules that need to be fixed. This builds a persistent, manageable correlation between information, costs, and underlying causes. The metadata should enable those correlations to be tracked and acted upon.

Knowledge objects
Context-level objects (what is perceived) – Often, in highly-complex environments, the users’ experience doesn’t highly differentiate one problem from another. The environmental factors and the user’s perception are highly subjective. Therefore, creating context frames that link to problem objects allows users to create high relevance with an object before moving to the problem. If you combine too many possible symptoms/problem descriptions, you create ambiguity for users and dilute relevance for the system.

Problem-level objects (what is known) – The cookies is an example of a problem-level object. People may perceive the problems in many different ways, and there may be many different causes for a problem. By keeping the problem at a specific level, we can better enable a dynamic connection from many different points of view. The problem object should ensure the real issue is isolated through the qualifying/objective information.

Causal-level objects (why) - The cause of the problem should be maintained as a separate object with its own context frame. A different workflow is enabled to maintain the cause objects which can have a many-to-many relationship with the problem level objects.

How does this structure enable better Resolution Paths?
Increased logic – All the objective/qualifying information must be true. In our example, if the qualifying statement about packaging damage is true, the user is directed away from this content object onto a resolution path about packaging. Through the paths, the problems are solved methodically and consistently so problem costs can be tracked.

Increased context around the fix – The information about the fix should not be solely about what users need to know to fix the problem. Don’t assume that a connection with the problem is the only important context connection. Connecting with the fix such that users can feel confident that the fix itself is not a risk is also important. This increased confidence increases resolutions on the web.

Decreased reliance on the environment – Generally, the environment description(s) helps people identify with the content but can’t be counted on to drive relevance. It should be used for filtering, to exclude things, but not to relate things. Support organizations tend to overemphasize the importance of knowing the product, version, and release of problems before isolating the problem. These are overly important because relevance is lacking in other areas (like knowing what the problems really are). These are most important to know when applying the fix and when managing the content. They are less important in the resolution workflow.

Why is this more sustainable?
The content described here creates a knowledge space and a relationship between knowledge objects. From this view, knowledge specialists, champions, and engineers can assume responsibility for paths (related objects about common problems) within a space with specific business values. Content isn’t proliferated independently of the paths. Suggestions for new content and updates are reconciled against those paths and the associated value and affinity to resources is known. People are then inherently organized to work together rather than independently to maintain content. The value and relevance (differentiated relevance not just high relevance) not the quantity becomes the focus.

About the author
Livia Wilson is a principal with OutSights, Inc. (OSI), a management consultation firm. OSI helps organizations implement new customer service programs and specializes in system design to deliver services more profitably, effectively, and leverages knowledge to benefit customer support organizations and their customers. The ability to translate complex service struggles into service solutions is an unusual and desired skill. This competitive edge allows OSI to empower clients with new knowledge, making them feel significantly more comfortable with the numerous service environment activities they manage.
For more information about Knowledge Normalization services and how to get started, please contact OutSights associate Farrell Dessert at 913-651-6424 or email fdessert@outsights.com.