Es importante distinguir: se trata de una elección de canal, no de una cuestión técnica.
Tanto los sistemas de voz como los de texto implican procesos de "entender al usuario, buscar información y realizar acciones", pero la diferencia radica en el punto de entrada. Los sistemas de voz operan en el teléfono: son inmediatos, no requieren escritura, son amigables con las personas mayores y los usuarios móviles, pero cada segundo se cobra, y si se malinterpreta, hay que empezar de nuevo. Los robots de texto operan en la página web y LINE: pueden responder lentamente, pueden incluir enlaces e imágenes, y los registros de conversación se conservan de forma natural, pero no pueden interactuar con los clientes que solo llaman. Por lo tanto, la primera pregunta siempre es: ¿De dónde vienen tus clientes actualmente?
¿En qué radica la diferencia en la estructura de costes?
La estructura de costes de los chatbots es relativamente sencilla: costes de implementación inicial más el uso de la API del modelo. En comparación, el servicio de atención telefónica implica tres capas adicionales: la capa de telecomunicaciones (tarifa mensual y minutos de llamada), la capa de voz (precios basados en el uso de audio para reconocimiento y síntesis), y la capacidad de concurrencia (que determina la configuración de la red y los recursos informáticos en función del número máximo de llamadas simultáneas). Por eso, nuestro MVP de chatbot tiene un precio inicial público (30.000 TWD), mientras que el proyecto de voz exige primero una evaluación del entorno antes de proporcionar una cotización. Es raro encontrar empresas que ofrezcan precios sin evaluar las necesidades específicas de PBX, concurrencia y grabación de voz.
Los patrones de fallo son diferentes, y el diseño de seguridad también lo es.
El principal riesgo de los robots de texto es en el nivel de comprensión: interpretación errónea de la intención, alucinaciones del modelo, respuestas incorrectas. La solución pasa por la calidad de la base de conocimientos, las limitaciones de las respuestas y los mecanismos de transferencia a un agente humano. Además de esto, los sistemas de voz tienen riesgos adicionales: errores de reconocimiento, ruido de fondo, acentos, interrupciones en la llamada. Por lo tanto, los procesos de voz deben incluir la repetición y la confirmación (campos importantes para que el usuario los confirme), la transferencia a un agente humano en caso de baja confianza y la conservación del estado después de la interrupción. Al evaluar un proveedor, es importante preguntar directamente: "¿Qué ocurre si se malinterpreta?". Mostrar escenarios ideales sin respuestas claras es inútil.
¿Cómo elegir? Basándose en el comportamiento del cliente, no en la tecnología.
La forma de decidir es muy práctica: revisa tus registros de atención al cliente actuales. Las llamadas telefónicas son la forma más común, y los clientes prefieren la comunicación verbal (por ejemplo, servicios locales, clientes mayores) —prioriza la voz; las consultas se centran en LINE y formularios web, y las preguntas son adecuadas para respuestas con imágenes y texto (por ejemplo, comercio electrónico, reservas) —prioriza el texto. Si ambas opciones son importantes, empieza por la que tenga más volumen, y luego amplía la otra. Si tienes un presupuesto limitado, los robots de texto son un punto de partida más sencillo, ya que no tienen la complejidad de las capas de telecomunicaciones y de voz.
Utiliza ambas: comparte la misma infraestructura, y el canal es solo el punto de entrada.
La arquitectura madura consiste en tratar el audio y el texto como dos entradas de un mismo sistema: un repositorio de conocimiento compartido (con mantenimiento) y una capa de backend compartida (para consultar pedidos, crear órdenes de trabajo, y transferir tareas a agentes a través de la misma API). Además, se adapta la estrategia de diálogo según el canal (el audio debe ser breve y conversacional, mientras que el texto puede incluir enlaces). El caso GoGoCha, que presentamos públicamente, es un ejemplo de esta idea: las entradas de teléfono, sitio web y LINE reciben la misma capa de backend para la gestión de pedidos. Se puede empezar con cualquiera de las entradas, pero lo importante es diseñar la capa de backend de forma que permita la integración con múltiples canales, evitando así tener que rehacer el trabajo más adelante.
