Dans mes projets, je constate régulièrement à quel point les attentes envers les voicebots ont augmenté. De nombreuses organisations se lancent dans cette aventure avec l'espoir de mettre en place un service complet basé sur l'IA en quelques semaines. La réalité est tout autre. Les voicebots ont aujourd'hui de nombreuses capacités, mais ils ont besoin d'une base solide, d'objectifs clairs et d'organisations prêtes à investir un peu plus d'énergie au début.
Dans mon webinaire (en allemand uniquement) organisé dans le cadre de la 16e Semaine du service client, j'ai présenté deux projets qui illustrent très bien les possibilités existantes et les pièges à éviter. Ces deux cas d'utilisation proviennent du secteur public et avaient le même objectif : soulager le centre de service et automatiser les demandes standard. Néanmoins, les projets ont abouti à des résultats très différents.
Un robot vocal comme premier point de contact : ce qui fonctionne bien et ce qui ne fonctionne pas
Dans le premier projet, le défi résidait dans le volume très élevé d'appels. Le personnel était constamment interrompu tout en aidant les citoyens sur place. L'objectif était de réduire la charge de travail d'au moins 50 %.
L'autorité a donc décidé de rediriger tous les appels publics vers un robot vocal. Ce n'est que lorsque le robot ne pouvait pas répondre à la demande que l'appelant pouvait laisser une demande de rappel. Ces demandes de rappel sont envoyées sous forme d'e-mail avec un résumé et une transcription détaillée à la boîte mail du personnel de l'autorité afin qu'il puisse les traiter dès qu'il en a le temps.
Au départ, l'approche semblait simple. L'idée était de reprendre les textes existants de la FAQ du site web et de les utiliser pour créer un bot. Nous avons donc commencé par un bot NLU (Natural Language Understanding) classique. Le client ne voulait prendre aucun risque et insistait pour que le parcours client soit strictement défini.
Mais c'est précisément là que nous avons réalisé à quel point le sujet était complexe. Le contenu des sites web n'est pas rédigé pour les chatbots vocaux. Il s'enrichit souvent au fil du temps, avec des contenus qui se chevauchent ou sont imprécis. Or, un chatbot a besoin d'informations claires, sans ambiguïté et bien structurées. Les dialogues semblaient rigides et n'auraient pas satisfait les appelants.
Le passage à un bot LLM (Large Language Model, LLM) a été un véritable tournant. L'enthousiasme était grand : dialogues humains, empathie, formulations variées. Le bot disait « Oh, ça a l'air génial » ou « Je suis désolé d'apprendre cela ». Il était capable de répondre à la même question de différentes manières et réagissait de façon plus humaine sans s'écarter des directives définies.
Résultats mesurables
Le résultat était clairement mesurable. Seulement environ 20 % des appels initiaux ont donné lieu à des demandes de rappel pour le personnel. La plupart des cas ont été résolus de manière satisfaisante par le bot. Un effet secondaire très appréciable : les appelants récidivistes ont disparu, car le bot n'émet pas de signal « occupé ». Les employés ont désormais beaucoup plus de temps à consacrer aux citoyens sur place. C'était exactement le soulagement que le client espérait.
Le robot raccroche à 15 % des appelants, principalement après des conversations fructueuses. Entre 30 et 40 % des appelants raccrochent eux-mêmes. Ici, nous avons dû examiner les transcriptions pour déterminer si cela était positif ou négatif.
Ce que nous avons appris de ce projet
Ressources humaines
Vous pouvez obtenir des résultats rapides, mais aucun projet de voicebot ne fonctionne sans la participation active du client. Cela inclut la maintenance de la base de connaissances, la création d'un glossaire, les tests, la compilation d'un lexique de prononciation correcte pour la synthèse vocale et la révision du contenu. En plus d'un expert en la matière, il faut disposer d'un support technique qui s'occupe des API et qui maîtrise le scripting en JavaScript ou XML. Des ressources de test sont également nécessaires. Pour un projet de cette envergure, vous avez besoin d'au moins deux interlocuteurs dédiés du côté client, idéalement trois.
Connaissances LLM
Un autre point important concerne les connaissances générales intégrées au LLM. Un modèle apporte toujours ses propres connaissances de base. Il doit être activement contraint afin de rester dans le cadre du contenu fourni. Cela fonctionne bien, mais pas à 100 %. Vous devez tester, corriger et ajuster chaque fois que nécessaire.
Naturel
Lorsqu'un citoyen pose une question, le bot « réfléchit » : conversion de la parole en texte, texte dans le LLM, conversion du texte en parole. Ces pauses doivent être comblées. Bruits de frappe, petits marqueurs d'hésitation, variations de volume. Les variations du bruit de fond contribuent à rendre le dialogue plus naturel.
Intrusion
La plupart des fournisseurs de bots sont désormais également capables de ce que l'on appelle le « barge-in », c'est-à-dire d'interrompre le dialogue. Le bot doit accepter d'être interrompu. Par exemple, si l'appelant a déjà reçu les informations dont il a besoin, il ne devrait pas avoir à attendre la fin du script du bot. L'inconvénient est que les bruits de fond peuvent également être interprétés comme une interruption, par exemple sur un quai de gare. Les paramètres de sensibilité peuvent résoudre ce problème.
Deuxième exemple : lorsque le transfert d'appel fait partie du processus
Le deuxième projet concernait également des FAQ, mais les exigences étaient différentes. Le bot était censé répondre aux demandes et soulager le centre de service – l'objectif était également de 50 %. Cependant, pendant les heures d'ouverture, les appels devaient être transférés au personnel du backend ou du centre de contact si nécessaire. Il n'y avait pas d'option de rappel. De plus, le système Avaya existant devait être intégré en ce qui concerne le transfert du bot vers l'employé.
Intégration technique
L'intégration technique était un aspect essentiel. L'appel arrive au centre d'appels, est redirigé vers le robot vocal et doit être renvoyé à un employé si nécessaire. L'identifiant de routage doit être fourni et renvoyé, via des informations utilisateur à utilisateur ou la manipulation de l'en-tête SIP. Cela garantit que l'appel apparaît correctement dans l'historique des rapports.
Nous avons également intégré le service Call Data Service de Parloa. Le résumé de l'appel apparaît dans l'interface Avaya avant que l'employé n'accepte l'appel. Cela permet aux agents de voir à l'avance de quoi il s'agit.
Résultats
Une fois encore, nous avons rencontré le même problème au début : le client souhaitait importer les FAQ du site web. Et une fois encore, cela n'a pas fonctionné. Le contenu a dû être révisé manuellement.
Un taux de transfert de 50 % a été atteint, ce qui constitue un succès partiel. Idéalement, le transfert ne devrait pas être nécessaire, mais les 50 % restants ont été automatisés avec succès.
Le taux de raccrochage du bot était de 10 %, ce qui est un succès après examen des transcriptions. Le taux de raccrochage des clients était de 40 %, ce qui doit être examiné de plus près. Est-ce un succès ou non ? Les transcriptions doivent être vérifiées à nouveau et les conversations examinées. Une option consiste à mener une enquête de satisfaction à la fin de la conversation dans le bot.
Leçons tirées du deuxième projet
Temps nécessaire
La durée du projet était de trois mois. Cela a bien fonctionné. La conception, la configuration et les tests techniques de notre côté ont nécessité environ 20 jours-personnes.
Ressources humaines
Nous disposions de trop peu de ressources clients ici. Cela nous a occasionné un surcroît de travail imprévu.
Inscription
Un point important pour les deux robots. Le citoyen doit consentir à l'enregistrement. Le robot enregistre toujours tout – les transcriptions complètes sont toujours disponibles, qu'elles soient supprimées après 7 ou 30 jours.
L'adhésion doit être demandée. Les citoyens doivent également avoir la possibilité de dire « Non, je ne souhaite pas continuer ». Ils peuvent également continuer et, comme nous l'avons vu dans le premier cas, demander à être rappelés et ne fournir que le minimum d'informations les concernant.
Dans ce cas, il peut être judicieux de commencer par la NLU, c'est-à-dire l'approche structurée, puis de poursuivre avec l'approche LLM-Agentic afin de garantir que l'opt-in est correctement géré. Avec un démarrage complet en LLM, cette étape peut être involontairement contournée.
Ce que nous avons appris des deux projets
Les voicebots sont aujourd'hui très performants. Mais ce ne sont pas des produits prêts à l'emploi. Pour réussir, vous devez prendre trois choses au sérieux.
Premièrement : le contenu. La qualité d'un bot dépend entièrement de la base de connaissances que vous lui fournissez. Les textes des sites web ne peuvent presque jamais être utilisés tels quels. Ils doivent être révisés et structurés.
Deuxièmement : les ressources. Sans experts côté client pour tester, corriger et maintenir le contenu, le projet deviendra lent et difficile.
Troisièmement : la gestion des attentes. Il y a presque toujours une phase où la qualité n'est pas encore suffisante. Si vous continuez à vous améliorer, la qualité augmente rapidement. Dans les deux projets, nous avons obtenu des taux de réussite élevés et des appelants satisfaits.
Conclusion
Les voicebots sont un véritable soulagement lorsqu'ils sont correctement configurés. La technologie est mature, mais elle nécessite une mise en œuvre minutieuse. Si le contenu, les tests et la collaboration sont bien gérés, vous atteignez un stade où la plupart des demandes sont automatisées et où les équipes ont plus de temps à consacrer aux cas qui nécessitent véritablement une attention humaine.
