The Avocado of Knowledge Management

Recently I’ve been talking to many servicedesk managers from different organisations to better understand the service delivery problems they solve with Knowledge Management.

Knowledge Management is a funny old thing – it certainly has a high level of awareness amongst servicedesk managers but isn’t considered as fundamental as Self-Service, Incident, Problem, Change or Config.

Most of the practitioners that I spoke acknowledged that they would like to do more with their implementations of Knowledge Management but – as we all know – sometimes it’s all people can do to keep services running and SLAs met.

We posed what we hoped was a probing question to servicedesk managers. “If we could prove that investing in Knowledge Management resulted in improved service to end users… would you do so”

Towards the end of this article I’ll provide some real life responses to this question.

Effective knowledge management certainly has the potential to both improve service and reduce costs for an IT organisation by encouraging shift left… shift down


This model – defined by Tim Cobben from KPN in the Netherlands – shows how incident resolution time and cost increases as the resolving engineer moves up and to the right, away from the customer.

As issues are escalated from the service desk to 2nd or 3rd line support groups, we are resolving the issue with more expensive engineering resources that are further removed from the customer.

The aim of the IT Manager should be to shift left… shift down. Where possible move the point of resolution towards self-service. How can we do this? With effective knowledge management tools and processes. And of course… content.

The HDI Support Center Practices & Salary report contains some interesting statistics about the costs of different forms of support.

  • Walk-up support costs an average of $20
  • Phone support costs $17
  • Email support costs $14
  • Peer support costs $7
  • Community support costs $2

The Peer support and Community support costs were predictions that we made rather than data from the HDI report.

You can clearly see that the model of shift left… shift down would lead to economic as well as customer satisfaction benefits. As an IT Manager you would want to move to a community support model based on a knowledge management strategy as the most economic way to scale your IT support operations.

Knowing that applying effective Knowledge Management to customer interactions such as incident and self-service, how do you get started?

Slicing up knowledge management

We looked at how customers are using knowledge today and how other products and tools are redefining the knowledge management landscape and defined this model.

We call it the “Avocado of Knowledge Management”


Engineered Knowledge

At the center of the model we have an activity called Engineered Knowledge. This will be familiar with anyone maintaining a knowledge base in their organisation today.

Characteristics of Engineered Knowledge practices are:

  • Structured content, normally in article format
  • Content is written by a small number of contributors, sometimes they are dedicated writers
  • Content has a formal approval and publishing workflow
  • Content is categorised and ordered

There are many examples to hand to demonstrate Engineered Knowledge. All big software vendors have a knowledge base containing many articles. You can imagine that these articles were written and reviewed by technical writers and had many rounds of reviews before being published.

Engineered Knowledge is an interesting case – it requires a formal process and good tooling to support the publishing and approval workflow. It also aims for completeness and accuracy.

Many customers that I have spoken to complained about the overhead involved in getting valuable content into their knowledge base.

Contributed Knowledge

Next in our graphical model we have an activity called Contributed Knowledge that surrounds Engineered Knowledge.

This activity is familiar to those of us that work in IT support today. Those that write contributed knowledge work amongst us on the service desk, network and database teams.

They are people who have a primary role but are able to contribute knowledge as a by-product of that work. For example as a network engineer figures out a gnarly configuration issue with his Cisco VPN router he can document it to help the next engineer that might find the same issue.

Contributed knowledge has a cheaper cost of production as it is created by non-dedicated authors. It also has a lower level of authority as the publishing process won’t have multiple levels of review and approval.

One theme throughout this model is the tradeoff between Cost, Authority and Immediacy of content. Although knowledge written by the network engineer might not have been triple-checked and re-edited for mistakes it did deliver value to its readers in a shorter amount of time.

We traded authority for immediacy.

Social Knowledge

Wrapping the layer of Engineered Knowledge we have a layer referred to as Social Knowledge.

This class of content is typically contributed by end-users, perhaps interacting with technical teams in a forum or Twitter style stream format.


With Social Knowledge our primary characteristic is Immediacy. Users and technical staff can have a real-time conversation, often in a public or quasi-public setting and generate knowledge.

In the case above you can see knowledge being traded about a service impacting event (the WiFi in building 3) or about common application questions.

There is a danger associated with trading the Authority of the content however. We don’t know whether Lee Javens is a peer user that found a solution or someone in the IT department. The tradeoff is apparent.

Why is it called the Avocado of Knowledge??

The idea of the avocado was to highlight the layered nature of the types of knowledge, especially regarding authority.

Engineering Knowledge is like the stone in the middle of the avocado – it’s formal process with review and approval makes it the firmest in terms of authority.

Contributed Knowledge has a lower level of authority. Although written by subject matter experts it won’t have the formal approval processes. Think about your wikis and HOWTO documents written by engineers in your organisation

Social Knowledge has the least authority. It isn’t easy to tell whether an answer is correct or approved. Answers from the peer community of users of a service are inter-mingled with those from technical experts.

A quick crib sheet of the Avocado of Knowledge


Social interactions cut through the Avocado

We mentioned Social Knowledge as a class of knowledge imagining Twitter-style streams of updates and conversations.

There is another dimension to Social that applies to all three classes described above. These are social interactions that are equally as applicable and useful in Engineered or Contributed Knowledge.

There are 6 types of social interactions that can be applied to knowledge

  • Consume: Read the content, digest it and move on
  • Interact: Hit the “Like” button, Thumbs up or +1 to lend your vote of confidence to an article. Perhaps this should increase the Authority of an article
  • Curate: Add categories, tags or other data to improve an article. Making it more useful for others that will read it in the future. Perhaps adding a comment to an article is a form of curation
  • Create: Create new content based on the original work or build on top of existing content
  • Network: Find authors and contributors, follow them and reshare content into that network. Both LinkedIn and Twitter are create examples of content sharing networks
  • Build Reputation: Give thanks for correct answers in the form of points, awards, coins or kudos

There are some very interesting possibilities when you look at how users can interact with knowledge content using these social signals.

For example, we would expect that Engineered Knowledge – formal articles that have been checked and approved – would have an expiry date. All Knowledge must die at some point.

What if an article starts to receive lots of negative interactions in the form of a thumbs down. Should that article suddenly be flagged for review because the instructions it provides no longer works for users?

We consider Social Knowledge to have the least Authority because we can’t validate the solution that is offered. Perhaps the person that documented a solution didn’t properly test it.

Well could we build reputation – another social signal – to measure the authority of the knowledge? When a person has gained reputation through high quality content can we promote their contributed knowledge as a possible correct answer.

Why aren’t organisations diving into Knowledge Management today

Earlier in this article I promised to share some insights from people working in Service Management today.

We asked them a question that directly related to the shift left, shift down model described earlier and if they would use knowledge to deflect incidents and servicedesk calls

The question was “Would it result in an economic change or a change in how the organization is staffed and managed? How would this change your relationship with your users?”

The answers were interesting:

“If knowledge is positioned correctly it can definitely impact the organization. You would need less help desk technicians and users would have less down time thus increasing their productivity. If IT can spend less time reacting to issues they can focus on being strategic partners to the business.”

“IF this successfully reduced volumes of calls into the IT Service Desk and incidents being raised by them as a result of the call volumes then I would image that future growth within the IT Service Desk would be discussed or possibly re-organised into a structure that would be more beneficial to this way of working, perhaps have a small team of “Knowledge Editors” that owned and created the various articles that were publicly available”

“It would free up more time for high impact incidents, improve quality and throughput.”

“I think relationships are created between humans, not between humans and machines. The relationship between the service desk and customer would be minimized, but this would allow resources to be focused in other value-add areas.”

I find it interesting that we gave servicedesk managers an opportunity to think about Knowledge Management as an opportunity to handle the same volume of end-users with a smaller number of staff due to knowledge being used to resolve issues.

Almost all of them saw an opportunity to use Knowledge Management to reclaim engineering capacity to solve harder issues, be more strategic and to spend more time providing value to their users.

Surely this is a good thing! Every good blog post ends with a call to action and here is mine.

What next? Your call to action

Today please examine your self-service and incident management processes and identify where effective use of Knowledge Management could improve resolution times and autonomy amongst your users.

If users had the right solution presented to them could they fix their own issues? Are you doing enough to get knowledge in front of users when they need it.

And if pressures of time and resource are preventing you from building a great knowledge base could the avocado of knowledge help you understand about trading authority for immediacy and cost?

Thanks for reading!

6 thoughts on “The Avocado of Knowledge Management”

  1. A few provocative questions, if I may (without taking sides….) :
    Is it in the interest of a Service Desk agent to solve the same amont of issues with less staff? And risk being layed off?
    The same question applies to 2nd and 3rd line staff.
    And what about managers? The more staff they have, the more important they are and the better it looks on the CV. is it in their immediate interest to reduce staff?
    About self-service: is it good economy to let the CIO / accountant / engineer / etc look for a solution in the self-help? Compare the salaries and the answer is given.
    Anybody with good answers, please? It would help in the implementation of Solution Centered Support / Knowledge base implementation and maintenance.

    1. Hi Josef, thanks for leaving a comment.

      So I wrote this article because I had done a lot of research on the subject at work (You can check my Twitter or LinkedIn to see who I work for).

      We interviewed about a dozen different customers and spoke to the Service desk administrators and ITSM tooling support staff in each company.

      We explicitly positioned the idea of knowledge as a method to reduce incident volume and cited cost saving at the servicedesk level as an opportunity. This claim was a good example of “Devils advocate” because we wanted to test the thesis whilst not really believing it ourselves.

      Our customers set us straight. They don’t believe that an effective knowledge strategy would result in a reduction in staff. They do think that the same staff will be just as busy either working on more unique, thorny issues or will spend more time giving personal service to users or will spend more time on preventative maintenance and those types of activity.

      I think nominally you are right in worrying about the interests of the service desk agent and concerns about job security. In my recent experience service-desk managers want to do more with the same staffing levels and they know that staff reduction – even if they did want it – just isn’t realistic.

  2. I’m not convinced of the economic benefit. As a user the “shift down” means it’s costing me more effort to find a solution to my problem. Often times a solution that a service desk agent could give me in less than a minute. The “shift down” sharply decreases the immediacy of the knowledge to me as a user. That in turns decreases the perceived value I get from using the service, as it costs me more to use it in favor of it costing less for the service provider. Consequently, I will be inclined to leave the service, thus reducing the benefit for the provider. Without taking this into account I don’t think the cost reduction described is accurate enough to invest in the “shift left”, “shift down” approach.

    1. Hi Manuel,

      Thanks for leaving a comment, your points are very valid. I don’t think “shift-left, shift-down” should be considered as an alternative to a personal, real-person support service. It’s a complementary alternative.

      In my experience some users will struggle with annoying issues rather than go through the hassle of contacting IT through the Servicedesk. For the types of issues where knowledge can be shared to help users self-serve it could result in a more frictionless experience. Certainly more frictionless than having to call up, explain the issue and then wait for a solution.

      I wouldn’t compare an effective Knowledge strategy with – for example – interactive chat sessions with a customer service rep. I’m sure we’ve all had experiences with online chat support where you know you are getting canned responses and the level of friction is far higher than just picking up the phone and talking to a real person.

      Those kinds of poor experience, interactive chat sessions are an example of the service provider trying to short-change the user. Rather than offer a superior service on the phone they are overloading operatives with multiple simultaneous customer conversations and it raises the level of friction for each customer.

      Good knowledge should reduce the friction. Does that make sense?

      1. Sure, it’s a complicated equation, that was my point. If you talk about economic benefit, you need to factor in the side effects of the approach you take, not just the cost reduction.

Comments are closed.