Définir d'abord les conditions dans lesquelles l'IA doit cesser de fonctionner.
L'utilisateur peut exprimer clairement sa demande, notamment en cas de : Mauvaise compréhension par un humain,; Manque de champs obligatoires,; Implication de flux financiers ou de droits,; Utilisation de mots-clés à haut risque,; État "non gérable" retourné par une API d'entreprise,; Anomalies dans un modèle ou un service téléphonique. Ces situations peuvent constituer des conditions de prise en charge. Il est important que ces conditions soient formulées sous forme de codes de raison, plutôt que de simples jugements subjectifs basés sur le modèle. Cela permettra au service client de comprendre la raison de l'appel, et au service opérationnel de distinguer les problèmes liés à la conception du processus ou à la qualité du modèle.
Intervention manuelle pour déclencher et gérer les événements.| Causes | Ce que l'IA devrait faire | Points clés extraits des échanges |
|---|
| Les utilisateurs souhaitent une interaction avec un être humain. | Vérifiez immédiatement et rejoignez la file d'attente appropriée. | Statut confirmé et en attente de confirmation. |
| Malentendus répétés ou manque de confiance | Arrêtez de spéculer et expliquez la fonction de l'adaptateur. | Problèmes initiaux, champs de réponses et nombre de répétitions. |
| Points sensibles ou à risque élevé | Ne pas effectuer d'opérations irréversibles. | Classification des risques et données relatives aux affaires concernées |
| Échec du système d'entreprise | Sans prétendre à un succès immédiat, il est préférable de laisser la situation se développer et de la gérer de manière proactive. | État de l'API, identification des requêtes et possibilité de les retenter |
| Les sièges réservés sont inutilisables. | Proposer la possibilité de faire la queue, de rappeler ou de créer une tâche à traiter. | Informations de contact, horaires et identifiant de suivi |
Il est nécessaire de mesurer séparément les changements de connexion et les augmentations de capacité anormales.
La transition vers un agent humain est conçue dès le départ pour être effectuée par un humain, par exemple, en faisant d'abord que l'IA collecte les données, puis en les transmettant à un agent spécifique. Une escalade due à une incapacité de l'IA à comprendre, à une défaillance du système ou à un mécontentement de l'utilisateur entraîne également une sortie. Le mélange de ces deux situations peut amener l'équipe à croire que toutes les transitions vers un agent humain sont des échecs d'automatisation, et peut également masquer les véritables problèmes de compréhension. Les indicateurs de service client virtuel de Google Cloud distinguent également entre la transition planifiée, l'escalade, la résolution et l'abandon.
Les systèmes PBX, SIP et les files d'attente de service client sont responsables de la véritable routage des appels.
Les applications d'IA peuvent proposer des objectifs et des raisons de transfert, mais les fonctions telles que le transfert vers un numéro spécifique, le transfert vers un groupe de numéros, le transfert vers un groupe de compétences, les heures d'ouverture, la file d'attente, le transfert vers une autre ligne et la continuité de l'enregistrement sont généralement gérées par un système PBX, une plateforme SIP ou un centre d'appel. Avant l'implémentation, il est essentiel de vérifier les fonctionnalités de transfert direct, de consultation, de conservation du numéro original, d'identification des appels inter-systèmes et de gestion des erreurs de transfert. Affirmer simplement "prise en charge de SIP" ne suffit pas à prouver que l'environnement téléphonique existant peut gérer toutes les routes.
La transmission des informations se limite aux données nécessaires pour accomplir la tâche.
Les sièges doivent connaître au moins les raisons de l'appel, les champs déjà renseignés, les problèmes non résolus, les résultats des requêtes système, les actions entreprises et les raisons des échecs. La présence ou non de l'enregistrement original, du transcript complet ou des champs sensibles doit être déterminée en fonction du rôle et de l'objectif. Si le travail peut être effectué avec un résumé et les champs nécessaires, il ne faut pas divulguer toutes les informations. De plus, l'écran du siège doit indiquer quels champs doivent être confirmés par l'utilisateur et lesquels sont simplement des estimations.
Contenu minimal recommandé pour la transmission| Documents | Utilisations | Modes de contrôle |
|---|
| Code de justification | Établir les priorités et déterminer les prochaines étapes. | Classification fixe, afin d'empêcher le modèle de générer des commandes d'accès arbitraires. |
| Champ confirmé | Éviter que les utilisateurs répondent à la même question plusieurs fois. | Indiquer le moment de vérification et la source. |
| Problèmes non résolus | Permettre à l'IA de reprendre la conversation directement. | Présenter séparément les résumés des modèles. |
| État du système | Évitez les requêtes ou les commandes répétées. | Inclut l'identifiant de requête unique et l'état final. |
| Résumé de la sécurité | Comprendre rapidement le contexte. | La protection des données personnelles est obligatoire, et l'accès à l'original est restreint. |
Il est essentiel de prévoir des mesures pour les cas de dépassement manuel, de déconnexion et de rupture de connexion.
Si tous les sièges sont occupés, l'utilisateur peut choisir d'attendre, de demander un rappel à un moment précis ou de créer un ticket. En cas d'échec de l'API de transfert, il est nécessaire de conserver l'appel initial, de réessayer via une file d'attente de secours, ou de fournir des instructions claires sur les étapes suivantes. Il est également important de vérifier l'objectif de la communication, le numéro utilisé et les politiques de l'entreprise avant de tenter de rappeler après une coupure. Chaque chemin de dégradation doit générer un identifiant de dossier et afficher un état visible pour l'utilisateur, sans écrire les erreurs dans un journal pour que l'utilisateur doive les saisir à nouveau.
L'efficacité d'une intervention manuelle doit être évaluée en tenant compte à la fois des causes et des conséquences.
Le taux de transfert ne permet que d'indiquer le nombre de fois où une intention est transférée vers un agent humain, et ne permet pas de déterminer de manière isolée si cela est positif ou négatif. Il doit être analysé conjointement avec le nombre de plans de transfert, les mises à niveau anormales, les erreurs de routage, les abandons de file d'attente, les premières solutions, le temps total de traitement et le pourcentage de répétitions par les utilisateurs. Si un certain nombre de plans de transfert est élevé, cela peut indiquer que la conception du processus est correcte. Si un champ spécifique provoque de manière répétée des mises à niveau anormales, cela indique qu'il est nécessaire de corriger le dialogue, les données ou le modèle.
GoGoCha ne fournit pas de preuves publiques de sa capacité à transférer des appels vers un centre d'appel complet.
Le contenu mis à disposition par GoGoCha permet de prouver l'intégration de l'accès téléphonique, de la plateforme de gestion des demandes partagées, des notifications en temps réel, ainsi que l'intégration du site web, de LINE, de l'application et de l'interface opérationnelle. Il ne fournit pas d'informations sur les modèles de PBX, les files d'attente de support client, les stratégies de gestion des appels ou les accords de niveau de service (SLA). Ces éléments, qui sont des aspects spécifiques à chaque environnement d'entreprise, ne peuvent pas être regroupés dans un ensemble de fonctionnalités de support client validé par GoGoCha.
