Blog post

A wiki in the call center. It’s really okay.

By Darin Stewart | March 17, 2011 | 4 Comments

Enterprise Content ManagmentCollaboration

I’m a firm believer in the editorial process.  A formal publication workflow that includes peer-review, fact checking and editorial review goes a long way to ensure quality content.  Gartner follows such a rigorous process and I think it shows in our product. Editorial review as a best practice can be applied to any publication scenario,  but as with most things “can” does not always mean “should.”  Take for example the knowledgebase of a helpdesk call center. Accurate and timely content is the life blood of a support agent.  When a call comes in requesting help for some obscure problem, there had better be an accurate and up-to-date article on the topic in the knowledgebase for the operator to reference if they are to have any chance of helping the caller.  This would seem to argue for tight control of the content.  A domain expert should write the original article, which is then reviewed by a peer and then finally approved for publication by a manager.  Several sets of eyes should yield a reliable article.

This looks good on paper, but the reality is that in most organizations these functions fall outside of the day-to-day duties of those who should perform them.  A domain expert may dash off a note about a problem she has just solved, but her peers are busy solving other problems and the manager is swamped with just keeping the trains running on time.  As published articles age and expire, the backlog gets longer and longer and the knowledgebase becomes less and less relevant. Even when editorial duties are written into job descriptions, they are given a very low priority. 

The solution is to loosen up the publication process and put a little more trust in your staff.  The simplest way is to move the knowledgebase from a traditional command-and-control repository to a wiki.  I have had IT directors chase me out of conference rooms for even suggesting such heresy.  “Without proper review and managerial approval of each article,” they say “bad information will find its way into the knowledgebase.” While this may happen, the truth is, there is already bad information in the knowledgebase.  The dirty little secret of knowledgebase article review is that unless there are adequate resources (and in these days of scarcity that is a rare situation) the review and approval is a rubber stamp if it happens at all.  More conscientious managers just can’t get to them, so the knowledgebase ends up with 60% of its content expired at any given time. 

A wiki-based approach, on the other hand, removes the barriers to content sharing and allows the domain expert to share a solution, or correct an error, as it is discovered.  Managers can still be alerted when an article they might want to review is changed, peers who might want to chime in can still be alerted and you can of course still limit who is authorized to contribute.  This results in a much more agile knowledge environment. But what about those errors and inaccuracies that will sneak into the production repository?  Think of it in terms of a traditional encyclopedia like the Britannica and a collaboratively developed one like WikipediaA study published in the scientific journal Nature compared the accuracy of forty-two science related articles in the two encyclopedias.  On average, a Wikipedia article contained four errors while a Britannica article contained only three. So Britannica had a slight edge when it came to accuracy at the time. The difference is, the Wikipedia errors were corrected in production as soon as they were detected, while the Britannica must wait for the next edition to be published (which most people can’t afford anyway). 

The same principle holds true for rapidly evolving, volatile content stores like an internal knowledgebase.  Errors will creep in, but they will be detected and corrected much more quickly than if they must be processed through an under resourced editorial workflow. At the same time, the barriers to adding fresh, timely and relevant content are dramatically reduced.  Incentives for contributing, commenting and rating content can further enhance quality.  Such an approach clearly is not appropriate in all situations, but in a closed user environment, like a call center or an IT department, it really does work and has been successfully adopted by many organizations.  The content won’t be perfect, but it will probably be better than what you have now.  Never let “perfect” become the enemy of “good enough”.

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • A A says:

    “Gartner follow’s such a rigorous process and I think it shows in our product.”

    Follow’s? In the same sentence that talks of a strong editorial process?

  • Darin Stewart says:

    Oh my, that’s embarrassing. Mea culpa. Gartner’s editorial process is applied to our formal research publications. Blogging doesn’t have as much adult supervision. In a way it does reinforce the point of the post. A slight error was published (in this case a typo). It was caught and corrected within an hour or so. Thanks for the catch!

  • LAS says:

    In terms of the subject this post couldn’t be timelier. As both a user and administrator of an internal IT knowledge base I face this issue day in and day out. A perfect example occurred last week in fact. I looked up in our KB for the correct procedure to connect a mobile device to the internal/secure network, and as expected nothing was to be found. When I called the helpdesk I was quickly emailed the solution. I asked why this information was not within our KB, and the response was that the helpdesk didn’t have the time or resources to push articles through the process (i.e. it took too long and they needed information available now). Further inquiry showed that the help desk even installed their own shadow wiki because it “fit their needs better”. The strict adherence to KB policy for best practices has left our organization in a worse case position for knowledge management (i.e. bad practice).

  • MCM says:

    \… put a little more trust in your staff.\

    I get that it’s always a challenge to have trust that runs through each level of an organization, however in times of lean resources it is more important than ever to develop, nurture and allow that trust to happen. Of course trust must run in both directions to have any chance of success.

    A firm grip does not have to be a stranglehold.