Knowledge Base : identifier les contenus dont ont le plus besoin les équipes

Knowledge Base : identifier les contenus dont ont le plus besoin les équipes

L’idée

On sait qu’on a besoin de training ou d’une base de connaissance. Maintenant, comment savoir quel sujets et quels contenus il faudrait tacler exactement ?

Evidemment, “quels contenus”, mais de manière pragmatique. On pas là pour lister “tous les sujets sur lesquels on pourrait faire un contenu”.

Le but, c’est d’aider les équipes et de les rendre plus efficaces.

Point de depart

Si tu as suivi la méthode (pour être certains que la formation ou la base de connaissance est bien la bonne solution), tu as normalement…

Un objectif business clair qu’on veut tacler grace à la formation ou la base de connaissance… “Réduire le nombre de tickets escaladés par erreur…
… l’équipe concernée …par les conseillers CS…
…un niveau de résultat. …de 60% à 15%…
…avec une échéance… …d’ici juin.

Ce point de départ est vital.

Sans lui, c’est impossible de continuer. On va tomber dans le “faire du contenu pour faire du contenu”.

En revanche, une fois que tu a ces informations, tout coule de source. Il suffit de continuer à creuser : 

  • au mieux avec de la data
  • au pire par des interviews.

1️⃣ Avec de la data

Une fois qu’on a un problème clair (exemple : “trop de tickets sont escaladés par erreur”), la suite devient très facile. 

Il suffit de se demander : “Quelle source de données peut-on examiner pour voir objectivement les tickets de nos clients qui causent le plus souvent ce problème ?”.

Dans notre cas, c’est plutôt simple.

On a besoin de la liste des tickets envoyés par les clients qui ont ensuite été escaladés à tort sur une periode donnée. Par exemple, le mois dernier.

Pour l’exemple, voilà d’autres objectifs avec la data correspondante qui peut contenir la réponse.

Objectif Data
Répondre plus vite. La liste des tickets clos sur une période donnée avec le temps de traitement.
Apporter des réponses plus qualitatives aux clients. Intégrer un Customer Effort Score à chaque ticket (= demander au client d’évaluer en un vote la réponse reçue)
Faire de la Quality Assurance sur les tickets (faire examiner des échantillons pour évaluer manuellement la qualité de la réponse)
Alléger la frustration des équipes Réaliser des enquêtes régulières auprès des équipes pour évaluer leur satisfaction.

Comment obtenir cette data ?

Si ton département utilise un outil dédié pour gérer les demandes de clients (exemples : Freshdesk, Zendesk, Atlassian, etc.), tu dois normalement pouvoir très facilement exporter des lots de tickets, avec leurs informations clés (le message du client, la date, etc.).

Dans notre cas, on a besoin des tickets qui ont été escaladés à tort

Donc, pour cela, il faut aussi que les équipes qui traitent les tickets escaladés puissent flagguer les demandes qu’elles n’auraient pas du recevoir par l’équipe entre elles et le client.

Une fois l’export fait, on colle le résultat dans un Excel ou un Gsheet pour l’analyser.

Oui, mais si le département n’a pas d’outils pour gérer les tickets ?

Alors ça va être beaucoup plus laborieux. Et,à priori, le département a d’autres urgences que de plancher sur du contenu ou de l’analyse des questions les plus fréquentes.

Ceci dit, il y a quand même des solutions.

Si tous les échanges avec les clients fonctionnent par mail, tu peux mettre en place un pocess pour que les équipes qui traitent les tickets escaladés les forwardent à une adresse mail dédiée type escalade@nom-entreprise.com.

Si tous les échanes se font par téléphone, dans ce cas il faudra demander à chaque équipe de completer un log après chaque call (logcommun ou perso) pour garder une trace des principales infos : sujet du call, date et heure, client, etc.

Pour que ça marche, il va falloir faire comprendre aux équipes que c’est dans leur intérêt et que ça va leur faciliter le travail sur le moyen terme.

Comment analyser la data une fois dans l’Excel/Gsheet ?

On a donc notre liste de tickets escaladés à tort. 

Ce qu’on veut maintenant, c’est comprendre quels sont les sujets où les questions qui reviennent le plus souvent.

Dans un monde idéal, les conseillers flagguent chaque ticket une fois terminé en indiquant la thématique ou le sujet de la question. Le tout, avec un minim d’erreurs.

En pratique, tu auras vraisemblablement besoin de mettre les mains dans le cambouis. De noter rapidement chaque ticket pour lui attribuer une catégorie.

Note. La plupart des gens auxquels je pitch ce travail ont tendance à lever les yeux au cliel. 

Ca leur semble trop de travail ou une tache indigne d’eux.

C’est une grosse erreur.

En tant que content manager (travaillant au CS ou au Marketing), tu devrais lire systématiquement une portion des demandes envoyées par les clients chaque mois.

Pour comprendre ce que pensent les clients, ce qui les préoccupe, comment ils s’expriment, ce qui est important pour eux…

Et, honnêtement, ça n’a rien de très compliqué.

Il suffit de coller un Excel ou un Gsheet tous les tickets avec à minima :

  • la date d’envoi du ticket
  • Le message d’origine du client
  • (Bonus : un lien vers l’échange complet entre le client et le conseiller, si besoin de retrouver la conversation plus tard)

Puis il faut simplement lire chaque message, un par un, et noter dans une 4ème colonne le sujet du ticket. 

“Export. Accès. Accès. Facture. Bug. Feature 3. Feature 7. Accès. Accès.”

💡 Un conseil : la première fois que tu fais l’exercice, ne te prends pas trop la tête sur la formulation. Note spontanément ce qui te vient en tête.

Pourquoi ?

Parce que, une fois que tu as terminé, tu vas ajouter un tableau croisé  dynamique. Ca va te donner le nombre de tickets dans chaque “Thématique” que tu as crées”.

C’est à ce moment là que tu vas regrouper ou séparer des thématiques.

“En fait, Mot de passe et Email non reçu, c’est pareil. Je vais les regrouper comme des Accès”.) 

“Hum… Ca fait beaucoup de Exports. Je vais diviser entre Export – Fonctionnement d’un côté et Export – Propriétés disponibles de l’autre, pour séparer les clients qui ne savent pas qu’il y a un module et ceux qui connaissent le module mais ne trouvent pas la data dont ils ont besoin”)

Un petit graphe pour terminer et voilà : tu as une représentation visuelle des sujets les plus fréquents parmis les questions de tes clients.

En bonus, tu as fait un découpage, une architecture de l’information qui va potentiellement t’être utile plus tard (par exemple pour nourrir ta réflexion quand tu vas vouloir ranger ou organiser les contenus sur ton centre d’aide ou les formations).

Si tu refais régulièrement cette analyse (ce que je te conseille fortement tant que tu n’as pas un système automatique fiable en place, où les conseillers eux-mêmes taclent chaque ticlet), triche en utilisant des mots-clés.

A force de lire des tickets, tu vas finir par repérer des mots-clés.

Exemple : Toutes les questions sur la feature Export contiennent généralement l’un des mots suivants.

  • Export
  • Exporter
  • Télécharger
  • Livre d’achat
  • Croiser
  • Axe
  • Propriées

Notes ces mots-clés quelques part. Plutôt que d’analyser les tickets un à un, fais les par lots, en filtrant pour n’afficher que les tickets qui contiennent l’un de ces mots-clés. (Gsheet comme Excel te permettent de faire ça en quelques clics).

Tu iras beaucoup plus vite si tu analyse des lots de tickets similaire (ça demande moins de gymnastique mentale). 

2️⃣ Avec des interviews

La data est la solution idéale. Simple, objective, pratique. 

Mais que faire si elle n’est vraiment pas une option.

Eh bien, première étape, se mettre en ordre de bataille pour qu’elle devienne une option. Lancer un projet. Aller faire du lobbying. Mettre les outils ou les process en place pour y arriver.

Deuxième étape (en attendant que la data arrive) : aller discuter avec les équipes.

(💡 Ce qu’il faudra faire de toutes façons à un moment ou un autre du projet pour comprendre le besoin des équipes, comment ils vont utiliser l’information, dans quelles circonstances, etc.)

Qui interroger ?

Dans notre exemple (“Trop de tickets escladés par erreur”), on a 2 populations à aller interviewer : 

  • les équipes qui escaladent les tickets
  • les équipes qui traitent les tickets escaladés.

Ce qu’on veut savoir

Commençons par l’équipe qui traite les tickets escaladés par erreur (potentiellement la source de donnée la plus intéressante).

Exemples types de questions qu’on pourrait leur poser :

  • Quels sont les tickets escaladés par erreur que tu vois le plus souvent passer ?
  • Quel est le dernier ticket escladé à tort que tu te rappelles avoir traité ?
  • Est-ce que tu reçois souvent des tickets de ce type ?
  • Est-ce que tu en as des similaires, mais sur des sujets différents ?
  • Quels sont les tickets qui te pèsent le plus ? 

Deuxième population : l’équipe qui escalade des tickets.

  • Quelles sont les infos dont tu as souvent besoin mais que tu n’as pas aujourd’hui ?
  • A chaud, quels sont les types de tickets que tu escalades le plus souvent ?
  • Honnêtement, juste entre toi et moi : quels sont les tickets que tu escalades, mais en te demandant si c’est pas un ticket qui va être recadré comme “Escaladé à tort”. Avant que tu répondes : sache que ta réponse est 100% anonyme. Ton nom n’apparait pas sur les notes. J’ai juste besoin de comprendre ce qui ne marche pas dans le système actuel. 
  • Est-ce qu’on peut regarder ensemble vite fait les 5 derniers tickets que tu as  escaladés ?
  • Raconte-moi les étapes par lesquelles tu passes quand tu es face à un ticket et que tu ne sais pas immédiatement ce qu’il faut en faire. Que fais-tu ? Est-ce que tu vas chercher de l’info ? Ou ? Comment ?

Quelques tips pour que l’interview soit productif.

👉 Toujours demander à l’interviewé de se rappeler, pas d’imaginer

Ce qui nous intéresse, c’est des retour sur ce qui se passe. Pas des hypothèses ou des interprétations.

On recherche des informations les moins biisées possibles.

Si tu demandes à ton interviewé “Comment gèrerais-tu…. (situation)”, tu vas avoir une réponse sensiblement différente de celle que tu obtiendrais en posant la question “Raconte-moi comment tu as géré… (situation)”.

👉 Aide au maximum ton interviewé à être objectif

Pose-lui des questions qui vont l’aidder à challenger lui-même sa propre subjectivité.

Dans l’exemple plus haut, on leur demande “Quels sont les tickets les plus fréquents” mais aussi “Quels sont les tickets qui leur pèsent le plus”. 

Pourquoi ? Parce que s’ils en on marre de recevoir certains types de tickets, ils risquent (consciemment ou non) de gonfler l’importance de ces sujets.

“Ha, on reçoit trop de tickets sur XXX.”

Alors que la data te montrerait que c’est l’une des catégories les moins fréquentes, même si elle leur pèse.

👉 Bien expliquer qu’on est en train d’évaluer le système et pas la personne qu’on interview

L’interview peut vite de venir hyper anxiogène pour la personne interviewée, surtout si elle a l’impression d’être du côté de l’équipe “en tort”. 

Elle risque de se braquer ou de déformer (volontairement ou non) les informations qu’elle donne si elle a l’impression qu’on est en train de l’évaluer elle.

Il est super important de lui faire comprendre que le problème vient du système. Et qu’on est là pour le résoudre ensemble, ce qui devrait lui faciliter son quotidien si on obtient des réponses. 

Ca vaut le coup de le dire dès le début de l’entretien.

“Ok. Un élément hyper important avant qu’on commence : on est là pour comprendre ce qui ne va pas avec le système actuel. On est pas là pour t’évaluer toi. L’objectif, c’est de comprendre pourquoi la manière dont on est organisé actuellement ne marche pas. Ce qui manque aux équipes pour qu’elle soit autonome.

On voulait en parler avec toi parce que tu viens d’arriver et tu as un regarde neuf / parce que tu es là depuis un moment et tu as une bonne expérience.”

Et d’ouvrir par des questions qui ne laissent aucun doute sur le fait qu’on est là pour apporter de l’aide

“Quelles sont les infos dont tu as souvent besoin mais que tu n’as pas aujourd’hui ?”