Utiliser la data pour améliorer une knowledge base

Utiliser la data pour améliorer une knowledge base

L’idée

Comment améliorer une Knowledge base de manière pragmatique.

C’est à dire en se basant sur des pistes concrètes qui vont réellement avoir un impact (au lieu de brainstormer des “On pourrait”).

0️⃣ Le but du jeu n’est pas de “lister ce qu’on pourrait mesurer”

On pourrait mesurer….

  • le temps passé sur le site
  • le nombre de vues
  • l’ordre dans lesquelles les pages sont vues
  • le…

Non. 

Tout ça, c’est de la data pour avoir de la data. L’équivalent de faire du contenu pour faire du contenu.

On ne mesure pas pour le plaisir. On mesure parce qu’on veut faire bouger les choses. On veut comprendre ce qui se passe. Détecter des freins ou des problèmes qu’on peut résoudre.

Et pour ça, il faut une approche réfléchie.

Pas mesurer ce qui te vient en tête en espérant que tu vas avoir un declic en regardant la data.

Tu risques trop de (1) te limiter à la data que tu as déjà et (2) de mesurer des vanity metrics (= de la data qui fait plaisir mais qui ne sert à rien).

1️⃣ Pars de l’objectif

Pourquoi est-ce qu’on a une Knowledge base déjà ?

A quoi elle sert ? Quel résultat on veut atteindre ?

Prenons l’exemple classique : SaaS qui permet aux entreprises de gérer facilement leur comptabilité. 

Objectif
Répondre aux questions des clients

Pourquoi on lance cette base de connaissance ?

Parce qu’on veut absorber un maximum de questions que peuvent nous poser nos clients.

On veut que les clients soient plus autonomes, donc plus épanouis.

Et “moins de questions à traiter par les équipes”, ça veut dire qu’on va pouvoir gérer plus de clients sans être contraints de recruter de manière démesurée juste pour garder le rythme.

2️⃣ Quantifie l’objectif

A quel point est-ce qu’on tient à absober les questions de nos clients ?

Combien en reçoit-on chaque mois ? ll faudrait en absorber combien pour que ce chiffre devienne acceptable ? D’ici quand ?

3️⃣ Identifie ce qui doit se produire pour atteindre l’objectif

Qu’est-ce qui coince ? Pourquoi on est pas à l’objectif aujourd’hui ? Qu’est-ce qui  nous manque ? Qu’est-ce qu’on pourrait aller chercher ?

Cette étape demande des efforts sérieux. Il faut vraiment que tu te poses sur le sujet. Que tu taches de comprendre ce qui ne va pas, pourquoi, ce que l’on peut faire pour y remédier.

Ca demande de l’audit, des interview, du benchmark et de la réflexion.

Reprenons notre exemple.

On retourne la situation dans tous les sens, et au final, on se rend compte que…

Pour qu’un ticket soit absorbé, il doit se produire 5 choses.

  1. Il faut que la question du client soit du type qu’on peut effectivement absorber grace à la base de connaissance. (S’il s’agit d’un bug ou d’une action que le client ne peut pas réaliser tout seul, une action pour laquelle il a besoin de passer par nous, on est coincé)
  2. Il faut que le client fasse l’effort de chercher la réponse dans la base de connaissance (S’il envoie directement un message à son conseiller, c’est mort).
  3. Il faut bien évidemment qu’on ait la réponse à cette question dans la base de connaissance.
  4. Il faut que cette réponse soit simple à trouver. Via une barre de recherche, des catégories, un bot, une aide contextuelle dans l’app, etc.
  5. Il faut que cette réponse soit simple à lire et à utiliser (Si le client cherche comment faire un export, et qu’on lui balance un pavé théorique sur le fonctionnement de l’expot, c’est cuit).

Une fois qu’on a tout ça en tête, ce qu’il faut tracker est beaucoup plus clair.

Il y a plusieurs moyens possible dans cette situation (en fonction de ce que l’on est en mesure de tracker et de mesurer), mais voici un exemple.

Indicateur principal
Nombre de questions évitables reçues

Indicateur 1
Nombre de question évitables où le client n’a pas consulté l’aide

Indicateur 2
Nombre de question évitables où le client a consulté l’aide avant

Pourquoi ces indicateurs là ? Parce qu’on va pouvoir agir dessus (et mesurer dans la foulée si ce que l’on fait fonctionne).

Parenthèse

Cette info est beaucoup plus simple à tracker qu’elle n’en a l’air. Il suffit de deux mécanismes.

➡️ Chaque ticket doit être noté par le conseiller qui le traite (afin de flagguer les tickets “évitables”)

➡️ Il faut être capable de suivre les clients qui n’ont pas consulté la base de connaissance avant d’envoyer leur question.

Moyen tout bête pour ce faire : si les clients envoient leur questions via un formulaire de contact, il suffit de proposer deux liens différents vers le formulaire. 

  • L’un depuis les pages à l’intérieur de la base de connaissance
  • L’autre depuis les pages à l’extérieur de la base de connaissance

En ajoutant des paramètres UTM à la fin du lien, on peut récupérer l’info assez facilement et la passer dans le formulaire de contact.

4️⃣ A l’action maintenant

Une fois qu’on est capable de mesurer ces trois infos, on va pouvoir agir et améliorer sérieusement la base de connaissance.

➡️ L’indicateur principal (= nombre de questions évitables reçues) va nous servir de baromètre. On va le regarder chaque mois voire chaque semaine pour évaluer où on en est.

(Bien entendu, pourqu’il soit pertinent, il faudra l’utiliser en ratio, par exemple en le divisant par le nombre de clients à date ou le MRR)

Cet indicateur sera notre boussole.

➡️ L’indicateur 1 (= nombre de questions évitables ou le client n’a pas cherché) va nous aider à mesurer et à suivre notre capacité à résoudre le premier problème : les clients qui contournent la base de connaissance.

On va pouvoir brainstormer un maximum d’idées pour faire bouger ce levier, les mettre en place et mesurer leur efficacité.

  • Sensibiliser les clients pendant la phase de prise en main de l’outil
  • Message in app
  • Améliorer l’aide contextuelle
  • Détecter les clients qui vont avoir besoin de telle ou telle feature et leur envoyer proactivement un lien vers la fiche correspondant dans la base de connaissance
  • Revoir la stratégie du bot
  • Former les conseillers pourqu’ils puissent faire du nudger discret auprès des clients qui récidivent et n’utilisent pas la base de connaissance
  • Etc.

Voir, plus efficace encore : aller interviewer des clients pour comprendre pourquoi ils contournent la base de connaissance.

➡️ L’indicateur 2 (= nombre de questions évitables qu’on gère apparemment mal aujourd’hui) va nous permettre de nous focaliser sur le 2ème problème : les questions légitimes des clients que la base de connaissance gère mal.

On pourra alors creuser question par question (en faisant un export puis une analyse de toutes ces questions) afin de comprendre ce qui coince : 

  • On a pas l’information (= produire plus de contenu)
  • L’information est difficile à trouver (= améliorer la navigation et l’accessibilité)
  • L’information n’est pas claire ou utilisable (= optimiser la rédaction des contenus)