⛑️Boas práticas para desenvolvimento de bots na Hyperflow

Neste guia, vamos te mostrar algumas boas práticas para desenvolver bem seus bots na Hyperflow. Consulte-as sempre que precisar e aproveite o material!

💡Iniciar protocolo

Use sempre o módulo Iniciar protocolo no início de cada fluxo que leva a interações com o cliente.

Sem ele o protocolo não será iniciado! Quando isso acontece, uma série de informações são perdidas nos atendimentos, como classificação, rótulos, entre outros. Além disso, ele não será exibido no Histórico de Chats, o que prejudica drasticamente as métricas das empresas.

💡Iniciar inatividade

É importante usar o módulo Iniciar inatividade no início de cada fluxo que leva a interações com o cliente.

Sem um tempo máximo de inatividade, o atendimento ficará aberto indefinidamente, o que pode prejudicar as métricas de atendimento da empresa. Para evitar este tipo de situação, devemos sempre inserir uma medida que trate os atendimentos abandonados, encerrando-os ou transferindo-os para o atendimento humano após um certo tempo de inatividade do cliente.

💡Finalizar inatividade

Use o módulo Finalizar inatividade nos trechos de fluxo que levam ao final do atendimento sem passar por um humano.

Caso um atendimento tenha a inatividade iniciada e chegue ao fim sem passar por um humano, é importante inserir o módulo Finalização de inatividade. Desta forma, a contagem de inatividade é encerrada e o fluxo de inatividade não será executado ao final do atendimento.

Exemplo: o cliente entrou em contato para comprar um produto. Todo o atendimento até a finalização da compra foi feito de forma automatizada. Após comprar o produto, o cliente recebeu uma mensagem informando que está tudo certo e não respondeu mais. Nesse ponto, é importante colocar um módulo de encerramento. Pode ser uma pergunta como "Compra finalizada com sucesso! Deseja encerrar o atendimento?" e duas opções usando o componente botão, por exemplo, "Sim, está tudo certo!" e outra "Não, desejo prosseguir!".

💡Nomear os componentes do fluxo

Dar nomes a cada componente do fluxo facilita o processo de debug e acompanhamento do caminho percorrido pelos atendimentos na tela “Tempo real”. A própria plataforma já tem um padrão estabelecido, que é: “tipo componente – número” (ex: Chat - 2).

O ideal é nomearmos de forma que fique clara a identificação, como nos exemplos a seguir:

  • Chat - Mensagem de Saudação

  • Request – Salva contato

Veja nas imagens abaixo:

Para alterar o nome de um componente, basta abrir o card e, no canto superior esquerdo, editar o nome, como mostrado no gif abaixo:

💡Usar um botão ou comando para que o cliente sinalize que não deseja mais receber mensagens promocionais

Manter a saúde da conta de WhatsApp é crucial para as empresas,

Dar ao cliente a possibilidade de não receber mensagens promocionais pode ajudar a minimizar as denúncias e bloqueios. Muitas vezes o cliente final não deseja receber as mensagens ativas e vê como solução o ato de denunciar ou bloquear o destinatário.

Podemos minimizar estes casos inserindo um botão ou comando na mensagem, de forma que fique claro para o cliente final que ele pode escolher não receber estes contatos.

Quando o cliente fizer esta sinalização, é importante guardar esta informação para que não haja risco de novas mensagens ativas de campanhas serem enviadas para aquele determinado número, ocasionando uma possível denúncia.

Uma forma eficaz é criar uma variável de usuário que marca que aquele cliente não quer receber as mensagens ativas. Feito isso, é importante incluir uma condição nos fluxos de transmissões para que os envios de mensagem só ocorram para aqueles contatos que não tenham a variável de marcação.

💡Nos fluxos de encerramento, inserir uma tratativa para caso o cliente responda a mensagem de finalização

É comum haver uma mensagem de finalização nos fluxos de atendimento, como por exemplo: “Este atendimento foi finalizado. Fique à vontade para nos chamar novamente, sempre que precisar! Até logo!”

Porém, muitos clientes acabam respondendo a estas mensagens de finalização dos bots com uma mensagem de agradecimento (ex: “Tchau”, “Obrigado” e etc).

Se não tratarmos este tipo de situação, quando o cliente enviar a mensagem de agradecimento ele acabará acionando o bot novamente, iniciando um novo atendimento por engano.

Para solucionarmos este problema, podemos inserir nos fluxos de finalização uma tratativa com inatividade sugerida de 60 minutos, e, dessa forma, caso o cliente envie uma nova mensagem dentro do tempo estipulado, ele é questionado se deseja iniciar um novo atendimento. Se ultrapassar o tempo de inatividade, prosseguimos com o encerramento do atendimento normalmente.

💡 Tratar mensagens fora de contexto

Muitas vezes o cliente nos responde com algo diferente do esperado ou envia uma mensagem quando deveriam clicar em um botão. Por isso é indispensável sempre tratar as mensagens fora de contexto, ou seja, quando se espera que o cliente escolha alguma opção em um menu, mas ele envia uma outra mensagem de texto ou áudio.

Para esses casos, indicamos uma mensagem informativa, pedindo ao cliente que tente novamente. Se após algumas tentativas o cliente não clicar nas opções do menu mesmo com as mensagens informativas, a melhor estratégia é direcionar o cliente para o atendimento humano.

💡Usar respostas rápidas para habilitar sinônimos das opções de resposta em menus

No menu da imagem acima, o cliente pode acabar respondendo com uma mensagem digitada em vez de clicar em algum botão. Desta forma, poderíamos criar 2 opções de respostas rápidas além dos botões, para tratarmos as possíveis respostas do cliente:

  • Já sou beneficiário (sinônimos: já, sim, sou, sou beneficiário, ss, s);

  • Ainda não (sinônimos: não, ainda não, nn, n, não sou).

Dessa forma, caso o cliente responda com algum destes termos, o nosso bot estaria preparado para compreender.

Muito obrigado por chegar até aqui! Esperamos que esse guia te ajude no seus desenvolvimento e, claro, se tiver alguma dúvida, é só acionar nosso suporte! 🤖💜

Last updated