Posts in "Content Management 101"

Pour devenir une machine à contenu, il faut penser “en jauges”

L’idée

Organiser ses tâches “en silos” et penser “en jauges”, pour rendre son content management beaucoup plus efficace (et aussi plus confortable à gérer).

Penser en jauges ?

Pour créer un contenu, il faut passer par plusieurs étapes.

  1. Trouver l’idée
  2. Rechercher l’information
  3. Concevoir l’article (= de quoi on va parler dans quel ordre)
  4. Ecrire l’article
  5. Editer l’article
  6. Le valider
  7. L’intégrer
  8. Le publier
  9. Le promouvoir

“Penser en jauge”, c’est avoir toujours une “réserve” d’articles en cours dans chacune des catégories.

Pourquoi c’est important ?

L’approche “linéaire” (= on prend un sujet, on se donne à fond et on ne lâche rien tant qu’on n’a pas terminé”) marche très bien pour les écrivains. Ou les journalistes.

Eux ont besoin de creuser véritablement leur sujet. De devenir leur papier. Et s’il le faut, ils sont prêts à passer des semaines ou des mois pour sortir ce fichu reportage. Voire des années si on parle d’un bouquin.

Mais cela ne fonctionne pas du tout pour la grande majorité des content managers, qui, eux, sont dans une logique inverse : 

  • on doit sortir beaucoup de contenus en très peu de temps
  • on n’a pas spécialement besoin de creuser chaque contenu aussi profondément.

(💡 Attention, ce n’est pas vrai pour absolument tous les content managers. Certains, notamment en Branded Content, ont une approche quasi journalistique. Et vont passer plusieurs semaines sur un seul contenu.)

Mais, il faut être lucide : dans les faits, il y a peu de marques qui peuvent / osent investir dans ce type de contenu.)

Donc, pour le content manager “classique”, le plus efficace (de loin), c’est l’approche “en jauges”. Avoir à n’importe quel moment une “réserve” de tâches en cours pour chaque grand type de tâches qui existent.

Pour deux raisons.

1️⃣ Ces types de tâches demandent des états d’esprit radicalement différents.

“Rechercher de l’information” ou “Trouver les bonnes tournures pour un passage” vont demander une énergie (un état d’esprit ? une disposition ? un flow… bref : appelle ça comme tu veux) très différent.

C’est la même différence qu’entre “animer une réunion importante” et “bloquer 2 heures pour réfléchir au calme sur un projet”.

Ces tâches ne demandent pas le même type d’énergie. Et tu as probablement des moments de la journée où tu es plus efficace dans l’un ou l’autre type.

Traiter un groupe de tâches similaires en une fois (plutôt que de passer de l’une à l’autre) te rend plus efficace parce que tu vas :

  • pouvoir utiliser les moments de la journée les plus efficaces en fonction du type de tâche ;
  • éviter de passer d’un type de tâche à l’autre et donc perdre du temps à réajuster ton état d’esprit.

2️⃣ Cette méthode élimine la latence entre les tâches : le temps perdu à se demander “et maintenant, je fais quoi ?”

Avec l’approche linéaire, il est facile de perdre du temps parce que l’on réfléchit à ce que l’on doit faire ensuite à chaque arrêt. Ou parce qu’il faut “se motiver” pour passer à la suite”.

Alors qu’avec une réserve de tâches, on réduit énormément la charge mentale. Il n’y a pas besoin de réfléchir à ce que l’on fait : on peut se concentrer sur les tâches en elle-même.

Étape par étape

1️⃣ Monte le Kanban

Définis les types de tâches par lesquelles tu dois passer pour “sortir” un contenu.

Utilise Trello ou Notion pour monter la structure de ton Kanban.

2️⃣ Assure-toi que chaque colonne est toujours suffisamment remplie

Teste pendant quelques semaines pour trouver le bon équilibre. À savoir “De combien de tâches minimum as-tu besoin dans chaque colonne pour être toujours à l’équilibre ?”.

3️⃣ Fonctionne en “sprints”

En gros : travaille et raisonne en cycles.

Choisis une période de temps (1 semaine par exemple) et travaille en cycles de 1 semaine.

  • Au début du cycle, assure-toi que tu as suffisamment de tâches dans chaque jauge et organise-les par ordre de priorité
  • Pendant la semaine, déroule les tâches en les traitant par groupe de tâches
  • À la fin du cycle, marque un temps de rétrospective : fais l’inventaire de ce que tu as sorti, réfléchis à comment tu aurait pu être plus efficace, etc.

Une fois que tu as ce système en place, tu vas pouvoir te concentrer à 100% sur le flux. Faire tourner ta machine.

D’expérience, c’est la méthode la plus productive mais aussi la plus confortable à utiliser.

Demander une relecture / une validation

L’idée

“Briefer” la personne en charge de la relecture ou de la validation pour s’assurer que…

  • les retours seront utiles et pertinents (exemple type : éviter de recevoir des retours sur la forme quand on a besoin d’une validation du fond)
  • la relecture / validation soit simple pour la personne à laquelle on la demande (et donc maximiser les chances que cette relecture soit faite)

Étape par étape

1️⃣ Explique à tes relecteurs ce que tu attends concrètement de cette relecture

Évite les tournures comme : 

  • “Peux-tu relire…”
  • “Peux-tu me donner ton avis sur…”
  • “Que penses-tu de cet article…”

Elles sont trop vagues. Ton relecteur ne saura pas comment prendre la tâche + tu vas te retrouver avec une masse de retours qui ne sont probablement pas ceux que tu attendais.

Exemple type : ton relecteur va réécrire ton texte (pour coller à la manière dont “lui l’aurait écrit”)… Alors qu’en fait, tu avais seulement besoin d’une relecture sur le fond.

Ou tu vas te retrouver avec des retours de type “j’aime” / “j’aime pas” (qui n’ont absolument aucun intérêt à moins que ton relecteur soit un membre de ton audience).

Donc.

Si tu as besoin d’une relecture sur le fond, demande une relecture sur le fond.

“Peux-tu relire ce texte et me dire si les informations sont bien exactes ? (S’il n’y a pas de contresens par exemple, de passages qui risquent d’entraîner des quiproquos, etc.)”

Si tu as besoin d’un check orthographe, demande-le clairement

“Si tu as le temps, peux-tu jeter un œil à l’article pour être certain que l’on n’a pas laissé passer de coquilles ou de fautes de frappe ?”

Si tu as besoin d’une validation, demande-la explicitement.

“Voici la version finale du texte XXX. Pouvez-vous la relire et la valider avant le XXX afin que nous la mettions en ligne.”

💡 Alternative, si tu n’a pas vraiment besoin d’une validation, mais que tu es tenu de laisser la porte ouverte à un dernier retour.

“Voici la version finale du texte XXX, validée par l’équipe. Si toutefois vous avez un véto (objection, problème de fond avec un passage, etc.), merci de nous le communiquer avant le XX.”

💡 Pour maximiser les chances que la validation se fasse à temps et dans des conditions sereines, préviens à l’avance les personnes concernées que tu auras besoin d’une validation la semaine du XX.

Quand on reçoit une demande de validation qui sort de nulle part, ça rajoute une couche 

  • de stress (“Rhaa, encore une urgence”)
  • de doute (“Minute, est-ce que cette personne cherche à me forcer la main ? A faire passer des trucs dans l’urgence ?”)
  • de frustration (“Mais tu le sais depuis des semaines que tu vas avoir besoin d’une validation. Tu pouvais pas me le dire avant ? Je suis en réunion toute la journée !”)

Si tu as besoin d’un retour pour t’assurer que le texte sera clair pour le client (ou aura un impact sur lui), explique le contexte

“On a besoin de ton avis sur cet article pour le centre d’aide.

Le sujet : les nouvelles règles d’utilisation des titres restaurant

L’objectif de l’article : qu’on réduise au maximum les questions les plus fréquentes

Peux-tu relire l’article et nous dire si :

  • Les nouveaux montants et conditions pour utiliser les titres restaurant te paraissent clairs ?
  • Tu vois des questions que les clients risquent encore d’avoir après avoir lu l’article ?”

2️⃣ Explique à tes relecteurs où et comment ils vont pouvoir faire leurs retours 

C’est tentant de ne pas en parler et de botter en touche avec un “Fais comme ça t’arrange”. 

Mais c’est une mauvaise idée : tu as peut-être l’impression que laisser le choix à ton relecteur est une bonne chose, mais en réalité, c’est une contrainte. 

Une décision de plus qu’il va devoir prendre (alors que tu connais bien mieux que lui les différents moyens de te faire des retours, ainsi que leurs avantages et leurs inconvénients par rapport au texte en question).

Donc…

À la place, propose une solution dès le début…

“Tu vas recevoir un accès à une version sur Google Document du texte. Je t’invite à poser directement tes retours sous forme de commentaires (idéalement 1 commentaire par retour).”

… et laisse la porte ouverte à d’autres au cas où.

“Voici également une version .pdf si jamais tu préfères m’envoyer directement tes retours par mail ou par Slack.”

3️⃣ Assure-toi que ton relecteur comprenne bien la règle du “On remonte les problèmes, pas les solutions”

Lorsque l’on fait des retours sur un texte, un design (ou n’importe quelle création vraiment), on est souvent tenté de faire des retours sous forme de solution

(C’est-à-dire, en expliquant ce qu’on voudrait changer dans la version qu’on a sous les yeux.

  • “Il faut plutôt mettre cette phrase-là à la place.”
  • “Ça, à remplacer par…”
  • “Là, j’écrirais plutôt…”)

… au lieu d’expliquer le problème.

(C’est-à-dire, d’expliquer ce qui nous a fait réagir : ce qui nous fait dire qu’il faudrait modifier ce passage.

  • “Ce passage est très long. Je ne sais pas si les clients vont le lire jusqu’au bout.”
  • “Je n’ai pas compris du tout cette partie.”
  • “Là, le client risque de comprendre Y, alors qu’en fait X.”)

Remonter les solutions au lieu des problèmes est dangereux.

👉 On bascule très vite et sans s’en rendre compte dans le subjectif. Dans le “J’aime / J’aime pas” et dans le “Moi, je n’aurais pas écrit ça comme ça”.

Les retours subjectifs ne sont pas utilisables. Le but, c’est que le texte parle à l’audience, pas au relecteur. 

👉 Le relecteur est souvent la personne la moins bien placée pour proposer des solutions : 

  • il n’a pas l’expertise en rédaction
  • il n’a pas forcément tout le contexte

Il risque fort de proposer une piste (“Il faut trouver quelque chose comme XX, mais mieux écrit”) inutilisable.

👉 Il vaut mieux que le relecteur identifie le problème, puis que toi (ayant l’expertise) chercher des solutions à ce problème. 

Le relecteur n’a pas l’expertise : il va pousser une solution (un autre mot, une autre tournure) alors qu’il y en a probablement une plus efficace.

👉 “Faire rentrer” la suggestion du relecteur dans ton texte n’est pas toujours facile.

Sauf exception, intégrer le style de quelqu’un d’autre dans un texte déjà existant est souvent coton.

💡 Rien n’empêche ton relecteur de proposer des solutions.

Mais à condition qu’il définisse le problème avant.

4️⃣ Demande à tes relecteurs qu’ils te confirment une fois qu’ils ont terminé

Cela paraît évident, mais le préciser va t’éviter des frustrations. Des deux côtés.

C’est assez courant que ton relecteur fasse plusieurs passes.

Tu vas recevoir un lot de commentaires, hésiter, te demander s’il a terminé et si tu peux prendre le relais.

Finalement, tu vas commencer à traiter ses commentaires. Y répondre ou y poser des questions. Lui va s’agacer parce qu’il n’avait pas terminé.

Le process sera beaucoup plus efficace si tu le laisses terminer avant de traiter ses retours.

5️⃣ Si besoin, prévois un temps de visu pour expliquer à l’oral et “désacraliser” la relecture

Cela permet d’éviter que ta relecture reste coincée dans la to-do list de ton relecteur pendant X temps.

Un rapide coup de fil ou une visio de 5 minutes pour expliquer ce que tu attends va réduire la charge perçue et augmenter les chances que ton relecteur s’en charge.

6️⃣ Donne une deadline

Sois clair sur le timing : pour quand as-tu besoin de cette relecture ?

Quand tu demandes un service à quelqu’un, c’est irrespectueux d’être flou sur les paramètres de ce service.

  • “Quand tu peux..”
  • “Quand tu as le temps…”
  • “Dis, tu as pu avancer sur la relecture que je t’avais demandé ?”

Tu lui demandes un service et tu lui demandes aussi de deviner ce que tu attends. L’importance du projet. La priorité.

“Ne pas vouloir lui imposer une deadline”, c’est une excuse (et une mauvaise).

Donne une date claire à ton relecteur puis demande-lui poliment si c’est jouable de son côté. Tu exprimes ton besoin, sans rien lui imposer, et tu lui demandes ce qu’il peut faire.

7️⃣  Ne sous-estime pas le temps qu’il va falloir pour traiter ces retours

Les relectures prennent du temps à faire (côté relecteur) et du temps à traiter (de ton côté).

Les fautes sont vite expédiées, mais le reste peut vite devenir chronophage : les tournures à problèmes et les informations à vérifier.

Quand l’article est “low profile”, c’est rarement le cas, mais dès qu’on touche à un sujet touchy, attends-toi à ce que la relecture et les allers-retours derrière prennent un moment.

8️⃣ Souviens-toi que recevoir des corrections est rarement agréable

Je fais ce métier depuis 2008, et je ressens encore parfois de l’agacement en lisant des retours sur mes textes.

Ma personnalité joue probablement un rôle là-dedans, mais au-delà de ça, je pense que personne n’aime spontanément qu’on vienne pointer “ce qui ne va pas avec ce que tu viens de faire”.

Tu vas peut-être t’agacer parce que tu as laissé passer une faute. Ou parce qu’un retour te paraît incongru. Ou parce que ton relecteur a été très brut de décoffrage dans la manière dont il a écrit son commentaire (“Mal dit”). Ou n’a parce qu’il n’a pas suivi tes consignes pour la relecture.

Ou par le très classique “Oui, mais tu n’expliques pas…” alors que la réponse est 2 lignes plus bas.

Il faut en être conscient. Il faut se préparer avant de lire des retours. Il faut prendre du recul. Il faut les considérer au calme. Et éviter d’y répondre à chaud.

Garde en tête que le relecteur te fait un service : il essaye de t’aider dans ton travail. Il prend du temps sur le sien. Réceptionne avec bienveillance les commentaires.

Si tu es vache avec un relecteur, pourquoi ferait-il l’effort de t’aider la prochaine fois ?

💡 Ceci dit, il y a aussi (rarement, mais ça arrive) des relecteurs toxiques. Grisés par la posture (= je juge le travail d’un autre) et l’autorité qu’elle sous-entend. Qui vont te faire des retours inacceptables dans la forme. 

Quand ça t’arrive, autant éliminer le relecteur pour les prochains contenus. Ou, quand ce n’est pas possible (exemple : quand il s’agit d’une personne qui doit valider), remettre les points sur les i avec cette personne.

9️⃣ Prends le temps de répondre aux retours

Pour remercier le relecteur déjà.

Ensuite, tout dépend du contexte.

À mon avis, il est rarement nécessaire de répondre individuellement à chaque commentaire. Un message global une fois tous les commentaires traités est largement suffisant.

En revanche, s’il s’agit :

  • d’un retour que tu as choisi de ne pas prendre
  • envoyé par un décideur (avec droit de véto)

Il vaut mieux expliquer exactement pourquoi tu prends une autre direction.

Explique, rationnellement et objectivement, en un minimum de caractères, mais avec tous les arguments nécessaires “pourquoi on va plutôt partir dans telle direction”.

Et prends le temps de réfléchir un minimum à la forme de ton message : de la même manière que personne n’aime recevoir des retours sur son texte, personne n’aime entendre que son retour est stupide ou inutile.

Ranger & réorganiser des contenus

Définir la nouvelle arborescence au moment de créer (ou de refondre) un centre d’aide, une base de connaissance, un intranet, etc.

En bref : comment décider du “quoi doit être rangé où et pourquoi”.

Avertissements

1️⃣ L’architecture de l’information (IA) est un vrai métier. Dès qu’on dépasse une certaine taille de projet, il vaut mieux faire appel à quelqu’un de rôdé, qui exerce ce métier à plein temps.

2️⃣ Si la plateforme a des ambitions de référencement, il y a tout une autre série de paramètres et de contraintes qui entrent en jeu. Et, dans ce cas, il vaut mieux être accompagné aussi par un expert SEO.

Ce que tu vas trouver ici, c’est la version hyper courte. Elle est parfaite pour des projets “simples” (moins de 500 contenus), sans enjeux SEO.

Au-delà de ça, je te recommande plutôt la version longue, ou mieux, les deux bouquins cultes (concrets et pratiques) qui l’ont inspirée :

Étape par étape

👉 Pré-requis indispensable : prépare le terrain avec les décideurs (et démine un quiproquo fréquente)

Tous les décideurs avec lesquels tu vas échanger (= toute personne qui peut te faire un retour “obligatoire,” un véto ou autre sur ce que tu vas proposer) doivent comprendre quelque chose d’important.

👉 Il n’y a pas de “bonne architecture de l’information”.

Si tu y réfléchis un instant, tu te rends compte qu’il y a une infinité de combinaisons possibles de rubriques, de sous-rubriques et de manières de ranger l’information.

Quand tu vas présenter une suggestion d’architecture, il y a de fortes chances que quelqu’un te fasse remarquer…

🤔 “Ha, bah oui, mais tel contenu, il peut aller aussi bien dans cette sous-rubrique que dans cette autre”.

C’est normal. On trouvera souvent 1 ou 2 contenus qui vont être compliqués à ranger. Il faut en être conscient. 

On n’arrive pas toujours à créer des architectures parfaites où chaque contenu ne peut être que dans une seule catégorie et où les catégories couvrent tous les contenus possibles (on parle de “MECE”).

🤔 L’autre retour que tu vas souvent entrendre va être :

  • “On pourrait aussi…”
  • “Je n’aurais pas fait comme ça”

C’est un retour dangereux. Il existe une infinité de combinaisons : on trouvera toujours “quelque chose qu’on aurait pu faire différemment”.

Et parfois, on s’entête : on a une arborescence qui marche plutôt pas mal, mais on a repéré UN truc qui ne marche pas parfaitement. Et en essayant de le corriger (= on ajoute des rubtiques, on supprime, on fusionne, etc.)… eh bien, on se retrouve au final avec une architecture qui marche beaucoup moins bien que l’originale.

👉 Donc, quand quelqu’un te fait une remarque sur une architecture que tu viens de proposer, il est vraiment important de garder tout ça en tête.

Il ne faut pas avoir peur d’expérimenter : si ça se trouve, la remarque est pertinente et peut aider à améliorer l’architecture.

Mais il faut aussi savoir laisser passer certains retours.

On se contrefiche que l’arborescence trouvée soit…

  • parfaite
  • élégante
  • symétrique
  • visuellement plaisante
  • parlante pour les décideurs

La seule chose qui nous intéresse, c’est de trouver une arborescence qui réponde : 

  1. à l’objectif (= à quoi sert ce site)
  2. aux besoins des users (= que veulent-ils, comment ils fonctionnent) et 
  3. aux contenus que l’on prévoit d’y mettre

👉 Le chemin le plus court pour y arriver, c’est…

1️⃣ Se mettre d’accord entre décideurs sur nos besoins (l’objectif, les contraintes, etc.). Les formaliser pour s’assurer qu’on ne diverge pas en cours de route.

2️⃣ Comprendre comment les utilisateurs vont vouloir se servir de la plateforme.

3️⃣ Identifier tous les contenus qu’on a l’intention d’y mettre.

Une fois seulement que ces 3 étapes sont terminées, on pourra passer à la suite.

4️⃣ Choisir un type d’arborescence parmi les 6 principaux qui existent.

5️⃣ Concevoir l’architecture de l’information.

6️⃣ La tester.

7️⃣ La déployer.

💡 Je te recommande la version longue de l’article pour en savoir plus sur chaque étape, mais voici déjà les principales questions à te poser sur chaque.

1️⃣ Nos besoins

👉 Ce qui suit va peut-être te paraître bêtement évident, mais je t’assure que c’est vital. Près de 90% des problèmes que tu auras pendant le projet viendront de là : de décideurs qui pensent être d’accord sur leurs besoins, mais qui, en fait, ne le sont pas.

1/ L’objectif

Qu’est-ce que l’on attend de cette plateforme ? Quel est l’objectif business qui nous a poussés à investir pour la créer ?

On en attend quoi concrètement comme résultats sur notre bottom line ?

Exemples :

  • Moins de questions de nos clients (= le centre d’aide va permettre à plus de nos clients de trouver des réponses à leurs questions basiques)
  • Plus d’efficacité des équipes SAV (= la base de connaissance interne va leur permettre de trouver les réponses à plus de 50% des questions que posent les clients)
  • Plus de satisfaction de nos clients (= notre académie en ligne va aider nos clients à monter en puissance dans leur vie professionnelle, et ils en seront reconnaissants)

2/ Les parties prenantes

Qui soit être consulté ? Sondé ? Informé ? Intégré dans les décisions ?

3/ Timing

Quels sont les deadlines à prendre en compte ?

(En séparant bien “Les éléments non négotiables” vs “Les timings qu’on espère tenir”.)

4/ Contraintes techniques

Est-ce que l’outil qui va héberger le contenu est déjà décidé ? Est-ce qu’on veut le revoir ? Est-ce qu’on attend de définir l’IA idéal avant de choisir l’outil ou est-ce que l’IA doit être décidée en fonction de l’outil ? Est-ce qu’on ne sait pas ? Comment on va décider ?

Une fois l’outil validé, quelles sont les contraintes techniques qu’il faudra prendre en compte ?

5/ Contraintes graphiques

Est-ce qu’on doit suivre des guidelines graphiques ? Intégrer un validateur sur ce point ?

2️⃣ Les users

👉 Cette partie-là est vraiment tricky. Tu vas probablement être tenté de la sauter (ou de la survoler), mais il faut que tu résistes à la tentation.

C’est cette étape qui va te donner les éléments et les idées dont tu vas avoir besoin pour “trouver” l’IA. Si tu te retrouves coincé plus loin (étapes 4️⃣ à 6️⃣), reviens ici : tu as peut-être manqué quelque chose.

Prends une feuille de papier, ou ouvre un document sur ton ordi, et raconte qui va se servir de cette architecture.

Fred est Customer Manager.

Son job est de répondre aux questions des clients :

  • le plus vite possible
  • avec la réponse la plus exacte possible.

Fred reçoit régulièrement (environ 6x / jour) des questions auxquelles il n’a pas la réponse.

  • Parce que c’est un cas particulier que Fred n’a jamais rencontré.
  • Parce que le client est bloqué sur une partie de notre SaaS que Fred connaît mal.
  • Parce que Fred n’est pas sûr de comprendre pourquoi l’app se comporte de cette façon.

Quand ça arrive, Fred se rend sur la page d’accueil du Wiki interne.

Il veut comprendre comment l’app est censée fonctionner dans ce type de situation.

Afin de pouvoir soit répondre directement au client, soit reporter un bug à l’équipe technique pour qu’elle prenne le relais.

Quand tout se passe bien, Fred trouve très vite…

  • soit un article dédié à la feature ou à la situation (qui explique ce qui doit se passer vs ce qui ne doit pas arriver) ;
  • soit un article “d’auto-diagnostic” (qui explique “quelles vérifications faire dans quel ordre quand un client a tel problème”).

Quand ça se passe mal, Fred…

  • trouve trop d’articles qui peuvent potentiellement répondre à sa question, et ne sait pas lesquels lire (et il n’a pas le temps de tout lire) ;
  • ne trouve aucun article qui pourrait l’aider ;
  • trouve des informations contradictoires.

👉 Encore une fois, ça va peut-être te paraître bête d’écrire quelque chose qui a l’air aussi évident quand on le relit.

“Bah oui, c’est un intranet quoi.”

Mais je te garantis que, si tu ne fais pas l’exercice, ça va être un cauchemar de trouver la bonne arborescence.

Trouver la bonne arborescence est bête comme chou… tant que tu as pris le temps en amont de noter les autres infos bêtes comme chou : l’objectif, ce qu’attendent tes users, etc.

Quand tu fais ça, l’IA te saute presque aux yeux. Mais si tu zappes ces étapes “évidentes”, tu n’y arriveras jamais.

Essaye a minima de compléter la trame suivante.

Quand il se passe [DECLENCHEUR],

[USER] se rend sur la plateforme.

[USER] veut [MOTIF DE LA VISITE]

afin de [MOTIVATION]

Quand tout se passe bien, [ADJUVANT]

Mais ça coince quand [OBSTACLE]

Pour trouver la bonne histoire, il est vital que tu passes du temps avec au moins 5 users. Prends au moins 20 à 30 minute avec chacun d’eux pour comprendre qui ils sont, de quoi ils ont besoin, comment ils fonctionnent, ce qui marche pour eux aujourd’hui, ce qui ne marche pas, etc.

3️⃣ Les contenus

Quels sont les contenus qu’on a l’intention de mettre sur la plateforme ? 

C’est-à-dire, ceux que l’on a déjà (et que l’on veut conserver) plus ceux qu’on a l’intention de produire.

Tu vas avoir besoin de faire un inventaire des contenus. Et un plan des contenus à produire.

Plus, idéalement, un audit des contenus existants.

👉 Un point très important : réfléchis soigneusement avant de décider de reprendre tels quels tous les contenus que tu as déjà.

Dans certaines situations, ça fait sens. Tu as un blog, avec des articles clairement définis, chacun bien référencés dans Google.

Et tu veux simplement les organiser différemment.

Dans ce cas, pas de soucis, tu peux probablement reprendre les contenus tels quels.

Mais dans toutes les autres situations, c’est une très mauvaise idée.

Exemple type : 

“On a un intranet, mais personne ne l’a jamais vraiment géré. On a créé du contenu au fur et à mesure. Aujourd’hui, on ne sait même pas trop ce qu’on a dessus. 

Dans ce cas, il y a de fortes chances que tes contenus soient mal définis : 

  • tu as la même information dans plusieurs contenus ;
  • tu as des contenus en double ;
  • tu as des contenus qui manquent.

Donc… Si tu décides de reprendre tels quels les contenus que tu as déjà (= si tu te dis “Ok, la nouvelle architecture doit accueillir ces contenus exactement tels qu’ils sont maintenant, découpés de cette manière là”)… tu vas avoir un mal fou à trouver une arborescence qui marche.

Et avec le temps, tu vas te retrouver de plus en plus souvent face à de nouveaux contenus qui vont arriver et que tu ne sauras pas ranger dans ton architecture neuve.

👉 Si tu penses que tes contenus actuels sont mal découpés, prévois une étape supplémentaire

Commence par lister “Les contenus que nous devrions avoir sur cette plateforme” (= sans regarder ce que tu as déjà).

Puis fais un inventaire de tous les contenus dont tu disposes déjà.

Et enfin, fais un tri impitoyable parmi les contenus que tu as déjà pour voir s’ils correspondent vraiment à ce dont tu as besoin.

L’erreur classique, c’est de faire un inventaire et de te dire naïvement : 

“Ah, mais en fait, on a déjà un contenu sur X, Y et Z”

Sans te rendre compte que ces contenus, même s’ils parlent des sujets qui t’intéressent, ne répondent pas vraiment aux questions des utilisateurs.

Tu risques de dérouler ton projet sans t’en rendre compte, d’annoncer fièrement à tes utilisateurs que la nouvelle version règle tous les problèmes… puis de faire un flop.

4️⃣ Choisis le type d’arborescence

Au fur et à mesure que tu as formalisé les besoins du projet, les besoins des users et les besoins en contenu, il y a probablement un début d’idée qui a commencé à germer sur la meilleure manière d’organiser le tout.

Commence simple : choisis d’abord le type d’architecture.

A/ Une hierarchie ? (Des catégories imbriquées les unes dans les autres)

B/ Une table de donnée ? (Chaque contenu a les mêms types de propriétés. L’user peut filtrer les contenus en filtrant les propriétés.)

C/ Un catalogue ? (Un mélange de A et de B : l’user peut se rendre dans une catégorie, puis à l’intérieur de la catégorie, filtrer les contenus selon certaines propriétés.)

D/ Un parcours linéaire (D’abord le contenu 1, puis le contenu 2, puis le contenu 3, puis…)

E/ Un portail (pense “Wikipedia”)

F/ Un hybride de plusieurs types.

5️⃣ Enfin, construis l’architecture

Garde en tête tous les choix faits jusqu’ici et… tente des combinaisons. Expérimente.

Note ce qui marche et ce qui ne marche pas.

💡 L’exercice est beaucoup plus facile sur papier que sur ordinateur.

Sur écran, je trouve ça très difficile de déterminer la bonne combinaison.

En revanche, avec des post-it, ça devient immédiatement beaucoup plus facile. Il y a quelque chose dans le fait de pouvoir manipuler les post it (les déplacer, les rapprocher ou les éloigner les uns des autres) qui aide vraiment la réflexion.

6️⃣ La tester

Idéalement, avec des vrais utilisateurs.

Donne-leur des exercices et des cas concrets pour voir si l’architecture leur permet de trouver facilement ou non l’information qu’ils cherchent.

“Imagine que tu es… Il se passe… Tu veux savoir… Que fais-tu ?”

💡 Préciise-leur bien..

  • que c’est l’architecture qui est testée (pas eux)
  • qu’ils doivent faire comme si tu n’étais pas là (= il faut juste qu’ils utilisent l’architecture pour trouver le contenu et qu’ils racontent à haute voix ce qu’ils font ; pas qu’ils évaluent l’arborescence ou t’expliquent comment eux l’aurait fait)

7️⃣ La déployer

Mettre en place l’architecture (migrer les contenus, gérer la conduite du changement, etc.) est un gros morceau. Ne sous-estime pas le temps et l’énergie que cela va prendre.

Customer nurturing : par quoi commencer ?

L’idée

On sent qu’on est prêt à faire du customer nurturing sérieux.

On est prêt à envoyer au compte-goutte du contenu à nos clients, de manière proactive.

On se dit que ça va aider à réduire le churn, améliorer la satisfaction des clients, déclencher des opportunités d’upsell…

Mais… Par quoi on commence ?

  • Quel contenus on envoie ?
  • A qui ?
  • Quand ?
  • A quel rythme ?
  • Pourquoi ?
  • Comment on mesure que ça marche ?

Alors, dans l’ordre.

0️⃣ Commence par la stratégie, surtout pas par l’opérationnel

Toutes ces questions juste au-dessus sont importantes, mais ce sont les dernières que tu dois te poser.

Il faut aborder le problème de manière logique et pragmatique. Et surtout ne pas essayer de deviner les bonnes réponses à ces questions.

1️⃣ L’objectif

Donc, première étape, formaliser ce qu’on attend exactement du Customer Nurturing.

C’est toujours le même problème : ce genre de tâche est très simple si tu as un (ou deux) objectifs clairs.

Et presque impossible si tu pars “un peu tous les objectifs”.

Exemple.

On travaille pour une SaaS qui permet aux entreprises de gérer plus facilement leur comptabilité.

La SaaS propose une offre standard (avec les options fondamentales), une offre avancée et une offre premium.

Plus un catalogue de modules et de services complémentaires auxquels peuvent souscrire nos clients.

En en discutant avec les décideurs et quelques interlocuteurs clés, on se met d’accord : les trois grosses priorités de ce programme de customer nurturing, ce seront…

  • Améliorer la rétention et réduire le churn (plus on arrive à conserver de clients, plus on est heureux)
  • Multiplier les upsell et les cross sell (plus on arrive à vendre de modules ou à upgrader des users, plus on est heureux)
  • Développer l’advocacy (plus on arrive à convaincre des clients de nous recommander autour d’eux, plus on est heureux)

2️⃣ Les résultats qu’on veut atteindre

Pour chacune de ces priorités, on va commencer par mesurer où on en est.

Quel est le churn actuel ? Quelle est la Customer LifeTime Value moyenne de nos clients ? Quel est l’advocacy rate parmis nos clients ?

Et, surtout, où veut-on aller ? Quels chiffres on aimerait voir ? Et d’ici quelles échéances ?

Une fois qu’on a réussi à décider ça, le reste va couler de source.

💡 Bien sûr, on ne se fait pas d’illusions. On sait très bien que les résultats qu’on est en train de décider là sont des placeholders. Temporaire.

En fonction de ce qu’on va découvrir par la suite, on reviendra sur ces résultats si on se rend compte qu’ils sont bien trop ambitieux (ou trop timides).

3️⃣ Les leviers pour y arriver

Quels sont les leviers qu’on peut actionner pour faire bouger les résultats dans le bon sens ?

Prends ton temps sur cette étape là. Il faut vraiment poser les choses. Ca va demander des audit, du benchmark, des interview, dujus de cerveau…

Il faut enchainer les “pourquoi”.

Pourquoi est-ce qu’on est pas à l’objectif ? Pourquoi ? Pourquoi ? Pourquoi ?

Qu’est-ce qui se passe ? Ou l’inverse : qu’est-ce qui ne se passe pas ?

4️⃣ Les projets pour actionner ces leviers

Une fois qu’on a fait tout ça, on rentre en mode projet.

On va sélectionner les projets qui 

  • ont le plus de chance de nous amener à l’objectif,
  • sont compatibles avec les ressources que l’on a.

Bien entendu, il va falloir planifier soigeusement chaque projet.

  • Quel va être le livrable
  • A quelle date
  • On part d’ou
  • Pourquoi c’est important
  • Quelles vont être les étapes pour arriver au livrable
  • Pour chaque étape, quelles sont les dépendances (ressoures, buyin, équipes à mettre dans la boucle, etc.)

Tout le reste après est une question de suivi… et d’exécution.

Manager les contenus d’un rules-based chatbot

Comment manager efficacement les contenus d’un rules-based chatbot quand ils commencent à s’accumuler.

Plus on prépare de réponses et de séquences pour un chatbot, plus il est facile de s’y perdre dans le contenu qu’on a déjà créé.

Et mettre à jour ce contenu (ou le développer pour obtenir de meilleurs résultats) devient alors un cauchemar.

Lire la suite

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.

Lire la suite