Knowledge base interne : par quoi commencer ? (Surtout quand on en a déjà une qui ne marche vraiment pas)

Knowledge base interne : par quoi commencer ? (Surtout quand on en a déjà une qui ne marche vraiment pas)

L’idée

Cas particulier : comment démarrer un projet de Knowledge base interne (= pour les équipes) dans une situation à problèmes.

C’est à dire…

  • Quand on a déjà un paquet de contenus en interne (généralement sur plusieurs supports)
  • Quand la thématique derrière le produit n’est pas simple (exemple type : SaaS très tech, juridique, ou compta)

Étape par étape

  1. Gérer la toute première conversation avec le n+x qui va mettre le sujet sur la table
  2. Gérer les conversations suivantes
  3. Résumons
  4. Quelques techniques pour éviter les bloquages
  5. Et ensuite ?

1️⃣ Gérer la toute première conversation avec le n+x qui va mettre le sujet sur la table

Ce sera peut-être plus clair avec un exemple. 

Imaginons qu’on travaille pour une SaaS qui permet de gérer facilement la comtpabilité de son entreprise. 

Le département CS est censé répondre aux questions les plus fréquentes des clients. Lorsqu’un ticket qu’envoie le client est trop compliqué, les conseillers au CS ont la possibilité d’escalader le ticket, c’est à dire de le transmettre à une équipe de spécialiste (les comptables et les développeurs quo ont conçu l’app) pour obtenir une réponse.

Voici deux manières différentes d’approcher cette conversation :

Celle de Fred.

Et celle d’Elisa.

L’une d’elle va dans le mur. Laquelle d’après toi ? 

L’approche de Fred

“Le manager – Fred, on a besoin de mettre en place une nouvelle base de connaissance en interne. Les conseillers au CS galèrent à répondre aux clients. Ils ne trouvent pas les infos dont ils ont besoin.

Entre toi et moi, c’est une grosse grosse priorité pour M. machin. Il nous attend vraiment là-dessus. Et on a pensé à toi, comme tu as l’expertise contenu.

Fred – Ok. Le projet m’intéresse. C’est vrai que c’est un retour que j’ai entendu plusieurs fois des équipes. 

D’après toi, qu’est-ce qui va pas avec la base de connaissance actuelle ? A chaud ?

Manager – Hum… Le gros plus problème, c’est qu’elle n’est pas à jour. Le contenu s’est accumulé avec le temps. Chacun a fait ça dans son coin. Je pense qu’on a de contenus à plusieurs endroits : sur l’intranet, dans le Trello, dans le Notion, dans le CRM… Personne ne gère le sujet. C’est un énorme gaspillage : on a des tonnes de contenus mais les équipes ne peuvent pas s’en servir.

Fred – Je comprends. Je vais avoir besoin d’examiner les contenus que l’on a, pour comprendre ce qui ne va pas. En termes de timing, vous aviez quoi en tête à priori ? Sans parler d’une deadline, qu’est ce que tu imaginais à chaud ?

Manager – L’idéal, ce serait qu’on présente la nouvelle Knowledge base pendant le prochain séminaire de juillet. Ca te parait faisable ?

Fred – Hum… On doit pouvoir sortir quelque chose d’ici là. Au moins une V1. Ecoute, laisse-moi un peu de temps pour auditer les contenus que l’on a déjà. Je nous cale un point la semaine prochaine pour te tenir au courant de l’avancement et te proposer un plan.”

L’approche d’Elisa

“Le manager – Elisa, on a besoin de mettre en place une nouvelle base de connaissance en interne. Les conseillers au CS galèrent à répondre aux clients. Ils ne trouvent pas les infos dont ils ont besoin.

Entre toi et moi, c’est une grosse grosse priorité pour M. machin. Il nous attend vraiment là-dessus. Et on a pensé à toi, comme tu as l’expertise contenu.

Elisa – Ok. Le projet m’intéresse. C’est vrai que c’est un retour que j’ai entendu plusieurs fois des équipes. 

Pour être sure de bien comprendre… Le besoin derrière la knowledge base, c’est que les équipes ont besoin d’information sur le fonctionnement de l’app ? Ou sur les règle de la compta ?

Le manager – Hm… Un peu des deux en fait. Et j’ajouterais même un troisième : ils ne connaissent pas assez les process. Par exemple, comment on doit réagir quand le client nous fait telle ou telle demande.

Le point commun des trois, c’est qu’ils ne savent pas quoi répondre, alors ils escaladent le ticket au niveau supérieur, à la tech. Mais eux nont pas le temps de gérer.

Elisa – Je comprends. Donc, la prioirté numéro une pour ce projet, c’est de résoudre le nombre de tickets escaladés à tort, c’est bien ça ?

Le manager – Exactement. On est à 60% d’erreurs aujourd’hui, il faut qu’on descende sous les 15% avant juin.

Elisa – Ok. Ce que je te propose dans ce cas, c’est que l’on se pose 2 heures ensemble toi, moi plus un ou deux conseillers du CS. Je vais vous poser des questions pour identifier ce qui leur manque comme infos et dans quelles situations.

Une fois qu’on aura fait ça, on pourra très vite commencer à déployer des solutions.”

A ton avis, qui a le plus de chances ?

Pour moi, c’est Elisa.

Fred va droit dans le mur.

Erreur 1 – Fred prend pour argent comptant les hypothèses de son boss

  • “C’est un problème d’information. Les CS n’ont pas l’info.”
  • “Une base de connaissance va résoudre le problème.”
  • “On a déjà tous les contenus, c’est juste qu’ils ont dispersés et pas à jour.”

Erreur 2 – Fred démarre sur un projet sans objectif.

Elisa a un objectif clair : “Réduire le nombre de tickets escaladés à tort.”

Fred part sur : “Refaire la base de connaissance actuelle.”

C’est un cas classique de “Faire du contenu pour faire du contenu”, avec tous les problèmes que ça va entrainer.

Conséquence 1 – Fred n’aura aucun moyen de mesurer l’impact de son projet.

Ca va entrainer des conversations très difficiles avec son manager. Au final, le seul critère pour évaluer Fred et son projet, ce sera “A quel point le manager pense que Fred a fait du bon travail.”

Elisa, elle, va montrer la baisse du nombre de tickets escaladés par erreur. Et si jamais les chiffres n’ont pas bougé après la sortie de sa base de connaissance, elle pourra au moins aller regarder la data pour comprendre et expliquer ce qui s’est passé.

“Telle équipe ne joue pas le jeu : les réponses à ces questions sont clairement disponibles dans le wiki, mais ces conseillers là ont escaladés sans rechercher avant.Le problème maintenant n’est plus sur la base, il est sur le training des équipes.”

Conséquence 2 – Fred va se faire imposer des décisions toxiques pendant tout son projet

  • On pourrait faire une page sur…
  • Ha, il faut qu’on prévoit…
  • Je ne comprends pas. M. Machin avait suggéré en réunion qu’on fasse une page sur X. Pourquoi c’est pas dans le plan ?
  • Les équipes aimeraient bien.

Non.

Juste, non.

Tout le monde a des idées. Mais on ne construit pas un projet en fonction des envies de chacun ou des idées que quelqu’un a pu avoir sous la douche.

On construit un projet en choisissant les meilleurs morceaux : ceux dont on est sûr qu’ils vont avoir le plus d’impact sur le problème.

Elisa, elle, sera beaucoup plus sereine pendant son projet.

“Merci, ce sont d’excellentes idées ! Je les note précieusement. N’hésite pas à m’en  envoyer si tu en as d’autres. Pour la V1, on va se concentrer sur ces 10 sujets, car la data montre que ce sont les tickets sur ces sujets qui sont le plus souvent ecaladés par erreur. Mais je garde toutes ces idées pour la V2.”

Conséquence 3 – Fred va passer à côté de solutions qui auraient pu marcher

Le manager pense que le coeur du problème, c’est “Les équipes n’ont pas l’information”.

Mais on en sait rien à ce stade. 

Il faut qu’on discute avec les équipes. 

On va peut-être se rendre compte que, oui, une base de connassance va régler une partie du problème, mais une partie seulement.

Par exemple, on va se rendre compte que les procédures ne sont pas claires. Ce n’est pas que les équipes ne suivent pas les procédures…. C’est juste que ces procédures ne couvrent que quelques cas… Contrairement à ce que pense le manager, les CS doivent improviser 80% du temps.

Autre exemple : on va se rendre compte que, oui, les conseillers ont besoin d’information, mais sous forme de training, pas sous forme de base de connaissance. Les conseillers ont besoin de connaitre certaines infos par coeur, quand ils sont au téléphone avec le client. Ils ne peuvent pas prendre le temps d’aller chercher dans un intranet car ça les décrédibiliserait.

Fred et son manager vont s’arracher les cheveux, dans quelques mois, quand ils vont se rendre compte que le problème est toujours là malgré la nouvelle base de connaissance flambant neuve qu’ils ont sortie.

Elisa, elle, va se lancer dans le projet en sachant d’avance qu’elle va tacler seulement une part du problème. Et le manager pourra mettre d’autres personnes sur chaque autre problème relevé.

Conséquence 4 – La base de connaissance de Fred va être un fail

Fred part du principe qu’on a déjà tous les contenus en interne. Et qu’il s’agit juste de les auditer, de les actualiser et de les ranger.

Mais là encore : on en sait rien.

Si ça se trouve, 90% des contenus que l’on a déjà répondent à des questions que les équipes ne se posent jamais.

Parce que certaines équipes ont esayé de se lancer dans un Wikipedia de la comptabilité en interne. Et qu’elles ont commencé par les contenus génériques, facile à écrire. Ou par les contenus que les experts en interne ont jugé important.

“Ok, tu ne peux pas comprendre la compta si tu ne connais pas la comptabilité à l’italienne. On va commencer par ça.”

Fred va passer des mois à brasser des tonnes de contenus pre-existant, à les mettre à jour, à les ranger, à supprimer les doublons… pour se prendre un coup de massue dans quelques mois, quand il va se rendre compte que personne ne se sert de sa knowledge base “parce qu’elle ne répond pas aux questions”.

Elisa, elle, saura en moins de 48 heures si elle peut utiliser ou pas le contenu qu’elle a déjà.

Elisa – Hum, d’après la data, voilà les 10 sujets sur lesquels on escalade à tort le plus de tickets. 

Manager – On a déjà en interne du contenu sur les sujets 3, 6, 7, 8 et 10. 

Elisa – Tout à fait. Mais on ne va pas utiliser les contenus pour 3 et 8, car ils ne répondent pas aux questions les plus fréquentes. Ce sont plutôt des introductions au sujet. Il va falloir qu’on crée des nouveaux contenus, mais pas de panique, ça sera très simple.

2️⃣ Gérer les conversations suivantes

Reprenons l’échange d’Elisa là où on l’avait arrêté.

Alors que Fred s’est lancé tête baissé dans le “Comment va-t-on utiliser tous les contenus qu’on a déjà”, Elisa, elle, a obtenu 2 choses de son boss.

  • Un objectif
  • Un meeting pour creuser le problème (avec 2 représentants des principaux concernés)

Depuis cette première réunion, Elisa a récupéré 2 autres élements : 

  • La procédure en interne qui explique aux conseillers CS comment escalader un ticket
  • La liste des tickets qui ont été escaladés à tort le mois dernier, qu’elle a analysée pour sortir les principaux sujets qui ont générés des erreurs.  

Le jour de la réunion

Elisa accueille les participants, rappelle le contexte et projette (ou partage son écran).

Le support de la réunion va être un whiteboard virtuel ou un logiciel de mind map (Whimsical, Miro, peu importe). 

Elle commence par noter au centre l’objectif et la population concernée.

Puis elle creuse avec les participants pour comprendre quelles sont les étapes par lesquelles ils passent lorsqu’ils traitent un ticket.

Elisa creuse et pose d’autres questions pour comprendre ce qui se passe à chaque étape. Elle demande à l’un des deux CS de lui montrer avec un exemple réel. Elle challenge à coups de questions.

On finit par avoir une vue détaillée de ce que font les CS lorsqu’ils répondent aux questions.


Une fois ce travail fait, on peut entrer dans le vif du sujet : comprendre quelles sont les sous-étapes qui entrainent le plus de problème (et pourquoi).

Elisa va demander aux participants quelles actions, à leur avis, entraine le plus de problèmes (= de tickets escaladés par erreur). 

Si besoin, on va regarder la data ensemble (= la liste des sujets qui entrainent le plus d’escalade à tort), pour discuter sur la base d’exemples concrets.

Conseiller CS – Ha oui, les tickets “parce que le client n’a pas réussi à exporter une information”. Ca me surprend pas qu’il y ait autant de tickets escaladés à tort dans cette catégorie. On a pas de documentation en interne sur l’outil d’export et ce qu’il permet de faire. Très souvent, on les passe directement aux développeurs.

Manager – Je vais voir avec l’équipe tech s’ils ne peuvent pas nous assembler une petite documentation simple.

Conseiller CS – Tiens, cette catégorie là est surprenante : ‘La gestion de la facturation’. Ca, pour le coup, c’est vraiment un fondamental. Il faut que toutes les équipes sachent par coeur comment les traiter. Ce n’est pas normal qu’elle soit là.

Manager – On l’ajoute au programme pour la base de connaissance ?

Elisa – Attention, s’il s’agit d’une information que les conseillers doivent maitriser, il vaut mieux partir sur une formation. Il faut que les équipes sachent que c’est un sujet et qu’elles officiellement soient toutes formées au moins une fois. Si la formation est filmée ou écrite, on pourra l’ajouter dans la base de connaissance. Mais à ce stade, il faut une formation.

Etc.

Il va se passer deux choses pendant cette dernière partie.

De une, on va très vite identifier les problèmes qu’il faut tacler autrement que par une knowledge base.

De deux, on va pouvoir cerner beacoup plus vite les sujets à aller tacler par la knowledge base.

“Quelles sont les informations que vous avez besoin d’aller chercher pour apporter une réponse au client ?”

3️⃣ Résumons

Le but du jeu, c’est de passer de…

“Il nous faut une banque de connaissance”

à

  • “Voici l’objectif business qui est en jeu (= résultat mesurable visé + date)
  • Voici la population en interne qui est concernée (= sur qui on va travailler pour atteindre l’objectif)
  • Voici la série d’actions que cette population fait ajourd’hui
  • Voici les actions où ça coince aujourd’hui et pourquoi
  • Voici ce que l’on va faire pour chaque blocage”

4️⃣ Quelques techniques pour éviter les bloquages

Avant de terminer, trois tips sur les étapes qui peuvent éventuellement coincer.

Obtenir l’objectif

Dans l’exemple que je te donnais tout au début, la conversation sur l’objectif s’est faite facilement. Le manager d’Elisa avance de lui même les infos.

Du coup, on a pu commencer directement la réunion suivante avec un objectif clair.

Ce ne sera pas toujours le cas. 

Autre exemple où il faut creuser un peu, avec les questions qui permettent de le faire.

Elisa – Pour être certaine de bien comprendre la situation. Pourquoi est-ce que l’on veut une base de connaissance aujourd’hui ? (question 1)

Manager – L’actuelle ne marche pas. Il y a trop de contenus. Ils ne sont pas à jour. Les équipes ne trouvent pas l’info. On en parle depuis un moment. Etc.

(Le manager nous liste pour l’instant des éléments qui ne nous aident pas sur l’objectif business : il nous fait un diagnostique de ce qui ne va pas avec les contenus actuels. Ce n’est pas grave. Cette première question lui permet d’évacuer ces infos et de dire ce qu’il a besoin de dire.”

Elisa – Je comprends. Et donc, quelle est la conséquence principale que ça a sur le business ?

(Si le manager bloque sur la réponse, ne pas hésiter à lui tendre des perches. “C’est que les équipes mettent trop de temps à répondre ? Que les réponses sont fausses ?”. Mais lui laisser le temps de réfléchir avant.)

Manager – Il y a trop de tickets escaladés par erreur. Les équipes mettent trop de temps à répondre à chaque ticket. La qualité des réponses varient trop d’un conseiller à l’autre.

(Variante de question. “Imaginons, on est dans 6 mois, on a terminé le projet. Les résultats dépassent nos espérances… quel est le chiffre clé que tu vas communiquer à la direction pour leur montrer l’impact du projet ?”)

Une fois qu’on a trouvé l’indicateur, il faut voir avec le manager quelle amélioration on veut aller chercher. 5% ? 50% ? 75% ? D’ici quand ? 3 mois ? 6 mois ? 1 an ?

💡 Si le manager bloque à ce stade et n’arrive pas à se prononcer, je recommande de lui donner un exemple d’objectif volontairement dérisoire pour le faire réagir.

Manager – Je ne sais pas du tout ce qu’il faut qu’on vise.

Elisa – Ok. Si je te dis, “on baisse le taux de tickets escaladés par erreur de 60% à 50% d’ici un an”. Est-ce que ça te parait un bon objectif ?

Manager – Bah non, pas du tout. C’est beaucoup trop peu. On ne vas pas viser le 0%, parce qu’on y arrivera jamais, mais il faut au moins qu’on descende à 15%. Et on ne peut pas attendre un an. Il faut qu’on ait des résultats en juin.

Obtenir la data

Pour gérer sereinement son projet, Elisa va utiliser de la data.

Dans son cas, la liste des sujets ou des questions de clients qui entrainent une escalade fautive. 

Comme on la vu plus haut (les 4 conséquences), cette data va être indispensable pour que le projet se passe bien : qu’on tacle les bons sujets et qu’on crée des contenus utiles.

Récupérer la data est beacoup plus simple qu’il n’y parait, quelle que soit la taille du département ou sa maturité sur le sujet data.

Mode d’emploi par ici : “Knowledge base / Training : comment identifier les sujets prioritaires ?” 

Knowledge base ? Ou formation ?

Lorsqu’Elisa rentre dans le vif du sujet et qu’on regarde quelles actions bloquent aujourd’hui, il va falloir être prudent.

Une knowledge base ne remplace pas du training. Et du training ne remplace pas une knowledge base.

Ce sont des outils différents pour répondre à des besoins différents.

Mode d’emploi par ici : “Knowledge base ou Formation ?”

5️⃣ Et ensuite ?

Une fois qu’on a…

  1. L’objectif
  2. La population concernée
  3. La série d’actions que cette population doit faire
  4. Les actions où ça coince aujourd’hui
  5. La solution pour chaque blocage (training, knowledge base, autre)

…on a logiquement le périmètre de la knowledge base. “Pourquoi on veut une” et “Quels types de questions elle va régler”.

On devrait donc pouvoir très vite se mettre d’accord sur un backlog : une liste priorisée du contenu que l’on veut avoir dans la knowledge base.

Le reste ? C’est du content management archi-classique pour obtenir l’information, produire les contenus, les publier, les maintenir, etc.