Common Craft Blog
Wiki This- A Model for Customer Support Using Blogs and Wikis
By leelefever on May 03, 2005 - 11:38am
Blogs and message boards both suffer from the same problem- they are great for presenting emerging information, but poor at organizing it for future reference. The “good stuff†that people often need and companies often want to capture quickly gets buried among all the comments and messages.
You could say that blogs and message boards are good at managing flows, but poor at managing stocks.
With this post, I’m outlining a potential way organizations can use blogs and message boards as a way to generate useful information and a wiki as a way to filter, archive and organize it for future reference.
The graphic below represents the two-way communication occurring between employees and customers at companies like MacroMedia and Microsoft.
These companies are using blogs and message boards to interact with customers regarding their products on an ongoing basis. Often valuable feedback is provided via these resources but as long as it remains in the blog or board, it is quickly buried. The rest of this post focuses on how a wiki could remedy this situation. Not familair with wiki? Read this.
Below is a high level model for how a wiki could be used to capture the most pertinent information posted to blogs. In this case, employees and support staff act as filters, plucking out the best information for the wiki.
The blogs get the conversation started and comments keep it going. Throughout the process, support team members, employees or the bloggers themselves look for emerging and valuable information that should be archived in the wiki.
In the situation above, a few key things need to be in place:
- Everything needs a permalink- every comment, every message. This makes easy referencing possible.
- Everything should be RSS enabled. This makes the flow easier to manage.
- The company's representatives must keep up with the flow – this means collectively watching every post and comment via RSS.
- A convention for using the wiki- a plan for how to collectively manage it on an ongoing basis
- Efficient Information Management: An efficient way for the support team to move pertinent information from the blog to the wiki.
Building on the last point, time is of the essence. Humans play a central role in this process and there has to be a way to make it easy for a person to move valuable information into a wiki. Here’s one way I see that working:
Adding the “Wiki This†link (only visible to company reps) provides a means for moving information to the wiki by copying information to their clipboard (or a specific location) with one click. A support person would just click the “wiki this†link and quickly place the information in an appropriate wiki page- perhaps a holding pen for future organization.
Managing the Wiki
Obviously, this is still a somewhat manual process. People will have to take time to pluck out the information and organize it in the wiki. I see a few ways to manage this:
Holding Pen: On a daily basis, the team would have a holding pen where team members would dump the information they pluck out of discussions and blog posts. Then a person or team would synthesize that information into wiki pages and more static support resources.
Group Editing: Given a defined convention, the support team could work together to organize the wiki on an ongoing basis. As they pluck information out, they would quickly reorganize the wiki to include their addition.
Ratings or Nominations: The support staff could also use a nomination or ratings system that would enable the candidate wiki postings to be easily collected.
Tags: As the support folks add information to the wiki, perhaps they can tag it with a few key words that can bind the plucked posts/comments together.
Taken a step further, the wiki (or Wiki This! ability) could also be opened to the customers. This would bring the valuable perspective of the customer into the mix, potentially creating more relevant and powerful wiki archives.
While this is not a new concept, I hope that it will provide food for thought for those wondering about possibilities for how blogs and wikis can work together.
For me it’s all about matching the tools to their strengths- blogs are great for managing the flow and wikis are great for managing the stock and any combination of the two should play from these strengths.
Wiki This- A Model for Customer Support Using Blogs and Wikis
Hi Lee, thanks for the article, I'll pass it around.
Such filtering/distillation already takes place at Macromedia, although not as a wiki deliverable. (Wikis have been tested in the past, mainly for high-profile single events like a product launch... that multi-author convergent wiki process is a little different from the single-author divergent filtering process, where datapoints precede patterns.)
One of the goals in your piece is to get pertinent customer comment in to internal decisionmakers in a timely fashion, true...?
jd/mm
Wiki This- A Model for Customer Support Using Blogs and Wikis
Thanks for the comment John! I would say that there are a couple of goals. My goal in writing the piece was to get it into the world and hear from people like you about how it might/might not work in the real world.
The primary goals of the process I describe would be a persistent feedback loop for the decision makers and a timely support resource for customers.
My hope would be that the wiki would be a place for stakeholders to see a distilled version of what is happening/being said on the front lines of support each day or over time.
I could also see the same being true for customers looking for pertinent answers/solutions.
Wiki This- A Model for Customer Support Using Blogs and Wikis
Understood, thanks. Bounceback thoughts:
-- From what I've seen, internal stakeholders prefer to see patterns backed up by datapoints, rather than raw datapoints themselves... that practice of distilling patterns seems to be the big bottleneck.
-- External stakeholders have a problem here too, because they don't have a quick'n'easy way to see what internal stakeholders have come to see. For wishlists and other feedback routes there's a persistent "black box" problem: "I have a feeling no one ever reads these requests." Having a public-facing aspect to the feedback loops would help, but risks feeding-back on itself.
It's not only "how can you listen", but also often "how can you *prove* you listened". It's a hard problem, and I appreciate that you're thinking about it too.
tx, jd/mm
Wiki This- A Model for Customer Support Using Blogs and Wikis
Hi Lee,
I bumped into your blog a month ago while doing some research on using blogs in business...and now I'm sold!
What you've just described in this post is extremely relevant to new ways (well, to me anyway) in which we could apply the power of a community of practitioners and experts to learning (KM) in the entreprise. I'm sure billions of papers have been written on the subject. But it would make a great employee facing tool.
Typically we suffer from:
- poor knowledge dissemination, particularly from one project to the next
- 'lessons learned' done at the end of a project when (a) most of the good stuff is forgotten, (b) most people couldn't care less (for those that are still around!), too busy looking for the next job and (c) the knowledge rarely gets added to a pool of knowledge that can easily be re-used by the next guy.
What you offer here is a very powerful and elegant way to solve this conundrum (...not sure what that word means, but it sounds cool ;-P)
Wiki This- A Model for Customer Support Using Blogs and Wikis
Lee, as I told you elsewhere I think this is a brilliant bit of synthesis. I was planning to write a big response on my blog explaining how this model could work with purple numbers, but I've spent my mojo for that engaging Adina in similar discussions that may be relevant:
http://www.burningchrome.com/~cdent/mt/archives/000387.html
The bit I wanted to add to this discussion was this:
Above you mention that content in the flow could be automatically brought into the clipboard of the user for emplacement (via paste presumably) in the stock.
Granular identification and referencing systems like purple numbers could make it possible to reuse (by reference) the content in the flow, not copy it.
Wherever the original content is reused (and it could be easily reused multiple times), a link back to the source would be available, providing valuable context.
If the referenced content in the flow changes, the views of it in the stock update as well.
Wiki This- A Model for Customer Support Using Blogs and Wikis
I'm glad you brought that up Chris. I could see Purple Numbers being an almost necessary part of the equation. I *really* like the idea that when something in the flow changes (like an edited weblog post) that the corresponding stock (like a wiki page) could be updated simultaneously. It's a lot like version control on a small level- and something I didn't consider before. Thanks Chris!
Wiki This- A Model for Customer Support Using Blogs and Wikis
I've had similar conversations about blogs with several colleagues over the past few months. I can see the value of blogs for customer support, but there are other tools that have been around longer that still may work better than a blog/wiki. I've been doing 'volunteer' product support for the past 5 years with user groups (on Yahoo) and maintain their associated FAQs. The groups have grown in size to thousands of users. In several cases, I do it for products I helped to design. I use the term 'user group', but I realize some call them bulletin boards, discussion groups, etc.
Eventually, every support-related question that can be asked about a product will be asked. The FAQ is necessary just to keep the sanity of the readers and maintainer of the user group. Otherwise, you get too much repetition and users will check out or start complaining.
The nice thing about user groups is that they don't necessarily require a main author, like a blogs generally require, and so the most frequently asked questions will bubble to the top since they are user-initiated. And you can also get the benefit from users-helping-users, which I've not seen in the case of blogs yet. Also, once a blog scrolls off the end of a page, it seems lost to the world despite being archived and permalinked-enabled. It's almost like a newspaper from that standpoint. So your comment about blogs 'flowing' is right on.
Wikis seem like they need a lot of managing because they can be co-opted if someone wants to over contribute and take them off course by adding extraneous material. And I'm sure that a lot of the user-contributed material needs editing to make it comprehensible. I notice a certain kind entropy that occurs when too many authors get to contribute to a knowledgebase. This effect can be mitigated, like you mention, with a dedicated team of editors who moderate and manage the wiki content. But finding these saintly people...that can be a challenge.
I'm always looking for better ways to do product support and if someone comes up with a system for doing it using an integrated blog/wiki, I'd certainly like to check it out.
-Lee Devlin
Hello people
Peace people
We love you
Here is our contribution for - A Model for Customer Support
Hello everyone!
Providing a customer support for a satisfied clientele is an endless journey and everyone is trying to play their respective roles wisely to end up with satisfied clientele with the provided support so the support model may vary in this regard.
Providing customer support thorugh blog can prove to be another step forward for a fruitful online customer stay ever, imagin what a difference it could make if the same support is provided right then and there where the customer has stepped in ( home page).
The idea is to put a human touch, a warm welcome, a feeling that they are being heard, to qualify and to provide solution. save customer' s time and efforts to go through all the information in order to locate just one and much more which we have learned from putting ourselves in customer's shoes and the result is a higher percentage of satisfied clientele through live chat support and this is what everyone is striving for... isnt it?
Live Harry
http://www.liveadmins.com
I didn't see this article
I didn't see this article before now but what you are talking about is exactly what we did at Cisco.
http://supportwiki.cisco.com
We have a team that moderates the wiki but one of the things that I did when I was designing this wiki was to layout all of our products and technologies before hand so we could attempt to keep order in the wiki.
Also, the real magic of this wiki happens on the backend. We built and are still building tools to moderate this wiki automatically. We have developed a whole set of next generation analytics just for this purpose.
Please email me if you would like to discuss further I would be more than happy to give you demo of this and some internal wiki systems I've designed.
Good example
I've gone through many Wiki's to set up in order to decide of the best way to provide FAQ to my users and I've got to say that cisco support does look great. I'll try to find a way to make a smaller version of that for my users.
Thanks.