Nuestro equipo se ha dedicado a la automatización del servicio al cliente durante más de dos años. Recientemente, nos dimos cuenta de que conectar chatbots y asistentes virtuales no siempre beneficia a las empresas.
Para ver esto, imagine esta situación: usted es un gerente en un banco grande, donde es difícil para los clientes iniciar sesión en una aplicación móvil; cada segundo se rompe en la etapa de inicio de sesión, porque iniciar sesión es tan difícil como dominar el gran teorema de Fermat.
Tienes dos opciones:- Corrija el proceso de autorización: normalmente diseñe pantallas y ponga fin al tormento de los usuarios. Costará desde NNN rublos.
- Automatice el soporte: conecte un asistente virtual que enseñará a los clientes cómo usar la aplicación. Costará desde NN rublos.
Automatizar el soporte y contratar un robot suele ser más barato que recordar procesos en una aplicación. Por lo tanto, ahora los gerentes miopes eligen la segunda opción: confían en la primera línea de soporte para cerrar los agujeros en los productos con ella.
Esto es especialmente cierto para los innovadores de negocios (fintech, viajes, telecomunicaciones, comercio electrónico): ya han implementado con éxito asistentes virtuales y pudieron resolver la mayoría de los problemas. Como resultado, el soporte a veces funciona como un tapón para cerrar agujeros en un bote.
Caso. El banco quería que nuestro asistente virtual coordinara la entrega de tarjetas con los clientes. Durante la automatización del script, resultó que el proceso en sí mismo se construyó incorrectamente: el usuario primero selecciona la región, luego el mapa se lleva a la ciudad deseada y solo entonces se acuerda la dirección de entrega.
Este enfoque lleva a un montón de problemas con aquellos que no prestaron atención al artículo sobre la ciudad: está precargado como "Moscú" y muchos simplemente no lo notan. Como resultado, el robot llama al cliente y le dice: "Hola, su tarjeta en Moscú, ¿cuándo es conveniente entregarla?", Y el cliente responde: "Bl **, estoy en Novosibirsk, ¿cómo estás?"
No es difícil arreglar ese proceso: solo necesita preguntar claramente en la aplicación dónde llevar la tarjeta. Pero tuvimos que enseñarle al robot a responder correctamente a la articulación y enviar tarjetas a otras regiones.
Como resultado, el banco perdió dinero en el momento de la entrega y cerró el error con la ayuda del soporte, aunque valió la pena completar el proceso de solicitud; no habría problemas.
Este no es un caso aislado. Analizamos las solicitudes de 6 millones de usuarios y vimos que el dolor más común son las jambas banales en el producto.
5 de los 10 escenarios de mayor frecuencia (en fintech, retail, telecomunicaciones) se pueden cerrar si modifica los procesos comerciales o cambia el diseño de UX.
Pero la pregunta es, ¿cómo sabe el equipo del producto
lo que debe mejorarse?
Los bots pueden dar una respuesta. Nuestras redes neuronales agrupan las solicitudes de los usuarios y agrupan los mensajes del mismo tipo en grupos (grupos): cuanto más grande es el grupo, más agudo y popular es el problema. Si observa el clúster, puede comprender qué vale la pena arreglar para facilitar la vida de los usuarios.
Durante el último año de trabajar con estos casos, hemos concluido que la automatización del soporte no siempre es buena si nos olvidamos de resolver problemas del producto: cambiar procesos y diseño, construir la comunicación correcta. Pero si bien el soporte es hacer frente y enseñar a los clientes cómo usar lo que tienen, pocas personas lo toman en serio.
Y los asistentes son en parte culpables.Función olvidada: comunicación
Intentar cerrar todos los agujeros en un producto con un robot no es el único problema que los asistentes virtuales crean para un negocio.
Con el advenimiento de la automatización en las primeras líneas de soporte, todos olvidaron traer información sobre fallas del sistema y problemas del usuario a la empresa. Nos centramos en la mayoría del soporte de servicio, pero no pensamos en cómo establecer comunicación con los gerentes de producto.
Por lo tanto, una vez que nuestros colegas de Ucrania se encontraron con esta situación: lanzaron un asistente en un gran banco y no configuraron el algoritmo de cambio para el operador de manera bastante correcta. Cuando la funcionalidad de pago básica fallaba, y las solicitudes de los clientes caían, el robot estaba tonto, se le pedía que reformulara la pregunta u otmazyvatsya: "Sí, sí, lo solucionaremos pronto".
Era el segundo día, el asistente continuó consolando a los usuarios, y nadie dentro del banco sabía sobre el incidente. Fue difícil notarlo en el análisis: la funcionalidad no estaba en todas partes, sino solo en un segmento pequeño.
Bueno, hubo clientes enojados que eludieron el robot: alguien lo rompió con malas palabras que los obligaron a cambiar al operador, alguien llamó a los gerentes e informó un colapso. El banco finalmente se dio cuenta de lo que salió mal y solucionó el problema solo el segundo día.
Fue un caso genial que mostró un error en el robot de comunicación → administrador. Nos dimos cuenta de que necesitábamos crear un modelo y establecer una conexión de emergencia entre asistentes y productos.
Cómo enseñamos a los asistentes a hablar sobre problemas
En primer lugar, necesitábamos comprender sobre qué informar a los productos; en otras palabras, qué se considera un incidente y qué no.
Para que el robot aprenda a comprender los parámetros del volumen de solicitudes y distinguir los errores masivos de los pequeños, lo capacitamos para determinar el incidente mediante varios criterios:
- Número de usuarios : de acuerdo con el historial de mensajes del cliente, el robot reconoce el número aproximado de usuarios activos y determina qué porcentaje de llamadas puede considerarse crítico.
- El período de tiempo durante el cual llegan los mensajes sobre el problema : cuando el robot ve un aumento brusco en llamadas idénticas, lo correlaciona con el número de clientes: si el error es masivo, comienza un incidente (nuestra red neuronal básica determina el significado de las llamadas en el texto).
El algoritmo de agrupamiento identifica grupos de llamadas similares, independientemente de si están en el marcado o no. Si los usuarios contactan con el soporte masivo y la dinámica de los mensajes está creciendo en los últimos minutos / horas / días, esto es un incidente.
Todavía no es perfecto, pero hemos aprendido cómo resolver el problema de la comunicación con los empleados de la empresa. Si el asistente comprende que se ha producido un problema, actúa de acuerdo con este algoritmo:
- Inicia un incidente y envía notificaciones a los empleados responsables por números de teléfono / correo electrónico previamente especificados.
- Pide escribir un mensaje que se enviará a los usuarios en respuesta: por ejemplo, "la reparación tomará dos horas, nos disculpamos" .
- Después de corregir el error, el asistente cierra el ticket y puede escribir a todas las víctimas: "¡Hurra, lo arreglamos todo ! " Esto es conveniente, ya que no tiene que enviar una respuesta a través de la base de datos: el robot solo recuerda a los afectados por el problema.
Cuando el asistente comenzó a informar fallas masivas, vimos que muchos errores estaban relacionados con problemas técnicos. Y aprendimos cómo responder rápidamente a ellos.
Por ejemplo, cuando la lógica de los pagos del presupuesto se voló hacia nosotros y los usuarios no podían pagar impuestos, el robot envió un informe de error en una hora. El equipo retiró rápidamente la versión y resolvió el problema rápidamente.
Esto es mucho mejor que escribir:
"Sí, sí, pronto todo estará bien" . Y más honesto con respecto a los usuarios.
Por lo general, todos los involucrados en el soporte de la automatización del soporte se enfocan en enseñar a los robots cómo responder de manera rápida, eficiente y económica. Pero pierden un punto importante: las tareas de un gerente de soporte son más amplias que solo escribir una respuesta.
Cuando comenzamos a estudiar a fondo todas las funciones del rol que estamos tratando de automatizar, vimos que un buen servicio al cliente es cuando el soporte contacta al equipo y les informa sobre los dolores de los usuarios, y la compañía completa su producto.
De lo contrario, el soporte se convierte en una muleta permanente para el negocio: cierra los agujeros y otmazyvatsya hasta el final, en lugar de resolver problemas.