Commencez par réduire le POC (Proof of Concept) en une tâche commerciale clairement définie.
Les POC (Proof of Concept) doivent être choisis en fonction de critères tels que des règles relativement claires, une quantité de communications prévisible, la possibilité de vérifier les résultats en arrière-plan, et la capacité de corriger les erreurs. Par exemple, la création d'un ticket à partir des données de réparation est plus appropriée que "la gestion de tous les problèmes de service client". Il est essentiel de définir clairement les points d'entrée de la conversation, les champs obligatoires, les actions possibles, les actions interdites, les conditions de transfert vers un opérateur humain, ainsi que la source des API et de l'environnement de test (entreprise ou tiers). Si la portée n'est pas clairement définie, la validation ne fera qu'aboutir à une évaluation subjective.
Commencer par établir des normes pour les processus manuels, puis discuter de l'amélioration grâce à l'IA.
Il est impossible de déterminer si le POC s'améliore sans un point de référence. Au minimum, il est nécessaire de documenter qui est responsable de chaque tâche, comment le succès est défini, les erreurs courantes, les temps d'attente, les données à saisir à nouveau, et la manière dont l'intervention humaine permet de résoudre les problèmes. Le point de référence ne doit pas nécessairement être un KPI attrayant ; un petit nombre de cas réels et vérifiés est préférable à des hypothèses faites par le fournisseur. Lors de la comparaison, il est essentiel d'utiliser les mêmes tâches, des conditions d'arrivée similaires et une définition du succès cohérente.
Les exemples de tests avec des métaux précieux doivent inclure des scénarios pour les cas de réussite, d'échec et de résultats ambigus.
Commencez par rédiger, en collaboration entre les équipes commerciales, du service client et les responsables système, les entrées, les questions attendues, les champs nécessaires, les actions autorisées et l'état final. Ensuite, soumettez ces données au système pour des tests répétés. Il ne s'agit pas d'utiliser uniquement des phrases standardisées, mais de prendre en compte les variations possibles, les erreurs de saisie, les homophones, le bruit de fond, les silences, les interruptions, les délais API et la nécessité d'interactions avec des humains. Lorsque des informations telles que des noms, des adresses, des montants ou des identités sont concernées, il est également important de vérifier si l'IA répète-t-elle la confirmation, plutôt que de simplement comparer les transcriptions mot à mot.
Matrice de test minimale pour la preuve de concept (POC) de l'assistance clientèle basée sur l'IA| Contexte | Quels éléments observer ? | Résultats vérifiables |
|---|
| Réalisation réussie | Champs obligatoires, ordre de suivi et appel d'outils | Correspondance entre les informations CRM/bon de commande/état de la demande et les enregistrements des appels. |
| Informations floues ou inexactes. | Vérifiez-vous et remplacez-vous les valeurs existantes ? | Ne conservez que les données de validation finales, et évitez de créer de nouvelles commandes. |
| Malentendu verbal | Faible confiance, reformulation et adaptation des conditions humaines. | L'erreur n'a pas été directement enregistrée dans le système principal. |
| Erreur API : délai d'attente dépassé ou requête refusée | Réponses, tentatives de reprise, traitement en cours et idempotence | Il est préférable de ne pas annoncer publiquement le succès avant que la situation ne soit définitivement établie, afin que les résultats puissent être vérifiés. |
| Demandes concernant des personnes réelles ou des situations à haut risque | Le routage adaptatif établit une connexion en fonction du contexte. | Champ "Déjà confirmé" et champs "Problèmes non résolus" marqués manuellement |
Les indicateurs doivent être liés aux tâches, et ne doivent pas se limiter à la simple mesure de la précision.
La reconnaissance vocale correcte ne signifie pas nécessairement la réussite de la tâche. Des erreurs dans le transcript ne doivent pas nécessairement avoir d'impact sur les résultats. L'évaluation doit prendre en compte la réalisation de la tâche, l'exactitude des champs requis, le succès des appels d'outils, la compréhension, les mécanismes de secours, la transition planifiée, les mises à niveau inattendues, l'abandon de l'utilisateur, les délais de réponse et les corrections manuelles. Chaque élément doit avoir une base de référence claire et une source de données, par exemple, en utilisant "un appel de test conforme aux exigences" comme référence, et en vérifiant les enregistrements téléphoniques, les événements du modèle, les journaux API et l'état final du système d'entreprise.
Évaluation de la qualité des dialogues et des résultats du système.| Indicateurs | Définition | Éviter les erreurs d'interprétation |
|---|
| Taux d'achèvement des tâches | Pourcentage d'appels qui respectent les critères définis et aboutissent à un état final correct. | Il ne faut pas considérer une simple conversation comme une tâche terminée. |
| Vérification de la conformité des champs obligatoires | Champ vérifié et correspondance avec la réponse correcte | La moyenne ne permet pas de masquer les champs essentiels tels que l'adresse, le montant, etc. |
| L'opération a été exécutée avec succès. | L'API fonctionne correctement et ne présente pas d'effets secondaires redondants ou erronés. | Il ne faut pas considérer une transaction en ligne comme ayant échoué ou réussi simplement en raison d'un retard. |
| Malentendus et mécanismes de secours | Le système ne parvient pas à comprendre ou à accéder aux requêtes répétées. | Il est important de distinguer les questions pertinentes et constructives des discussions stériles et improductives. |
| Intervention manuelle | Planification de la mise en service, mise à niveau et demandes des utilisateurs. | Le recours à l'externalisation n'est pas toujours une mauvaise chose. Il est important de la considérer en fonction des raisons qui la motivent. |
La hauteur du seuil d'accès doit être définie en fonction du coût des erreurs.
Il n'existe pas de seuil de réussite applicable à tous les téléphones d'IA. Les coûts associés à la vérification des horaires d'ouverture et à la modification des informations de paiement sont totalement différents ; même une erreur d'un seul mot dans une adresse peut être plus grave qu'un ton inapproprié. La méthode consiste à classer les erreurs en trois catégories : celles qui peuvent être corrigées automatiquement, celles qui nécessitent une vérification manuelle et celles qui ne peuvent pas être corrigées automatiquement. Ensuite, on définit un seuil et une personne responsable pour chaque catégorie. Si le nombre d'échantillons est insuffisant, on ne peut que dire que le POC n'a pas encore identifié de problèmes spécifiques, et qu'il ne faut pas en déduire que l'environnement de production atteindra nécessairement les objectifs.
La réception des équipements doit également inclure des tests de défaillance pour vérifier leur capacité à fonctionner en cas de panne.
Lors d'un service en production, il est inévitable de rencontrer des problèmes tels que des interruptions de connexion, des délais dépassés, des erreurs dans les API, des sièges occupés et des maintenances des fournisseurs. Lors d'une phase de test, il est essentiel de vérifier quelles sont les conséquences de chaque problème, dans quel état les données sont bloquées, qui reçoit une notification, et si une nouvelle tentative est possible après la résolution du problème. L'interface utilisateur et le back-end doivent afficher clairement et de manière compréhensible les erreurs, sans les masquer et donner l'impression que le problème a été résolu alors qu'il ne l'a pas été.
GoGoCha ne peut être utilisé comme preuve structurelle, mais pas comme données de contrôle générales.
GoGoCha a publié des études de cas démontrant que Falcon a mis en œuvre des fonctionnalités telles que l'accès à l'IA par téléphone, la gestion centralisée des demandes, les files d'attente, les notifications en temps réel, ainsi que l'intégration avec des sites Web, LINE, des applications et des back-ends. Ces études de cas ne fournissent pas de données sur la précision, la latence moyenne, le taux de réussite, les économies de main-d'œuvre ou les accords de niveau de service (SLA) pour les appels, de sorte qu'il est impossible de les utiliser pour établir des critères pour une autre entreprise. Les nouvelles POC (Proof of Concept) doivent être réévaluées en fonction de l'environnement téléphonique, de la langue des clients et des données spécifiques de l'entreprise concernée.
Quels livrables doivent être produits avant la mise en production à partir de la phase POC (Proof of Concept) ?
Il est essentiel de conserver au moins les cas de test avec des versions fixes, les détails des résultats, les risques non résolus, l'architecture du système, les flux de données, les autorisations, les mécanismes de surveillance, ainsi que les procédures de prise en charge et de restauration. La version finale doit également inclure des tests de charge et de simultanéité, des tests avec un système PBX/SIP réel, des mesures de redondance, des politiques d'enregistrement et les autorisations d'exploitation. Le POC (Proof of Concept) ne signifie que que la solution est prometteuse et qu'il est envisageable de la mettre en œuvre, mais ne garantit pas qu'elle peut être utilisée directement sans adaptation.
