Este es un ejemplo de situaciones bloqueantes en las que un cliente puede llegar a encontrarse a la hora de interactuar con un chatbot. El absurdo infinito. El eterno loop. La frustración.
Llegados a este punto, un chatbot necesita dotarse de ciertos mecanismos por los que es capaz de detectar que la experiencia del usuario ha llegado a un punto en la que no puede avanzar según lo previsto. En el ejemplo anterior, no se ha contemplado la posibilidad de que un usuario quiere asegurarse de que el producto que está dispuesto a pedir dispone de unas condiciones específicas, en este caso, que la pizza sea especial para personas no tolerantes al gluten. Alguien podría pensar que quizás, más adelante, durante los detalles del pedido, el usuario tendrá una oportunidad para indicar al chatbot que la masa de la pizza sea sin gluten, pero, ¿Y si no es el caso? ¿Cómo puede saber el cliente esto con antelación? Seguramente el usuario quiera ahorrarse todo el proceso y por eso su principal inquietud deba ser resuelta al inicio de la conversación antes de invertir más tiempo en el proceso.
Una vez más, nos encontramos ante la duda de si el planteamiento de la lógica de negocio del chatbot debe ser basada en flujos y opciones, o bien basada en diálogo abierto (NLP). Desde mi punto de vista, el diálogo abierto siempre será la mejor opción siempre que la plataforma de desarrollo de Chatbot lo permita. El diálogo abierto permite mejores experiencias y conversaciones parecidas a las que tendríamos con un humano, pero por contra, requieren de una dedicación substancial para prepararlas u configurarlas apropiadamente.
En ambos casos, el bloqueo puede suceder, y el chatbot debe detectar que las respuestas que está dando el usuario no son las esperadas. Por tanto, debemos disponer de un mecanismo de detección y acción que lleve a cabo los siguientes pasos:
- Pedir al usuario el dato esperado, de forma explícita y dando ejemplos de cómo esperamos la respuesta.
- Comprobar si el dato recibido coincide con la respuesta esperada y/o forma parte de las opciones disponibles.
- Si el dato recibido no es correcto, volver a reformular la pregunta del paso 1, y si es necesario, con aclaraciones adicionales. Repetir el paso 2 y 3. IMPORTANTE: repetir los pasos al menos en dos ocasiones adicionales.
- Si el Chatbot después de 3 intentos sigue sin disponer del dato, entonces se pone en marcha el sistema de desbloqueo.
- Desbloquear la situación. Es decir, informar al usuario de que por algún motivo no podemos avanzar en el diálogo y darle la opción de si quiere volver a intentarlo desde el principio, o bien, proponerle si quiere cambiar de tema y llevar a cabo otro proceso diferente. Este es sin duda un buen momento en el que el Chatbot debe de dejar de ser insistente, y pasar a mostrarse “humilde” explicando al usuario sus limitaciones y capacidad de compresión. Buen momento también para ser transparentes y compartir con el cliente que quizás hoy el Chatbot no ha sido capaz de estar a la altura, pero que un equipo de personas trabaja por detrás para revisar las conversaciones que han ido mal y que las mejorará de cara a situaciones en un futuro cercano.
En el paso 5 podemos poner en marcha mecanismos de escalado, esto es, transferir la conversación a un escenario diferente en el que habrá intervención humana. Los tres mecanismos de escalado por excelencia son:
- Mostrar un número de teléfono del Contact Center.
- Generar un ticket vía email para atención al cliente.
- Transferir la conversación a una sesión de chat con agente.
Mostrar el teléfono no es buena idea, principalmente porque el agente recibirá la llamada fuera de contexto y obligará al usuario a empezar desde el principio la narración de su caso. Además, los últimos estudios identifican este canal como uno de los más costosos.
La generación de un ticket vía email es un mecanismo bastante efectivo. Por un lado podemos incluir en el ticket un histórico previo de la conversación que mantuvo el usuario con el bot, y por otro lado, la respuesta podrá ser gestionada en diferido, esto es, en cuanto el agente de contact center tenga disponibilidad. Por contra, será necesario conocer el email del cliente o bien preguntárselo antes de crear el ticket, ya que de otra forma no será posible retomar el contacto con él para darle la respuesta y seguimiento al caso.
En relación al live chat, este canal se posiciona como el preferido en un método de escalado de un Chatbot. Las ventajas son varias respecto a los métodos anteriores. Por mencionar las más relevantes:
- El interfaz de usuario (UI) se mantiene, y lo único que cambia es el interlocutor. Si se puede mantener la misma ventana de interacción, mejor que mejor. Cerrar una ventana bruscamente para abrir otra puede llegar a provocar cierto rechazo en el usuario.
- Durante la transferencia es muy importante disponer de la capacidad de enviar al agente humano el histórico previo de interacciones con el Chatbot. Esto evitará tener que reformular las preguntas una y otra vez, situación que a todos nos es familiar y que tanto nos incomoda.
- Los agentes de live chat, a diferencia de las llamadas, pueden gestionar más de una conversación simultánea, siendo 4 el número máximo aconsejado.
Si bien el chat se posiciona como método recomendado de escalado de un chatbot, pasar de la idea al hecho podría convertirse en una pesadilla de integración.
Errar es de humanos (y de bots!). Es importante tener la mente abierta y aprender cada día de la experiencia. Pero hay un momento en que tanto las personas como las IA’s tenemos la obligación (moral) de reconocer nuestras limitaciones, mostrarnos humildes, y pedir ayuda. Tal y como dijo una vez un famoso presentador de TV: “Uno hace lo que puede. El resto lo hacen los amigos”.
