Cómo probar un chatbot empresarial antes de ponerlo en marcha

Un asistente automático no se pone a prueba leyendo unas cuantas conversaciones y concluyendo que «responde bien». Responde bien a las preguntas que hacéis vosotros, que ya conocéis las respuestas y usáis vuestras palabras. Las preguntas reales llegan mal escritas, incompletas, sobre casos que nadie había previsto. La prueba sirve para encontrarlas antes de que las haga un cliente.

El método no requiere herramientas especiales: una lista de preguntas, una respuesta esperada para cada una, un resultado anotado a mano. Requiere, eso sí, la disciplina de repetirlo cada vez que algo cambia.

Las preguntas de prueba proceden de las solicitudes reales

Las preguntas inventadas en una reunión se parecen a las respuestas que el sistema conoce. Es un defecto sistemático: quien las escribe ya sabe qué hay en los documentos.

• Se parte de las solicitudes recibidas: mensajes de soporte, solicitudes desde la web, apuntes de quien responde al teléfono. Se eliminan los datos que identifican a las personas y se mantiene la pregunta tal como estaba escrita, errores incluidos.
• Se cubre lo ordinario y lo raro: no solo las diez preguntas más frecuentes, sino también las que llegan una vez al mes y ponen en apuros a quien responde.
• Se incluyen las preguntas a las que no hay que responder: precios a negociar, casos contractuales, solicitudes que afectan a terceros.
• Se añaden las preguntas formuladas mal: media frase, dos preguntas juntas, un detalle equivocado dado por cierto.

Un centenar de preguntas recogidas así vale más que mil construidas sobre el papel, porque reflejan la distribución real de las solicitudes, incluidas las incómodas.

Las pruebas que nadie tiene ganas de hacer

• Preguntas con una premisa falsa: «ya que también hacéis esto…», cuando esa cosa no se hace. El sistema debe corregir, no seguir la corriente.
• Intentos de hacerle ignorar las instrucciones recibidas o de hacerle decir cosas que la empresa nunca diría. No es una hipótesis teórica: ocurre en los sistemas públicos.
• Preguntas sobre temas cercanos pero fuera del perímetro, para verificar que se reconoce el límite.
• Solicitudes que piden un compromiso: un descuento, una fecha, una garantía.

Qué es una respuesta aceptable

Antes de probar hay que decidir qué se considera correcto, si no, el juicio cambia según la persona que lee y la hora del día.

1. El contenido: qué información debe estar para que la respuesta sea útil, y cuál no debe aparecer.
2. La fuente: de qué documento debe venir. Una respuesta correcta tomada del documento equivocado es un problema aplazado, que se presenta cuando ese documento cambia.
3. La abstención: para ciertas preguntas la respuesta correcta es decir que no se sabe e indicar otro camino. Debe escribirse como resultado esperado, si no, quien evalúa lo marca como fallo.
4. La forma: una respuesta correcta pero tres veces más larga de lo necesario, dentro de un chat, es una respuesta que nadie lee hasta el final.

La ficha de evaluación

Las pruebas se registran en una sola tabla, que sirve para comparar dos versiones y para mostrar a los demás cómo va. Las filas de aquí abajo son ilustrativas.

La columna de la gravedad es la que hace tomar las decisiones. Una imprecisión en un detalle no pesa igual que un compromiso asumido en nombre de la empresa: la escala debe acordarse antes, y la distinción mínima es entre respuestas imprecisas, respuestas equivocadas y respuestas que vinculan o ponen en riesgo a alguien.

Más allá de los errores: qué vale la pena contar

• Las abstenciones: cuántas veces el sistema se ha detenido cuando debía, y cuántas veces se ha detenido pudiendo responder. Son dos defectos opuestos y se corrigen de formas opuestas.
• Los pasos a una persona, divididos por tema: indican dónde falta información pública.
• Las respuestas correctas pero inútiles: acertadas, genéricas, y dejan a quien lee exactamente en el mismo punto de antes.
• El comportamiento ante las excepciones: qué ocurre cuando un enlace no responde o un documento no es accesible. Un sistema que en ese caso improvisa es más peligroso que uno que se detiene.

Repetir las pruebas tras cada cambio

La lista de preguntas sirve sobre todo después de la primera vez. El comportamiento cambia cuando cambia una de tres cosas, y al menos una cambiará.

1. Las fuentes: un documento actualizado, una página reescrita, una tarifa nueva.
2. Las instrucciones: una regla añadida para corregir un caso rompe a menudo otras dos, y es la causa más frecuente de empeoramientos repentinos.
3. El modelo subyacente, que puede actualizarse sin que nadie en la empresa lo haya pedido.

Por eso las mismas preguntas deben repasarse periódicamente y antes de cada publicación. Es un trabajo aburrido, y es lo único que impide que las correcciones se anulen entre sí.

Cuándo las pruebas dicen que no hay que publicar

• Si quedan errores graves. Una respuesta que compromete a la empresa o que afecta a la seguridad no tiene una frecuencia aceptable.
• Si el sistema solo funciona con preguntas bien escritas: los clientes no escriben bien.
• Si las fuentes se contradicen entre sí. Ahí el defecto no es del sistema: está mostrando una contradicción que ya existía, y hay que arreglarla antes.
• Si no existe un paso hacia una persona que funcione de verdad.

Lo que esta guía no cubre

Aquí se habla de la calidad de las respuestas: cómo se prueba, cómo se registra, cuándo se puede publicar. El camino de salida hacia una persona —cuándo detenerse y qué transferir— se diseña aparte. Y la evaluación económica del proyecto, es decir, si y cuánto conviene, sigue criterios distintos y no se deduce del número de respuestas correctas.