Will Wikis replace the traditional KB for Web self-service?
Yes, ultimately, I think that they will.
I just wrote up my 2008 Web Self-Service trends, and I am now becoming convinced that Wikis are the new knowledgebase (KB):
“Though discussion forums dominated the Web 2.0 conversation in 2007, look for wikis to grab some of the spotlight in 2008. This easy to access, search and edit “living document” is a logical replacement for the maintenance-intensive traditional knowledgebase. A key new process for 2008: identify ‘best practices’ as they emerge in discussion forums and migrate them to the wiki library.“
My trends stem from a startling metric from the SSPA Benchmark database: Successful visits to Web self-service declined 4% in 2007, from 44% down to 40%. There are many reasons why self-service success is declining (faster product lifecycles, rising complexity, broader customer audience), and I now think that throwing more money at the traditional “KB and search” approach is not the solution. Sure, many companies need to overhaul outdated self-service, and heaven knows better search technology would increase accuracy of many sites. But I also think we need to look beyond our current self-service paradigms.
Judging from the member success stories about customer adoption and call deflection from online customer discussion forums, Web 2.0 is clearly part of the solution. And when you identify useful content in a forum, what do you do with it? Migrate it into your old knowledgebase where no one may ever find it again, or instead have popular discussion threads morph into entries in your Wiki on how to implement, use and upgrade your products? With tagging, Wiki content can be easily categorized without the overhead of a complex content ontology.
There is more detail available in the research report, and I’m sure I will be writing more about this topic in 2008. To get started with wikis, consider these recommendations.
- Start internally. Wiki vendors report that most customers start with wikis internally to better understand the technology and processes, identify best practices, and then introduce for external use. This also allows the wiki to build up a good library of content so customers have something substantial to use from Day 1.
- Leverage existing processes. As with any self-service technology, ensuring customer adoption is critical for success. SSPA Research recommends that when introducing Web 2.0 elements to self-service, start with existing processes that lend themselves to Web 2.0 automation. This provides a built in set of users and accepted processes.
- Look to younger agents. When first starting wiki initiatives, draft some of your 20-something agents for the initial team in lieu of your current content SMEs and knowledge administrators. Forums and wikis may represent a major paradigm shift from traditional KM practices, and the project will have difficulty getting off the ground with too much “but we’ve always done it that way.”
Are you using Wikis in your support environment (even internally)? If so, how is it going? Please add comments or send any thoughts via email. And as always, thanks for reading!
January 2, 2008 at 7:28 pm
[...] Akkamâ??s Razor wrote an interesting post today onHere’s a quick excerpt [...]
January 2, 2008 at 7:42 pm
I disagree that it’s always harder to find information in a KB than a wiki. What defines a wiki is how the info is posted, not how it’s found.
http://www.google.com/search?hl=en&q=define%3A+wiki
January 2, 2008 at 7:54 pm
Traditional CBR-based knowledgebases don’t lend themselves to easy, frequent, transparent updates, nor do they allow collaboration with customers. Finding it isn’t the issue, it is how quickly new content can be available for customers.
January 3, 2008 at 6:34 pm
How can a company keep people from posting disparaging comments and inaccurate information?
January 3, 2008 at 6:42 pm
This is probably the biggest concern companies have about starting a customer discussion forum. However, companies like Novell who have been doing this for a few years say it isn’t an issue–they only receive about 1 ‘flame’ posting a year. Keep in mind these are registered customers–not the general public–and nothing can be posted anonymously. And you have rules you can set in community tools, such as allowing you to review comments before they are posted for all to see. But you will have all the ‘worts’ of your products discussed, and having an attitude of openness helps win loyalty.
January 3, 2008 at 8:41 pm
Before everyone starts trashing their current KB tools and spooling up RFP processes for the latest and greatest wiki tools, remember that technology is never a silver bullet. Think of wikis as the equivalent of the telephone, which was the 20th century replacement of the telegraph, which followed the Pony Express, and so on all the way back to the first spoken words. Each was evolutionary in their time but only as effective as the user, the learning, or the process.
The value in wikis is the viral nature of contribution. And John is spot on that “traditional KBs” will fade away in favor of applications that support, and encourage contribution. But what about the checks and balances? Little constraints like Sarbanes-Oxley and HIPPA increase the risk of enabling broad contribution. Remember also that companies will always want editorial rights, and there are bound to be some situations where contribution simply is not wanted or feasible.
Don’t get me wrong, wikis have power and value. But they simply embody the next evolutionary step. To think that you should forego all the benefits of a structured knowledge management methodology and the KBs that enable structure is myopic. Wiki is just a name with implications, just like to the average person a tissue is a “Kleenex” and most cotton swabs are “Q-Tips.” Don’t get wrapped up in the name.
Wikis, blogs, forums, and KBs have similar goals. Sure, we can quibble about the minutiae, but at the end of the day it’s about making information available to someone other than the writer, author, or Subject Matter Expert. There’s no question that wikis are the rage. But that does not mean KBs will become extinct. Vendors that adapt and provide wiki-type democracy will deliver powerful next generation KBs that carefully incubate the viral growth of information “and” provide appropriate inoculation methods to ensure information remains beneficial and does not become a cancer.
I do agree in general with John’s recommendations regardless of your wiki intentions, especially assessing your current processes. Are they lethargic because of unnecessary checks and balances that target “golden content?” Is content ownership clearly defined? Do you know which content needs to be delivered to whom, and when, and in what context? And the list goes on and on.
So before you start Googling wiki tools, look first to the behavior wikis encourage and decide whether your company should move in that direction. Wikis are quite literally viral, and if you are unsure about your content or your processes, introducing wiki may start an epidemic.
Bob Peery
Director - Knowledgebase Product Management
Talisma Corporation
http://www.talisma.com
January 3, 2008 at 8:54 pm
Thanks for the thoughtful input Bob. Successful knowledge management is all about process, not technology, so I completely agree: if you have broken processes and your KB is poor as a result, buying wiki software won’t solve your problem.
January 8, 2008 at 3:07 am
John -
I think you’re on to a very important trend. And Bob Peery’s right too — it’s less about the technology and more about the process and incentive structures that have grown around wikis.
I’ve really gotten this between the eyes over the last six months. Again and again, as I’m describing Knowledge-Centered Support (a best practice for knowledge management), people have been interrupting me to say, “oh! it’s like a wiki!”
They didn’t mean it was like a specific brand of wiki software. Their intent was to say:
- It’s inclusive — people who have knowledge to contribute are encouraged to do so
- It’s self-maintaining — users take collective responsibility for keeping information accurate and up-to-date
- It’s dynamic — topics flourish, expand, and die out based on what users need
- It’s transparent — barriers between “users” and “producers” blur, and people contribute based on knowledge and reputation
I believe wiki software generally does a better job of supporting these social characteristics than traditional KB vendors do. And traditional KB vendors are much better at search / navigation, portals, and CRM integration than wikis are.
I hope we’ll soon see software that supports “wiki-style” interactions with all the support muscle that the KB vendors have invested so many engineer-years into building.
Best,
David Kay
DB Kay & Associates
ps - I’ve put my time where my keyboard is — I’ve launched an open source wiki-based project called osKCS. It’s a KB that’s built on MediaWiki and Lucene (the platform used by Wikipedia). It was recently KCS Verified, and is going into production at its first SSPA member site next month. dbk
January 9, 2008 at 4:18 pm
Hi David;
Thanks for chiming in on this topic. Glad to see KM and KCS gurus involved!
–John
January 10, 2008 at 8:33 pm
[...] Will Wikis replace the traditional KB for Web self-service? « Ragsdale’s Eye on Service some useful points on introducing wikis into the enterprise. As ever, it’s more about culture, processes, and people, rather than technology. (tags: wiki Blog Tools example eGovissues enterprise2.0) [...]
January 18, 2008 at 7:25 am
John,
Finally - free from the constraints and ready to speak my mind
I think you are making a very interesting point, and I think that some of your previous comments are right on target — it is more process than technology.
Yet, the main problem seems to be absent. Wikis require, nay - demand, talent willing and ready to contribute. If you don’t have more than a couple of people contributing, then it becomes as outdated and low-value as an out-of-date KB. The real value comes from the challenge-and-response process of bringing together all the collective knowledge existing in the world about a topic (OK, maybe that is just a tad too much… but certainly as many SME as possible)
The issue is not technology or process, those are certainly needed, but with Wikis the issue is gathering the right people to come in and contribute, creating sufficient freedom that they feel like they can contribute, yet reigning in the content so you DO have some level of control. This is the key challenge — and technology or process cannot do much about it. It is the people and the way to put in place the right incentives for them.
That is your weak link. Everyone in this blog and comments would agree with you on on either the technology or the process — yet, without the people management there is not much that can be done.
Am I wrong? no problem… but I think that the issue needs to be raised before we see forums, communities, Wikis - and the whole concept of collaborative customer service work its way up.
Esteban
PS: three years I wrote a note where I discussed this exact same topic: the role of people in the collaborative customer service space… and I have not seen more than head-nodding so far in this matter (maybe some finger-wagging and tsk-tsk’ing… but not much more than that)
January 18, 2008 at 2:35 pm
I’d like to hear thoughts on what Esteban brings up. I think this is crucial for any business that wants successful collaboration.
Wikis appeal to me and the other technical staff at our company. But so do KBs, forums, etc. We’re not hesitant about learning a new technology. And we also tend to dominate the contributions to the tools our company uses today.
As we move forward, we want to see contributions from ALL employees, including non-technical staff. Some of our department heads won’t buy into the tools we currently use because they feel the learning curve is too steep. And so the entire company (and ultimately our customers) loses out on the knowledge and perspective those folks bring.
Right now, I’m amazed at how little effort most wiki tools seem to put into managing content for authors. Sure, the WYSIWYG editors are great but they’re almost expected at this point. Businesses that adopt wikis aren’t looking to recreate WikiPedia- their scope is much more focused. As a result, their wikis will be scaled much smaller.
In those cases, why not attract users by improving the services that the wiki provides to authors. Parsing pages and suggesting links to existing pages is a great feature. Would it be accurate to estimate that authors want to spend 99% of their time writing the content and less than 1% thinking about and adding all the links to other topics that might or might not exist? Imagine how often you would use email if after you finished your message you had to look up IP addresses for the recipient’s email server.
I can understand that at some point content management affects performance so adversely that it is no longer feasible. But there has to be a sweet spot (maybe several thousand pages - or more) below which the tools can provide another layer of services. It’s these services that could create critical mass by expanding the userbase and really make wikis a killer business app.
January 18, 2008 at 3:52 pm
Wow! I’m a big fan of Esteban’s and am quite chuffed to see him chime in.
I couldn’t agree more on the people part, after all, the content is only as good as the contributors. When you have a wiki about the latest episode of Survivor, this isn’t a big issue. Everyone’s opinion counts. But obviously when you are describing best practices for technology, some contributors are in a better position to speak as a SME.
Fortunately, many of our SSPA members are B2B technology companies with an exisitng community of customer experts–the ones named in service contracts as the owner of the implementation, so they are in effect ‘pre screened’ for the most part. Companies like Novell with designated customer SMEs for each product on discussion forums will have an easier time introducing wikis and having both high levels of participation and high quality content.
It all seems much riskier in the consumer world. I may think I’m qualified to provide tech tips for my iPhone, as an example, but I could be completley wrong (and I personally find the iPhone highly un-intuitive). That’s where the process part comes in–having enough publishing rules to make sure someone is overseeing content before it becomes embeddeed as truth. Or else we end up with Colbert’s ‘truthiness’ concept running technical support wikis.
John Merritt makes an excellent point about having content be instantly classified, tagged and contextual, without authors spending hours doing manual tagging and linking. I’d like to think that some solutions (Knova is a good example) will have good enough search technology to automate some of this, but I’ll start asking this question in my next round of briefings with wiki vendors.
I definitely don’t have all the answers here–it is still very early days in the wiki-world. But conversations like this are a great way to learn, and to point out challenges to think through before jumping into the pool.
Thanks for reading and commenting!
January 25, 2008 at 4:02 pm
KB will not go away!
This is certainly a very interesting thread. I am not sure if the 4% difference in SSPA Benchmark has any statistical significance because the survey respondents can be at least 20% different year over year. If the measure is based on the question #81 . “….successfully find the answer they are looking for?” in the questionnaire, different organizations may measure “success” differently as well.
It is true that process is more important than technology. But MARKET DYNAMICS is even more important. One of the key benefits of KB is cost cutting. Focusing on creating 20% of the answers to 80% of the questions is just a powerful value proposition! Capabilities such as FAQs and workflow will continue to drive vendors to invest in KB because there is ROI in deflecting calls.
Forums on the other hand exist when there is a critical mass of interested users of products and services. So, Forums should be more successful in consumer goods. Young high-tech companies use Forums to provide support because they have to spend a lot of money on R&D. A good example is the GPS industry and forums for Garmin and TomTom. However, Forums may not work well in B2B business models or with companies with a small customer base and a lot of SKU’s in diverse product lines because there will not be enough interested parties.
As John mentioned Wikis are usually started internally. Wikis may not fit the above business model neither because of economics and the potential loss of control from a vendor’s perspective.
The key decision makers in investing in these tools are businesses but not individual consumers. Their ROI and effectiveness of serving their corporate objectives and customer needs will dictate the success of each tool. I still think KB has its place for many years to come just because vendors will want full control of its official answers to customer questions and use the opportunity to cross-sell and up-sell.
February 19, 2008 at 10:40 am
Can we say that opening up a KCS-enabled knowledge base to the community is equivalent to wiki?
I was seeing wiki (for support) related to content like manuals and best practices (how-to) rather than for problems.
February 19, 2008 at 3:55 pm
Equivalent to a wiki? It depends on the knowledgebase. Some KB vendors (KNOVA is a good example) supports customer discussions/collaborations on each KB article–which is getting close to a wiki. But just opening up a KB for customer access doesn’t replicate a wiki. Customers need to be able to discuss, comment on, and submit edits to each KB article to really deliver a wiki equivalent.
I agree with your assessment that manuals and best practices are obvious fits for this environments. Problems can work too, especially for communities with lively discussion forums in which customer problems are discussed and resolved…and migrated to a wiki.
March 30, 2008 at 5:19 pm
In fact, problems and how-to knowledge are the best fits for wiki-style or KCS-based approaches. This kind of information is so dynamic that the continuous improvement enabled by many eyes and many hands is crucial, while perfect grammar and document design is far less important.
It’s formal documents like manuals that are less suited to just-in-time approaches. The question is, how long will formal manuals exist in our business?
I agree with John that forums + KB != wikis. I think we have much to learn here.