"Wiki This" - Un Modèle pour le Support Client Utilisant des Blogs et Des Wikis
Les blogs et forums de discussions souffrent tous deux du même problème – ils sont parfaits pour présenter l’information émergente, mais pauvres pour l’organiser à des fins de future référence. Les “bonnes choses” dont les personnes ont souvent besoin et que les sociétés veulent souvent saisir rapidement, se font ensevelir parmi tous les commentaires et messages.
On pourrait dire que les blogs et forums de discussion sont bons pour gérer des flux, mais pauvres pour organiser les stocks.
Avec ce billet, j’esquisse un schéma potentiel sur la manière dont les organisations peuvent utiliser les blogs et les forums de discussion comme un moyen de générer de l’information utile et un wiki comme un moyen de filtrer, archiver et organiser l’information pour une référence future.
Le graphique ci-dessous représente la communication à deux sens se déroulant entre les collaborateurs et les clients de sociétés comme MacroMedia et Microsoft.
Ces sociétés utilisent les blogs et forums de discussion pour interagir avec leurs clients pour tout ce qui concerne leurs produits sur une base continue. Des échos souvent valables sont fournis via ces ressources mais tant qu’ils demeurent dans le blog ou le forum, ils se font rapidement ensevelir. Le reste du billet se concentre sur la manière dont un wiki pourrait remédier à cette situation. Pas encore familier avec wiki ? Lisez ceci.
Ci-dessous un modèle de haut niveau sur la façon dont un wiki pourrait être utilisé pour saisir l’information la plus pertinente postée sur les blogs. Dans ce cas, les employés et le personnel responsable du support agissent comme des filtres, extrayant la meilleure information pour le wiki.
Les blogs ramassent les conversations démarrées et laissent se poursuivre les commentaires. Tout au long du processus, les membres de l’équipe support, les collaborateurs ou les blogueurs eux-mêmes regardent l’information émergente et valable qui devrait être archivée dans le wiki.
Dans la situation ci-dessus, quelques points-clés ont besoin d’être mis en place :
- Tout a besoin d’un lien permanent, chaque commentaire, chaque message. Ceci rend tout référencement facile possible.
- Tout devrait être possible à mettre en RSS. Ceci facile l’organisation du flux.
- Les représentants de la société doivent aller aussi vite que le flux – ce qui signifie regarder collectivement chaque billet et commentaire via RSS.
- Une convention pour l’utilisation du wiki – un plan sur la manière de gérer collectivement sur une base continue.
- Gestion Information Efficace : un moyen efficace pour l’équipe support de migrer l’information pertinente du blog vers le wiki.
Pour construire ce dernier point, le temps est l’essence. Les humains jouent un rôle-clé dans ce processus et il doit exister un moyen facile pour une personne de jouer un rôle central dans ce processus et il doit exister un moyen facile pour une personne de migrer l’information valable à l’intérieur du wiki. Voilà un moyen dont je vois cela fonctionner :
Le fait d’ajout le lien « Wiki This ” (seulement visible en interne pour les collaborateurs de la société) fournit un moyen de migrer l’information vers le wiki en copiant l’information vers leurs presse-papier (ou un endroit spécifique) en un-clic. Une personne du support cliquerait simplement le lien “wiki this” et placerait rapidement l’information dans une page wiki appropriée – peut être un stylo à à tenir pour l’organisation future.
Organiser le Wiki
Évidemment, c’est encore en quelque sorte un processus manuel. Les gens devront prendre le temps de cueillir l’information et de l’organiser dans le wiki. Je voix quelques manières de gérer cela :
Prise du Stylo : Sur une base quotidienne, l’équipe aurait un stylo de gestion où les membres de l’équipe déchargeraient l’information qu’ils cueilleraient dans les discussions et les billets de blogs. Puis une personne ou une équipe synthétiserait cette information à l’intérieur de pages wikis et de ressources de supports statiques.
Édition de Groupe : Compte tenu d’une convention donnée, l’équipe support travaillerait ensemble pour organiser le wiki sur un processus continu. Au fur et à mesure qu’ils cueillent l’information, ils la réorganiseraient rapidement pour y inclure leurs ajouts.
Évaluation ou Nominations : Le personnel responsable du support utiliserait aussi un système de nomination ou d’évaluations qui permettrait aux billets candidats pour être postés sur le wiki d’être facilement collectés.
Mots-clés : Parce que l’équipe du support ajoute de l’information au wiki, peut-être peut-t’elle la taguer avec quelques mots-clés qui peuvent être liés avec les billets cueillis et les commentaires.
Pour aller un peu plus loin, le wiki (ou la capacité du "Postez Vers Wiki") pourrait être aussi ouverte aux clients. Ceci amènerait la perspective intéressante de faire entrer le client dans le mix, et de créer potentiellement des archives wiki plus pertinentes et plus puissantes.
Même si ceci n’est pas un tout nouveau concept, j’espère que cela fournira de la matière pour tous ceux qui réfléchissent aux possibilités de faire fonctionner les blogs et wikis ensemble.
Pour moi, tout cela ne fait qu’utiliser les points de forces des outils – les blogs sont géniaux pour organiser les flux et les wikis sont géniaux pour organiser les stocks. Toute combinaison des deux ne fait que jouer avec ces forces.
Message Original Posté le 3 mai 2005
Commentaires (non traduits)
Hi Lee, thanks for the article, I'll pass it around.
Un tel filtre/distillation est déjà en place chez Macromedia, même s'il n'est pas délivré sur wiki. (Les wikis ont été testés dans le passé, essentiellement pour des événements ponctuels de haut niveau comme un lancement produit... où un processus wiki convergent multi-auteurs est un peu différent du processus de filtrage divergent à auteur unique, là où les points de données précèdent les modèles).
Un des objectifs dans ton article est d'obtenir des commentaires clients pertinents ordonnés dans le temps, n'est ce pas ?
jd/mm
Commentaire de John Dowdell le 3 mai 2005 03:18 PM
Merci pour le commentaire John ! Je dirais qu'il y'a deux objectifs ici. Mon objectif au moment d'écrire ce billet était de rentrer dans le monde et d'écouter les gens comme toi à propos de ce qui pourrait/ne pourrait pas fonctionner dans le vrai monde.
Les objectifs essentiels du processus que je décris serait d'obtenir une boucle de rétroaction persistante pour les prises de décision et une ressource support dans le temps pour les clients.
Mon espoir serait que le wiki devienne une place destinée aux stakeholders pour y voir une version distillée de ce qui arrive/ce qui s'est dit sur les lignes de front du support chaque jour ou au fil du temps.
J'imaginerais aussi que la même chose soit vraie pour les clients à la recherche de solutions/réponses pertinentes.
Commentaire de Lee le 3 mai 2005 03:39 PM
Compris, merci. Quelques pensées à chaud :
-- De ce qu'ai vu, les stakeholders externes préfèrent voir des modèles sauvegardés par des points de données, plutôt que des points de données brouillon... cette pratique de distiller les modèles semble être le gros goulot d'étranglement.
-- Les stakeholders externes ont aussi un problème ici, parce qu'ils n'ont pas un moyen rapide et facile pour voir ce que les stakeholders internes sont venus voir. Pour les listes de souhaits et autres routes de rétroactions, il existe un problème persistant de "boîte noire" : "J'ai le sentiment que personne ne lit ces demandes". Offrir un aspect à visage ouvert vers les boucles de rétroaction aiderait, mais présente des risques de se remplir sur lui-même.
Ce n'est pas uniquement "comment pouvez vous écouter", mais aussi souvent "comment pouvez-vous *prouver* que vous m'avez écouté". C'est un problème difficile et j'apprécierais que tu puisses aussi y penser.
tx, jd/mm
Commentaire de John Dowdell le 5 mai 2005 02:48 PM
