Un bot de atención al cliente mal diseñado no ahorra dinero: lo traslada. Reduce una partida visible —el coste del equipo de soporte— y aumenta otras que nadie atribuye a esa decisión: clientes que se van, reclamaciones que escalan, reputación que se erosiona y, cada vez más, responsabilidad legal por lo que el sistema afirma.
El balance se presenta casi siempre a medias. Se enseña el coste evitado por consulta automatizada, que es fácil de calcular, y no se enseña el coste de las consultas mal resueltas, que es difícil de calcular y considerablemente mayor.
En 2024, el Civil Resolution Tribunal de Columbia Británica resolvió el caso *Moffatt contra Air Canada*. Un cliente había consultado al chatbot de la aerolínea sobre las tarifas por duelo y el sistema le dio información incorrecta. Cuando reclamó, la compañía argumentó que el chatbot era, en esencia, responsable de sus propias afirmaciones.
El tribunal calificó ese argumento de notable —en el sentido de sorprendente— y condenó a Air Canada a indemnizar al cliente. La cuantía fue simbólica: 812,02 dólares canadienses. El precedente no lo es.
Lo relevante para cualquier dirección es esto: lo que dice tu bot lo dice tu empresa. No hay arquitectura de descargo. Si el sistema promete un reembolso, una condición o un plazo, la organización responde de ello igual que si lo hubiera dicho un empleado. Y a diferencia de un empleado, el sistema puede decirlo a diez mil personas antes de que nadie lo detecte.
رحيل | Cómo se mide | Quién la ve |
Ahorro en soporte | Consultas automatizadas x coste por consulta | Dirección de operaciones, cada mes |
Clientes perdidos | Churn de quienes tuvieron una mala interacción | Nadie lo atribuye al bot |
Escalado tardío | Coste de resolver una incidencia agravada | Soporte, sin trazar el origen |
Reclamaciones formales | Tiempo legal y compensaciones | Legal, meses después |
Reputación | Reseñas, redes, boca a boca | Marketing, sin causa identificada |
La asimetría es estructural: el ahorro se mide con precisión mensual y se atribuye directamente al proyecto; el daño se dispersa en cinco departamentos y nunca se atribuye a nadie. Por eso los proyectos de automatización de soporte se presentan casi siempre como éxitos aunque el cliente esté peor atendido.
La forma de corregir esa asimetría es medir el balance completo desde el principio, no después. Y la métrica que lo captura mejor no es la tasa de automatización, sino la tasa de resolución en la primera interacción combinada con la satisfacción de los casos escalados. Un bot que automatiza mucho y escala mal produce un número excelente y un cliente enfadado.
No permite salir. El síntoma que más rápido destruye valor. Un cliente que no encuentra la forma de hablar con una persona no se queda: se va o escribe en público. La opción de escalado debe estar visible desde el primer mensaje, no escondida tras cinco intentos fallidos.
No sabe quién eres. Un bot sin acceso al contexto del cliente —pedidos, incidencias abiertas, historial— obliga a repetir información que la empresa ya tiene. Es la señal más clara de un sistema instalado encima del proceso en lugar de integrado en él.
Afirma con seguridad lo que no sabe. El problema no es que se equivoque, es que se equivoca con el mismo tono con el que acierta. Un sistema bien diseñado tiene condiciones explícitas para decir «no puedo confirmarte eso» y pasarlo a una persona.
Promete cosas que la empresa no va a cumplir. Aquí está el riesgo legal. Cualquier compromiso sobre importes, plazos, reembolsos o condiciones debería salir de una fuente de verdad del sistema, no de la generación del modelo.
No aprende de lo que escala. Cada caso escalado es un dato sobre lo que falta. Si nadie revisa periódicamente los escalados para corregir el diseño, el bot no mejora: solo envejece.
Hemos analizado un caso concreto de este patrón y sus consecuencias en cómo un chatbot arruinó la reputación de una empresa
La diferencia entre los dos resultados no está en el modelo. Está en cuatro decisiones de diseño que se toman antes de escribir código:
Decidir qué NO va a hacer. Antes que el alcance, el fuera de alcance. Reclamaciones, temas legales, casos de clientes en situación especial, cualquier cosa que implique un compromiso económico. Esa lista debe ser explícita y debe escribirla el negocio, no el equipo técnico.
Conectarlo a la fuente de verdad. El estado de un pedido no debe generarse: debe consultarse. La generación de lenguaje sirve para explicar, no para determinar hechos. Esta distinción —el modelo redacta, el sistema decide— elimina de golpe la mayor parte del riesgo.
Diseñar el escalado como parte del producto. Con contexto completo, sin que el cliente repita nada, con un plazo comprometido. Un buen escalado es una experiencia positiva; uno malo es peor que no haber tenido bot.
Medir la satisfacción del cliente escalado, no solo la del automatizado. Es el indicador que detecta el daño antes de que aparezca en el churn.
Una organización que toma estas cuatro decisiones puede desplegar automatización con tranquilidad. Una que no las toma está apostando su relación con el cliente al comportamiento de un componente probabilístico.
Hay contextos donde la respuesta correcta es no automatizar la primera línea:
En estos casos, la automatización tiene más sentido en la trastienda: preparar la respuesta que después envía una persona, resumir el historial antes de la llamada, clasificar y enrutar. El ahorro es real y el riesgo con el cliente es cero, porque hay una persona en medio.
No es «cuánto vamos a ahorrar». Es: ¿cuánto nos cuesta un cliente que se va enfadado, y cuántos tendrían que irse para anular el ahorro?
En la mayoría de las empresas B2B, ese número es incómodamente pequeño. Hacer la cuenta antes es lo que separa una automatización rentable de un ahorro que se paga con la base de clientes.
Sí. En el caso Moffatt contra Air Canada (2024), el tribunal civil de Columbia Británica rechazó el argumento de que el chatbot fuera responsable de sus propias afirmaciones y condenó a la aerolínea a indemnizar al cliente por la información incorrecta que el sistema había facilitado.
Por una asimetría de medición: el ahorro en soporte se calcula con precisión mensual y se atribuye al proyecto, mientras que el daño —clientes perdidos, incidencias agravadas, reclamaciones y reputación— se dispersa entre varios departamentos y no se atribuye a la automatización.
La tasa de resolución en la primera interacción combinada con la satisfacción de los casos escalados. La tasa de automatización aislada es engañosa: un bot que automatiza mucho y escala mal produce un buen número y un cliente insatisfecho.
Decirlo explícitamente y escalar a una persona con el contexto completo, sin que el cliente tenga que repetir información. El problema de un mal bot no es equivocarse, sino afirmar con el mismo tono de seguridad tanto cuando acierta como cuando no.
Separando dos funciones: el sistema determina los hechos consultando la fuente de verdad (estado del pedido, condiciones contratadas, importes) y el modelo solo redacta la explicación. Cualquier compromiso económico o de plazo debe quedar fuera del alcance de la generación de lenguaje.
Cuando el volumen es bajo y cada cliente pesa mucho en la facturación, cuando la mayoría de las consultas son reclamaciones, cuando el sector tiene alta carga emocional o regulatoria, o cuando la empresa compite por su atención personal. En esos casos la automatización rinde mejor en la trastienda, preparando lo que después envía una persona.
¿Vas a automatizar atención al cliente? Diseñamos primero qué no debe hacer el sistema, lo conectamos a tu fuente de verdad y construimos el escalado como parte del producto. Analizamos tu caso en dos horas, sin compromiso. لنتحدث → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
