Nossa equipe atua na automação de atendimento ao cliente há mais de dois anos. Recentemente, percebemos que conectar chatbots e assistentes virtuais nem sempre beneficia as empresas.
Para ver isso, imagine esta situação: você é um gerente de um grande banco, onde é difícil para os clientes fazer login em um aplicativo móvel - cada segundo é interrompido no estágio de login, porque fazer login é tão difícil quanto dominar o grande teorema de Fermat.
Você tem duas opções:- Corrija o processo de autorização - normalmente projete telas e ponha fim ao tormento dos usuários. Vai custar a partir de rublos NNN.
- Automatizar suporte - conecte um assistente virtual que ensinará aos clientes como usar o aplicativo. Vai custar a partir de rublos NN.
Automatizar o suporte e contratar um robô geralmente é mais barato do que trazer processos à mente em um aplicativo. Portanto, agora os gerentes míopes escolhem a segunda opção - eles contam com a primeira linha de suporte para fechar os buracos nos produtos.
Isso é especialmente verdade para os inovadores de negócios (fintech, viagens, telecomunicações, comércio eletrônico) - eles já implementaram com sucesso assistentes virtuais e foram capazes de lançar a maioria dos problemas neles. Como resultado, o suporte às vezes funciona como um plugue para fechar buracos em um barco.
Case. O banco queria que nosso assistente virtual coordenasse a entrega de cartões com os clientes. Durante a automação do script, verificou-se que o próprio processo foi construído incorretamente: o usuário primeiro seleciona a região, depois o mapa é levado para a cidade desejada e somente então o endereço de entrega é acordado.
Essa abordagem leva a um monte de problemas com aqueles que não prestaram atenção ao item sobre a cidade - ele é pré-preenchido como "Moscou" e muitos simplesmente não percebem. Como resultado, o robô liga para o cliente e diz: “Olá, seu cartão em Moscou, quando é conveniente entregar?”, E o cliente responde: “Bl **, estou em Novosibirsk, como está?”
Não é difícil corrigir esse processo: você só precisa perguntar claramente no aplicativo para onde levar o cartão. Mas tivemos que ensinar o robô a responder corretamente à articulação e enviar cartões para outras regiões.
Como resultado, o banco perdeu dinheiro na entrega e fechou o bug com a ajuda do suporte, embora valesse a pena concluir o processo de inscrição - não haveria problemas.
Este não é um caso isolado. Analisamos as solicitações de 6 milhões de usuários e vimos que a dor mais comum são os batentes banais do produto.
Cinco dos dez cenários de alta frequência (em fintech, varejo, telecomunicações) podem ser fechados se você modificar processos de negócios ou alterar o design do UX.
Mas a questão é: como a equipe do produto sabe o
que precisa ser aprimorado?
Bots podem dar uma resposta. Nossas redes neurais agrupam solicitações de usuários e agrupam mensagens do mesmo tipo em grupos (clusters): quanto maior o grupo, mais agudo e popular o problema. Se você observar o cluster, poderá entender o que vale a pena consertar para facilitar a vida dos usuários.
No último ano de trabalho com esses casos, concluímos que a automação de suporte nem sempre é boa se esquecermos de resolver problemas do produto: alterar processos e design, criar a comunicação certa. Mas, embora o suporte esteja lidando e ensinando aos clientes como usar o que eles têm, poucas pessoas levam isso a sério.
E os assistentes são parcialmente culpados.Função esquecida: Comunicação
Tentar fechar todos os buracos em um produto com um robô não é o único problema que os assistentes virtuais criam para uma empresa.
Com o advento da automação nas primeiras linhas de suporte, todos esqueceram de trazer informações sobre falhas do sistema e problemas do usuário para a empresa. Focamos no maior suporte de serviço, mas não pensamos em como estabelecer comunicação com os gerentes de produto.
Portanto, uma vez que nossos colegas da Ucrânia entraram nessa situação: lançaram um assistente em um grande banco e não configuraram o algoritmo de comutação para o operador corretamente. Quando a funcionalidade básica de pagamento falhou, e as solicitações dos clientes caíram, o robô foi burro, solicitado a reformular a pergunta, ou otmazyvatsya: "Sim, sim, resolveremos isso em breve".
Era o segundo dia, o assistente continuava consolando os usuários e ninguém dentro do banco sabia do incidente. Foi difícil perceber nas análises - a funcionalidade não caiu em todos os lugares, mas apenas em um pequeno segmento.
Bem, houve clientes irritados que contornaram o robô: alguém quebrou o palavrão que os forçou a mudar para o operador, alguém ligou para os gerentes e relatou um colapso. O banco finalmente percebeu o que deu errado e resolveu o problema apenas no segundo dia.
Foi um caso legal que mostrou um bug no robô de comunicação → gerenciador. Percebemos que precisávamos criar um modelo e estabelecer uma conexão de emergência entre assistentes e produtos.
Como ensinamos os assistentes a falar sobre problemas
Antes de tudo, precisávamos entender sobre o que informar os produtos - em outras palavras, o que é considerado incidente e o que não é.
Para que o robô aprenda a entender os parâmetros do volume de solicitações e a distinguir erros de massa dos pequenos, treinamos para determinar o incidente por vários critérios:
- Número de usuários - de acordo com o histórico de mensagens do cliente, o robô reconhece o número aproximado de usuários ativos e determina qual porcentagem de chamadas pode ser considerada crítica.
- O período de tempo em que as mensagens sobre o problema chegam - quando o robô vê um aumento acentuado em chamadas idênticas, o correlaciona com o número de clientes: se o erro for grande, ele inicia um incidente (a uniformidade é determinada pela nossa rede neural básica, que reconhece o significado das chamadas no texto).
O algoritmo de clustering identifica grupos de chamadas semelhantes, independentemente de estarem ou não na marcação. Se os usuários entrarem em contato com o suporte em massa e a dinâmica das mensagens estiver aumentando nos últimos minutos / horas / dias - isso é um incidente.
Ainda não é perfeito, mas aprendemos como resolver o problema de comunicação com os funcionários da empresa. Se o assistente entender que ocorreu um problema, ele age de acordo com este algoritmo:
- Inicia um incidente e envia notificações aos funcionários responsáveis por números de telefone / email pré-especificados.
- Ele pede para escrever uma mensagem que será enviada aos usuários em resposta: por exemplo, "o reparo levará duas horas, pedimos desculpas" .
- Depois de consertar o bug, o assistente fecha o ticket e pode escrever para todas as vítimas: "Hooray, consertamos tudo" . Isso é conveniente, já que você não precisa enviar uma resposta por todo o banco de dados - o robô lembra apenas os afetados pelo problema.
Quando o assistente começou a relatar falhas em massa, vimos que muitos erros estavam relacionados a problemas técnicos. E aprendemos a responder rapidamente a eles.
Por exemplo, quando a lógica dos pagamentos de orçamento voou para nós e os usuários não puderam pagar impostos, o robô enviou um relatório de erro em uma hora. A equipe rapidamente reverteu a versão e resolveu rapidamente o problema.
Isso é muito melhor do que escrever:
"Sim, sim, em breve tudo ficará bem" . E mais honesto com relação aos usuários.
Geralmente, todos os envolvidos no suporte à automação de suporte se concentram em ensinar aos robôs como responder com rapidez, eficiência e baixo custo. Mas eles perdem um ponto importante: as tarefas de um gerente de suporte são mais amplas do que apenas escrever uma resposta.
Quando começamos a estudar profundamente todas as funções do papel que estamos tentando automatizar, vimos que um bom atendimento ao cliente é quando o suporte entra em contato com a equipe e conta sobre as dores dos usuários, e a empresa conclui seu produto.
Caso contrário, o suporte se torna uma muleta permanente para o negócio: fecha buracos e otmazyvatsya até o fim, em vez de resolver problemas.