Qué hacer si el robot vendedor se equivoca

Los primeros tres minutos después de detectar el error

Mientras el diálogo va por el camino equivocado, cada mensaje siguiente del bot empeora la situación. La primera acción es detener la respuesta automática y pasar la negociación a una persona, no intentar corregir la formulación dentro del chat. Esto lo hace el mismo mecanismo que el traspaso habitual de un cliente caliente: el robot vendedor sabe pasar el diálogo a una persona si sabe que hay que pasarlo.

El segundo paso es registrar el hecho del error: a quién, en qué canal y a qué pregunta se dio la respuesta equivocada. Sin ese registro el análisis se convierte en un relato de memoria y la causa se encuentra por casualidad. Lo más sencillo es guardar una captura o un enlace a la ficha de la negociación en el CRM en el momento de detectarlo, antes de que la conversación baje en la lista.

El tercer paso es no borrar ni editar el mensaje del bot a posteriori. Es la única prueba de qué salió mal exactamente, y sin ella es difícil saber si el bot se equivocó en los datos, en el tono o en la lógica del traspaso al responsable. Un análisis sin el original guardado suele empezar de cero.

Qué escribirle al cliente después del error

El cliente no tiene por qué averiguar dónde se lió exactamente el bot: lo que le importa es qué pasa ahora. La fórmula «disculpe, aquí respondió un bot y se equivocó, ahora le escribe nuestro responsable» funciona mejor que intentar explicar la causa técnica. Reconocer el hecho sin excusas quita la irritación más rápido que una explicación larga.

Después es importante nombrar un paso siguiente concreto y no dejar al cliente esperando sin plazo. «Un responsable se pondrá en contacto durante el día» suena peor que «María le escribe en diez minutos», si ese tiempo se puede cumplir de verdad. Una promesa vaga después de un error ya ocurrido solo le da al cliente otro motivo para dudar.

Si el error fue en las cifras — precio, plazo, disponibilidad —, conviene enviar la corrección en un mensaje aparte y no mezclarla con la disculpa. Es más fácil leer dos mensajes cortos seguidos que un párrafo donde la disculpa y la información nueva van en un mismo bloque. Esto importa sobre todo cuando se habla de dinero: aquí la confusión sale más cara que en el resto de los temas.

Dónde buscar la causa: el prompt, la base de conocimiento o la conexión con el CRM

Los errores del bot casi siempre ocurren en uno de tres sitios, y cada uno se cura de forma distinta. El primero es el prompt, la instrucción con la que el bot entiende la pregunta y forma la respuesta: si interpretó mal lo que escribió el cliente, hay que precisar la instrucción, no cambiar los datos que la rodean.

El segundo sitio es la base de conocimiento: un precio caducado, un servicio retirado, una descripción errónea de las condiciones. Aquí el problema no está en la lógica del bot, sino en que la fuente de la que toma los datos no se actualizó a tiempo. Estos errores se repiten igual con distintos clientes, y esa es la primera señal de que no es cosa del prompt.

El tercer sitio es la llamada a la herramienta en el CRM: el bot pidió datos actuales de la negociación y no los recibió, o recibió otros. Eso ya es cuestión de integración y no de texto, y se arregla en el nivel de conexión de canales y campos, como se describe en la sección sobre la implantación del CRM. Mezclar estas tres causas en un mismo análisis es el motivo más frecuente de que el error vuelva un mes después con otra forma.

Qué hacer con la venta si el cliente ya se apoyó en un precio o condición erróneos

Si el cliente enseña la conversación y dice «su bot prometió un descuento», la decisión no la toma ni el bot ni el guion, sino una persona con autoridad. Hay tres caminos: registrarlo como excepción puntual para esa venta, compensar en parte la diferencia o negarse explicando que la información era errónea. No hay una opción universalmente correcta: solo está lo que sale más caro al negocio, la concesión puntual o la relación estropeada con el cliente.

Conviene decidir de antemano qué desviación resuelve el responsable en el momento y cuál necesita aprobación de arriba. Sin ese umbral, cada caso se convierte en una reunión aparte mientras el cliente espera respuesta. Un límite claro ahorra tiempo al dueño y al responsable.

Vale la pena hablarlo con el equipo: un error confirmado del bot no es motivo para culpar al responsable que siguió llevando la venta. Si no, el análisis de errores se convierte en una búsqueda de culpables en lugar de una corrección del proceso, y la próxima vez el fallo simplemente no se cuenta.

Cómo no perder estos casos y usarlos para enseñar al bot

Cada caso de error conviene marcarlo en el CRM con un estado o una etiqueta propia — «error del asistente», por ejemplo — directamente en la ficha de la negociación y no en un archivo aparte que nadie abrirá en una semana. Así, al mes se puede ver cuántos casos hubo y si se repiten en el mismo tema.

Es útil adjuntar a la ficha el fragmento de la conversación y no un resumen con tus palabras. El resumen pierde justo los detalles que hacen falta para saber si falló el prompt, la base de conocimiento o la integración. Un análisis de memoria dos semanas después casi nunca es exacto.

Los casos acumulados son una lista ya hecha de lo que hay que corregir en la base de conocimiento o en la lógica del bot en el siguiente ajuste. Sin etiquetarlos se dispersan por distintos chats y responsables, y la actualización solo llega cuando un mismo error provoca suficientes quejas como para notarse.

Qué medir para ver el problema antes que las quejas de los clientes

Para un bot que lleva ventas y no solo responde preguntas, no importan las métricas generales de satisfacción, sino contadores concretos. La proporción de diálogos escalados a una persona muestra con qué frecuencia el bot entiende por sí mismo que no se las arregla. Una proporción demasiado baja es una señal tan mala como una demasiado alta: significa que el bot o responde al azar donde debería pasar el caso, o carga a las personas con lo que podría cerrar solo.

El segundo contador es la proporción de respuestas erróneas en una revisión por muestreo de las conversaciones: cuántos diálogos elegidos al azar resultan inexactos en los datos. No es una comprobación única, sino un muestreo regular; si no, la cifra envejece rápido. El tercero es el tiempo de reacción de la persona después de que el bot le pasa la negociación: si entre la escalada y la primera respuesta humana pasa demasiado tiempo, se pierde parte del sentido de la rapidez del bot.

En el proyecto GetGate en marcha, en una comparación a ciegas la respuesta del asistente no fue peor que la de una persona en el 80% de los casos: es una referencia para una tarea parecida, no una garantía para cualquier negocio. Justo esa comprobación — comparar respuestas del bot y de una persona sobre conversaciones reales — conviene hacerla con regularidad y no una sola vez al arrancar. Más sobre cómo funciona esto en el día a día, en la sección sobre el control de calidad.

Cómo se ve esto en la práctica cuando las reglas son imprecisas

Una causa frecuente de errores no es un fallo del bot, sino una regla imprecisa en la entrada. Si con el responsable se acordó que el bot atiende todas las negociaciones salvo las grandes y los clientes VIP, pero esas excepciones no están fijadas como regla aparte en el CRM, tarde o temprano el bot cogerá justo la negociación que debía llevar una persona concreta. La frase «esas de momento las lleva un compañero» suena clara en una conversación, pero tiene que quedar escrita como condición y no como acuerdo de palabra.

Una situación parecida es el cambio de canal de contacto con el cliente. Si el contacto se actualizó en el CRM y el cliente ahora escribe no por WhatsApp sino por otro canal, pero la ficha de la negociación no lo refleja, el bot puede seguir con la lógica del canal antiguo o perder el historial. Esos cambios conviene anotarlos enseguida en la ficha y no guardarlos en la memoria de una sola persona.

La tercera señal típica es la pregunta «¿por qué el bot no responde nada?», que normalmente no significa un error en el texto de la respuesta, sino un fallo en la conexión del canal o en la integración. Conviene anotarla en el mismo registro de incidencias que los errores de sentido, porque la causa se encuentra igual: mirando dónde se cortó la cadena, en el canal, en el CRM o en el propio bot.

Cómo montar el proceso para que los errores no se acumulen en silencio

Corregir una sola conversación no resuelve el problema: al mes aparecerá un error parecido en otro canal o con otra persona. Un proceso estable se apoya en tres cosas: una regla de escalada clara, una revisión regular por muestreo de las conversaciones y la búsqueda de la causa en los tres sitios — prompt, base de conocimiento, integración — en vez de a ciegas. Sin esa rutina, el análisis de errores depende de un empleado atento y no de un proceso.

En el proyecto GetGate el 27% de las solicitudes llegan por la tarde y los fines de semana, cuando antes el cliente esperaba hasta la mañana; justo en esas horas hay menos control humano y el bot trabaja sin pausa. Es exactamente el momento en que la regla de escalada y un registro de incidencias escrito importan más: no hay nadie allí para detectar el fallo si no queda anotado automáticamente.

El tiempo liberado a la persona — en ese mismo proyecto, cerca de una hora al día — tiene sentido gastarlo no en volver a desmenuzar los mismos errores del bot, sino en revisar casos nuevos y ajustar las reglas. Así el control de calidad se vuelve parte del trabajo normal del departamento y no un incendio aparte. Si el proceso de análisis de errores hay que montarlo desde cero, eso está más cerca de la tarea de construcción del departamento de ventas que de un arreglo puntual de un solo diálogo.