Chatbot, centro de soporte u operador: elegir el recorrido para los clientes

La pregunta «¿necesitamos un chatbot?» llega casi siempre antes que la que de verdad importa: qué solicitudes recibís, cuántas veces, y qué hace falta para resolverlas. Algunas se resuelven con una página bien escrita, otras necesitan leer los datos de ese cliente, otras no deberían pasar nunca por una máquina. Esta guía sirve para hacer esta división antes de elegir la herramienta.

El coste de equivocarse no es técnico: es un cliente que da vueltas dentro de una conversación automática mientras la oficina está abierta y alguien podría responderle.

Un mes de solicitudes, puestas en fila

El material para decidir ya lo tenéis: el buzón de soporte, el registro de llamadas, los mensajes recibidos. Coged un periodo representativo y clasificad cada solicitud con tres preguntas.

• ¿La respuesta es la misma para todos, o depende de quién pregunta? «Cuánto duran los plazos de entrega» tiene una respuesta pública; «dónde está mi pedido» no.
• ¿Hace falta un dato que está en un sistema, y cuál? Estado del pedido, vencimiento de un contrato, disponibilidad de un artículo, historial de intervenciones.
• ¿Qué ocurre si la respuesta es errónea? Un horario de apertura equivocado es una molestia; una indicación errónea sobre el uso de un producto, sobre un vencimiento contractual o sobre una cantidad que pagar es otra categoría de problema.

Al final tendréis tres grupos muy distintos en tamaño: muchas preguntas repetitivas y públicas, un grupo considerable de solicitudes personales, y pocas solicitudes delicadas. Cada grupo tiene su respuesta, y no es la misma.

Si una página resuelve, lo demás sobra

Una parte de las preguntas repetitivas existe porque la información no está, o está en un punto que nadie encuentra. En ese caso construir un asistente conversacional significa poner un intermediario delante de un contenido que bastaba con escribir.

Antes de automatizar conviene preguntarse dónde nace la pregunta. Si «cuánto cuesta el envío» llega después de que el cliente haya mirado la ficha del producto, es que la ficha no lo dice, o no lo dice donde hace falta. Trasladar la información al punto donde nace la duda elimina la solicitud en lugar de gestionarla, y es casi siempre el trabajo menos caro.

Las solicitudes personales dependen de los datos

«Dónde está mi pedido» no es difícil de entender: es difícil de satisfacer, porque hay que saber quién escribe y leer un sistema. La parte exigente no es la conversación, son tres cosas tediosas.

• Reconocer al cliente de forma fiable, sin dar a cualquiera que conozca una dirección de correo el acceso a los datos de otra persona.
• Leer el dato donde es cierto, no de una copia actualizada una vez al día: un estado de envío con medio día de antigüedad genera más contactos de los que evita.
• Saber qué hacer cuando el dato no está o no está claro. Es el caso en el que un sistema mal diseñado inventa, y es el momento en el que pierde la confianza del cliente para siempre.

Si una de estas tres no está resuelta, esa categoría de solicitudes no está lista para la automatización, por muy frecuente que sea.

La matriz de solicitud y canal

El modo más rápido de poner de acuerdo a todos es una tabla con una fila por tipo de solicitud. Las filas siguientes son un ejemplo ilustrativo, para una empresa que vende y da soporte a productos.

La columna que se rellena en último lugar es la que más cuenta. Un recorrido automático sin una salida declarada no es un recorrido: es una trampa.

El paso al operador hay que diseñarlo

• Las condiciones de salida hay que escribirlas: palabras que indican una reclamación, dos intentos fallidos sobre el mismo punto, una solicitud explícita de hablar con alguien, un tema entre los reservados a las personas.
• Lo que se ha dicho debe llegar al operador. Hacer que el cliente repita todo anula la ventaja y empeora el humor de quien ya estaba descontento.
• Fuera de horario el comportamiento cambia: si nadie puede responder, el sistema debe decirlo y recoger un contacto, no prometer un paso que no llegará a producirse.
• Quien recibe los pasos debe saberlo y tener tiempo para hacerlo. Un canal más sin nadie que lo atienda produce solicitudes sin respuesta, que es peor que no haberlo abierto.

Qué medir

El número de conversaciones gestionadas no es un resultado: dice cuántas veces ha hablado la herramienta, no cuántas veces ha servido. Hacen falta medidas que miren el resultado.

• Cuántas conversaciones se cierran sin que el cliente vuelva a escribir o llamar por el mismo motivo en los días siguientes. Es el único indicador verdadero de resolución.
• Cuántas terminan con un paso a una persona, manteniendo distintos los pasos previstos de los debidos a un fallo.
• Qué preguntas reciben respuestas erróneas o genéricas. Hay que leerlas por muestreo, alguien que conozca el oficio, con una periodicidad decidida de antemano.
• Si la carga sobre los operadores ha bajado en las solicitudes repetitivas, o solo ha cambiado de canal.

Si después de un periodo razonable los pasos por fallo siguen siendo la mayoría, la conclusión no es que haga falta un sistema mejor: es que esas solicitudes no eran automatizables con los datos y los contenidos que tenéis hoy.

Lo que esta guía no cubre

Aquí se elige a qué recorrido confiar cada tipo de solicitud. Preparar los documentos y las fuentes en las que deberá basarse un asistente —qué ordenar, qué eliminar, cómo mantenerlos actualizados— es un trabajo aparte con una guía dedicada. También las reglas precisas con las que un asistente debe detenerse y llamar a una persona se tratan por separado.