Imaginez la situation suivante : vous travaillez dans une grande entreprise dans le secteur de l’immobilier. Votre entreprise a grandi rapidement les 5 dernières années, elle possède maintenant 50.000 résidences sur tout le territoire américain. Les perspectives business sont très positives, mais ce qui fonctionnait quand l’entreprise avait 100 résidences ne fonctionne plus maintenant qu’elle en a 50.000, notamment le customer service.

Situation initiale

Aujourd’hui, les opérations et équipes de service clientèle passent leurs journées à « éteindre des feux ». Le NPS score des résidents est très positif lorsqu’ils viennent d’emménager dans leur maison, mais quelques semaines plus tard, le taux de satisfaction s’effondre. Pourquoi ? Il y a énormément de problèmes de maintenance des résidences, les équipes de service clientèle ne peut pas prioriser correctement les tickets zendesk qui s’accumulent.

Chaque email ou appel que nous recevons devient un ticket dans Zendesk. Chaque ticket prend du temps à lire et à traiter, il y en a 10.000 à 15.000 nouveaux par mois, et il est impossible pour les agents de différencier un ticket bénin (« quand dois-je payer mon loyer ») d’un ticket extrèmement urgent (« une canalisation d’égout vient d’exploser en dessous de ma maison »). Zendesk dispose bien d’un système de classification des tickets, mais il n’est pas utilisé de façon utile (quand tout est important, rien n’est important).

La répartition des tickets est la suivante:

  • 30% de demandes dont un âne pourrait s’occuper (« à quelle date dois-je payer mon loyer? »)
  • 30% – 40% de demandes qui peuvent être traitées automatiquement, en allant chercher des informations via API dans nos systèmes (« Quel est le montant de mon loyer ? »), des informations uniques, mais standardisées.
  • 30% de questions très spécifiques, uniques, dont la complexité demande l’intervention d’un humain, capable de comprendre une situation et offrir des solutions raisonnables (« Une canalisation d’égoûts a explosé dans mon salon, que faire ? »)

Aujourd’hui, personne ne recoit de service correct : les résidents qui posent des questions simples se demandent pourquoi il faut tellement de temps pour répondre à leur question, et les résidents qui ont une urgence se demandent pourquoi leur demande n’est pas priorisée à la hauteur de l’urgence qu’ils subissent.

La solution proposée

Votre mission est d’améliorer le service et la satisfaction client. Heureusement, vous n’êtes pas seul : vous collaborez avec la personne responsable de l’App, celle responsable du portail en ligne, et celle responsable du système de comptabilité… Chacun a une équipe de développeurs dédiée. Détail important: tous travaillent évidemment sous l’autorité du CTO.

Un premier projet est donc lancé : les tendances dans l’industrie montrent que le service client passe de plus en plus par un AI enabled chatbot, qui permet de résoudre une portion importantes des demandes de façon automatisée. Le but n’est pas de pouvoir répondre à 100% des demandes, la granularité et spécificité de chaque situation rend la tâche impossible, mais si nous pouvions répondre automatiquement à 30%-50% des demandes, les agents pourraient mieux se focaliser sur les problèmes urgents.

A 15.000 tickets par mois, une différence de même 10-20% aurait un impact énorme. Le project est présentée au senior leadership, qui valide l’approche, les équipes d’opérations sont également également très emballées.

La nécessité d’un processus d’alignement interne

Je pose donc les requirements et user stories, c’est à dire la liste des choses dont nous avons besoin pour pouvoir automatiser une partie du service clients :

  • avoir un NLP engine (comprendre le langage humain): cela permet d’éviter que les clients doivent s’exprimer de façon très rigide, en utilisant des phrases précises, pour obtenir la réponse qu’ils attendent. Un NLP comprend que « Quand dois-je payer mon loyer », « quelle est la date de paiement du loyer » et « Quel est le dernier jour pour éviter de payer mon loyer en retard? » est la même question.
  • pouvoir se connecter à nos systèmes par API pour aller chercher des informations sur nos clients. On veut pouvoir récupérer des informations sur le client, son adresse, son loyer, ses derniers paiements etc.
  • la possibilité pour un humain de prendre le controle et chatter directement avec le résident (live chat): le chatbot n’aura pas réponse à tout. Une transmission fluide de la conversation à un humain dans les cas urgent aura une forte valeur ajoutée.
  • pouvoir « guider » facilement le bot dans les réponses qu’il offre aux clients: un chatbot est un outil: il ne sait rien. La connaissance qu’on lui donne et la façon dont il la servira au client sera déterminant pour son efficacité.
  • une UI simple, compréhensible par tous (dans les détails, c’est une UI de chat classique, indiquant le nom du bot, le nom de l’utilisateur, et le nom de l’agent si le bot passe la main à un agent, bouton envoyer, etc.).

Le lead dev avec qui je travaille, appuyé par le CTO (notre chef à tous les deux), a exprimé sa confiance en Amazon Lexbot comme étant une solution solide. J’ai suggéré d’examiner également d’autres technologies disponibles pour avoir une perspective complète, mais l’équipe technique était convaincue que Lexbot était la solution, et souhaitait commencer le développement immédiatement.

L’analyse « build » vs « buy » avait pourtant du sens dans ce cas-ci, mais ca sera pour une prochaine fois.

Durant les mois qui ont suivi, nous avons tenu plusieurs réunions avec l’équipe technique. Le lead dev a continué à assurer que tout avançait bien, le manque manifeste de partage d’information indiquant du progrès. Avec le temps, nous avons réalisé que, bien que Lexbot ait un potentiel énorme, il nécessite une expertise approfondie pour être développé, et nos équipes n’étaient pas équipées pour relevé le défi.

Au final, l’équipe technique a consacré trois mois à explorer une solution, mais a rencontré des obstacles insurmontables en cours de route. Face à ces défis, l’équipe Produit a décidé de jouer un rôle plus central dans l’évaluation des solutions, tout en continuant de solliciter l’expertise de l’équipe technique pour les aspects techniques des différentes options.

Les solutions envisagées

Nous évaluons donc plusieurs options: Ada chatbot, Zoom chatbot, Zendesk chatbot, IBM Watson… Les différentes options ont des avantages variables, cependant une option se détache du lot : Ada chatbot. Il check toutes les cases :

  • Un back-end utilisable sans devoir passer par des demandes aux équipes techniques
  • Une intégration légère et facile sur notre portail ou dans notre app
  • Un NLP engine puissant
  • Apprend automatiquement grâce au feedback donné par les utilisateurs
  • Intégration solide et flexible avec nos API
  • Livechat possible
  • Intégration avec Zendesk

Les autres solutions manquaient généralement une feature clef. Les facteurs disqualifiants étaient généralement l’absence de NLP, pas d’intégration à Zendesk, ou le manque de possibilité de développer des intégrations API puissantes avec nos systèmes. Ada était équipé de tout ce dont nous avions besoin.

Le développement commence. L’avantage d’Ada est que le back-end est user friendly. Je peux donc opérer avec des inputs limités de notre équipe dev (qui se charge de développer un API avec les endpoints nécessaires pour que le bot puisse répondre à des questions avancées). Je commence par intégrer notre FAQ entière dans le chatbot, en format conversationnel, et je développe les 5 – 10 cas « avancés » que nous avons identifié avec les équipes ops, parmi lesquels :

  • Quel est mon loyer
  • Où en est ma « maintenance order » (quand il y a quelque chose à réparer à la maison)
  • Je souhaite reprogrammer la visite du technicien
  • J’ai bien envoyé mon « move in payment » mais le portail m’indique que je dois encore de l’argent. L’avez-vous bien reçu ?
  • Je ne recois pas les filtres pour mon air conditionné (ou je les recois, mais la taille n’est pas bonne)

Lancement d’un pilote, confrontation à la réalité

Un chatbot, c’est un produit comme les autres, une fois qu’on a un MVP correct et raisonnablement utilisable, on le met devant les utilisateurs, et on regarde ce qu’il se passe. C’est le moment de l’intégrer à notre portail en ligne (celui que les résidents utilisent pour payer leur loyer et voir les informations de leur compte). Nous faisons une réunion avec mon chef, et son chef, le CTO afin de déterminer le lancement du pilote. D’après nos calculs, 2000 utilisateurs suffiraient pour avoir un bon feedback et une bonne idée des améliorations à apporter.

Les utilisateurs concernés

Typiquement, nous avons 2 types d’utilisateurs concernés par ce chatbot (ceux qui ont accès à notre portail en ligne) :

  1. les résidents qui ont signé un contrat avec nous, mais n’ont pas encore emménagé dans leur maison
  2. les résidents qui ont déjà emménagé chez eux.

Généralement, les résidents qui ont signé (de type 1 donc) emménagent chez eux en 11 jours en moyenne (et deviennent type 2). Tous les mois il y a entre 350 et 500 utilisateurs de type 1 qui signent des contrats avec notre entreprise.

La proposition de Pilote

  • 1000 utilisateurs de type 2 (résident déjà établis) ont un accès permanent au chatbot
  • A partir du lancement du chatbot nous laissons tous les utilisateurs de type 1 (futurs résidents) avoir accès au chatbot. Cela constitue un pool de 500 nouveaux utilisateurs par mois, avec des use cases spécifiques à leur istuation.
    • Lorsqu’ils émmenagent (et deviennent type 2), ils gardent l’accès au chatbot.

Le nombre d’utilisateurs total ayant accès au bot augmente donc au fur et à mesure de que nous signons des contrats avec de nouveaux résidents. Le rythme est raisonnable et contrôlé. Après 3 mois nous serons à peu près à 2000 utilisateurs (soit 0,01% du total de nos clients), et à priori, en travaillant bien sur les améliorations du bot, nous devrions avoir un produit correct sous 3 à 6 mois, et après lesquels nous l’ouvrirons à tous les utilisateurs.

Une contre proposition dégradée

Le CTO, semblant avoir une vision différente du projet, n’a pas accepté cette proposition, de peur que l’expérience utilisateur soit trop dégradée. Il a imposé ce qui suit :

  • 350 résidents établis (utilisateurs de type 2) qui auront accès permanent au chatbot
  • A partir du lancement du chatbot, nous laissons tous les utilisateurs de type 1 (futurs résidents) avoir accès au chatbot MAIS lorsqu’ils deviennent un utilisateur de type 2, ils en perdent l’accès.

Cela signifie que l’expérience utilisateur change pour nos nouveaux résidents une fois qu’ils emménagent, coïncidant avec une période où nous observons une baisse du NPS.

Visiblement la dégradation immédiate de l’expérience utilisateur prévalait, en comparaison de courir le « risque » d’étendre progressivement le pilote en recevant des feedbacks utiles, et en apportant des améliorations continues. Cela allait fortement nous ralentir puisqu’avec 350 utilisateurs de type 1, + temporairement les utilisateurs de type 2, le nombre de conversations générées n’allait pas être énorme.

Que s’est-il passé entre le moment où le CTO validait le chatbot, et le moment où il décidait implicitement de ralentir le développement et de minimiser tout progrès ? Une nouvelle CEO est venue remplacer l’ancien CEO, avec pour objectif d’améliorer les opérations et la satisfaction client. Avec ce changement, le CTO est entré dans une dynamique de réduction du risque (pour lui, présenter un nouveau produit est un risque) et mécaniquement, des opportunités de progrès.

Résultat

Après deux mois d’intéractions entre les résidents et le bot, 46% des requêtes utilisateurs trouvaient une résolution claire. Pour arriver à ce chiffre, je lisais chaque conversation, et me posais la question « si j’étais dans la position du résident, est-ce que cette réponse résoud mon problème ou pas? ». La réponse était oui dans 46% des cas. En août 2023, Ada a sorti un outil d’analyse basé sur les capacités d’un LLM, dont l’analyse nous donne un chiffre de 42%. La différence de 4% tient du fait que le LLM n’analysait pas TOUTES les conversations, et il a fait 2 ou 3 erreurs, influencant un peu le pourcentage puisque l’analyse s’est faite sur un nombre de conversations limité.

Question fondamentale

Si vous aviez une technologie qui répondait à 46% des requêtes utilisateurs de façon instantannée, est ce que vous l’implémenteriez ? (46% de 10.000 à 15.000 tickets par mois, c’est 5.000 à 7.500 tickets en moins par mois, ou 200 tickets en moins à traiter par jour)

La réponse de l’équipe produit est oui. La réponse des équipes ops (dont le travail est d’intéragir avec les résidents) est oui. La réponse du CTO? Non. Pourquoi ? « L’expérience utilisateur n’a pas l’air bonne ». Sur base de quoi est faite cette affirmation ? *silence*.

Dans ce cas-ci, les actions du CTO ont souvent entravé l’avancement du projet. Les raisons de ces décisions n’ont pas été clairement communiquées à l’équipe. Les arguments avancés n’étaient que rarement justifiés. Nous proposons une augmentation de l’échelle du pilote, mais ces propositions sont toujours refusées, sans raisonnement clair. Un des rares arguments avancés est que parfois, les utilisateurs donnent un mauvais rating aux conversations (à la fin d’une conversation, les utilisateurs sont invités à donner leur avis), mais ce feedback est une nécessite absolue pour pouvoir continuer d’améliorer le chatbot. C’est d’ailleurs un processus essentiel en product management.

Des défis d’alignement interne et des décisions parfois contradictoires

Cet argument n’est pas rationnel non plus, voilà pourquoi : nous avons exposé plusieurs produits aux résidents : le chatbot, une résident app, des agents répondant aux tickets zendesk. Parmi tous les produits, le chatbot est celui qui obtient le meilleur ratio entre les mauvais ratings et les bons ratings.

  • Chatbot: 85% de rating positif
  • App: 65% de rating positif (et les utilisateurs ne sont pas tendres sur les App Stores)

L’application mobile a été rendue disponible pour tous les utilisateurs, avec certaines fonctionnalités déplacées exclusivement vers cette plateforme. Cela a soulevé des questions sur les critères de décision entre les deux produits.

Il m’a été rapporté que le CTO avait mentionné au CEO que le chatbot n’utilisait pas les dernières technologies d’AI, en contradiction avec les informations que nous lui avions données sur le projet.

Quelles leçons tirer de tout cela ?

Une observation majeure de cette expérience de six mois est l’importance d’avoir une dynamique claire et bien définie entre les équipes produit et technologique.

Dans un fonctionnement normal, le Produit défini les besoins que l’équipe Technique devra développer. L’équipe technique donne son feedback et ses recommandations éventuelles, choisit les technologies à utiliser pour répondre à ces besoins selon les requirements définis. L’équipe technique sera également reponsable de la maintenance des produits.

Ici, nous avons une équipe Produit sous l’autorité directe d’un CTO qui commet l’impair d’imposer des décisions produits et des changements de scope, sans apporter de raisonnement ou justification. Ses interventions causent mécaniquement le blocage et la sous performance du chatbot, sans aucune « accountability » : Les conséquences de ces décisions sur le projet ne l’affecteront pas.

Comment aurait-il été possible de mieux faire?

Pour l’instant, je pense que dans les conditions existantes, il aurait été difficile de mieux faire. Parfois, les choses sont en dehors de notre contrôle, et il faut avoir conscience de ces situations pour adapter les attentes que l’on a du travail que l’on fait. Ca n’est pas une approche très épanouissante, mais dans ce genre d’entreprises, on en arrive souvent à cela.