Il est important de distinguer clairement : il s'agit d'un choix de canal, et non d'une question de supériorité technique.
Les deux systèmes reposent sur un processus de base similaire : « comprendre l'utilisateur, accéder à l'information, effectuer des actions ». La différence réside dans le point d'entrée. Le service client vocal se déroule par téléphone : il est immédiat, ne nécessite pas de frappe, est convivial pour les personnes âgées et les utilisateurs mobiles, mais chaque seconde compte, et une erreur nécessite de recommencer. Le chatbot, quant à lui, est présent sur un site web et sur LINE : il permet des réponses plus longues, l'ajout de liens et d'images, et conserve automatiquement l'historique des conversations, mais il ne peut pas interagir avec les clients qui préfèrent uniquement téléphoner. Par conséquent, la première question est toujours : « D'où viennent actuellement vos clients ? »
Quels sont les principaux facteurs qui influencent la structure des coûts ?
La structure de coûts des robots conversationnels est relativement simple : un coût initial de mise en place, plus des frais liés à l'utilisation de l'API du modèle. Cependant, le service de support vocal ajoute trois niveaux supplémentaires : Le niveau de l'opérateur (frais mensuels pour le numéro et nombre de minutes d'appel).; Le niveau de la reconnaissance et de la synthèse vocale (facturation basée sur l'utilisation audio).; Le niveau de la capacité (le nombre d'appels simultanés détermine la configuration des lignes et des ressources informatiques). C'est pourquoi notre MVP de support vocal par texte a un prix de base (30 000 TWD), tandis que le projet de support vocal exige une évaluation préalable de l'environnement avant de fournir un devis. Il est rare de trouver des prix qui tiennent compte de besoins spécifiques tels que les systèmes PBX, la capacité de gestion des appels simultanés et les exigences d'enregistrement.
Les schémas de défaillance varient, et par conséquent, la conception des réseaux de sécurité est également différente.
Les principaux risques liés aux robots conversationnels concernent le niveau de compréhension : mauvaise interprétation de l'intention, hallucinations du modèle, réponses inappropriées – ces problèmes peuvent être atténués grâce à la qualité de la base de connaissances, aux limites des réponses et à la possibilité de transfert vers un agent humain. Outre ces aspects, le service client vocal présente également des risques supplémentaires : erreurs d'identification, bruit de fond, accents, interruptions de communication. Par conséquent, le processus vocal doit inclure des mécanismes de vérification (champs importants pour que l'utilisateur confirme une information), un transfert vers un agent humain en cas de faible confiance, et la sauvegarde de l'état après une interruption de connexion. Lors de l'évaluation des fournisseurs, il est essentiel de se poser directement la question : "Que se passe-t-il lorsque l'on entend mal ?", et de s'assurer que les réponses vagues ne sont que des scénarios idéaux.
Comment choisir : en partant du comportement des clients, plutôt qu'en partant des aspects techniques.
La méthode de décision est pragmatique : examinez vos enregistrements de service client actuels. Les appels téléphoniques sont la méthode la plus courante, et les clients préfèrent la communication verbale (par exemple, pour les services locaux ou les clients âgés) – priorité à la voix ; les demandes sont principalement formulées via LINE et des formulaires en ligne, et conviennent aux réponses textuelles (par exemple, pour le commerce électronique ou la prise de rendez-vous) – priorité au texte ; dans les deux cas, évaluez la méthode la plus utilisée, puis mettez en œuvre cette méthode en premier. Si le budget est limité, un chatbot textuel est un point de départ plus accessible, car il élimine la complexité des aspects liés aux télécommunications et à la voix.
Utiliser les deux ensemble : partager une même infrastructure, mais avec des canaux distincts pour l'entrée.
Une architecture mature consiste à considérer la voix et le texte comme deux entrées d'un même système : une base de connaissances partagée (avec une maintenance dédiée), une logique de back-end partagée (pour la gestion des commandes, la création de tâches, et l'intégration manuelle via une API commune), et une stratégie de dialogue adaptée à chaque canal (la voix doit être concise et informelle, tandis que le texte peut inclure des liens). Notre cas GoGoCha, que nous mettons en avant, illustre cette approche : trois canaux (téléphone, site web, LINE) reçoivent la même demande via un back-end partagé. L'ordre d'utilisation des canaux peut être choisi librement, mais il est essentiel de prévoir dès la conception du back-end la possibilité de s'adapter à différents canaux, afin d'éviter de devoir tout refaire par la suite.
