Começando/melhorando um chatbot com o pé direito

Dicas de como alinhar as equipes na criação de fluxos de conversas

Toda boa criação de chatbot envolve equipes multidisciplinares, ponto. Tendo tanto a visão de negócio, técnica e alguém que entenda do usuário, há o mínimo necessário para um bot.

Imagine uma empresa de e-commerce que vende violão e tem um projeto de criar um assistente conversacional novo. A gerente da área de atendimento, a Jeniffer, trouxe uma de suas atendentes, a Paula, junto com o Juan para fazer a parte técnica.

Juntando todo mundo na mesma sala para definir os fluxos, a gerente comenta que precisam ver o status da encomenda, a Paula define os exemplos de frases, e no final a parte técnica define qual a rota da API que precisa ser usada. Todos ficam satisfeitos escrevem a historia do usuário e vão para a próxima.

Agora quem já é velho de guerra sabe que muito provavelmente isso vai gerar problemas no futuro, e vamos descrever o porquê.

O problema de fluxos resumidos em cartões

O grande poder do cartão é lembrar uma conversa que houve, no nosso caso a reunião de definição dos fluxos. Agora nós entramos em alguns problemas se apenas o cartão servir para lembrar o que foi discutido pelas seguintes razões:

Primeiramente, é muito fácil de um detalhe ser esquecido se apenas se basear na memória. Por exemplo: a gerente pode ter pedido para que, em caso de pedido entregue, exista uma chance da pessoa receber um conjunto de cordas de nylon ou aço dependendo do violão, motivado por uma companha de fidelização.

Segundo, se uma outra pessoa for desenvolver o fluxo, como o Zezé, que não participou da reunião, e ele se basear no cartão, ele não vai saber o que está acontecendo, qual o endpoint da API, quais os parâmetros de chamada, como tratar o retorno, a campanha, a persona… E se ele for conversar com o Juan que estava na reunião, o Juan pode esquecer algo importante, vide o jogo telefone sem fio.

Algo que parecia simples, quando esmiuçado, acaba virando algo bem maior. Mas a definição já foi feita e a estimativa foi totalmente subestimada, depois quando o desenvolvimento começa percebemos que a chamada da API ainda não foi concluída, o pessoal de cima pressiona para o projeto ficar pronto, gerando todo um estresse e o sentimento que projetos envolvendo bots é um bicho que só dá dor de cabeça.

A dica para não ter problema de escopo

Essa dica não é nenhum segredo, nem uma técnica milenar ou algo visto em um livro entitulado “7 passos para um chatbot eficiente”. É algo simples, mas que na correria do dia-a-dia é facilmente esquecido.

A dica é fazer conversas bem estruturadas.

Antes de fechar esse artigo dizendo que foi perda de tempo, vamos dar uma validada com o que queremos dizer com isso.

Para tanto, vamos usar uma ferramenta grátis (lembrando que ele não é obrigação nem nada, uma folha de papel ou um quadro branco serviria da mesma maneira) que é o Whimsical.

O primeiro desenho que temos pela demanda seria:

Agora, esse caso é lindo e maravilhoso, mas no meio da reunião o técnico responsável pergunta: “e se der erro na chamada? O que acontece?”, pois como sabemos, nem sempre tudo funciona perfeitamente. Além disso a consulta de status ainda não está preparada como uma API, foi despriorizada pela equipe de desenvolvimento… melhor deixar essa observação disponível.

Vamos adicionar esses casos dentro do fluxo:

Separando em cores, azul para chamadas de serviço, amarelo para resposta do bot e detalhes importantes em vermelho para prestar atenção. As cores não são fundamentais, mas ajudam para quando bater o olho saber exatamente o que acontece em cada bloco, ao invés de ter que entender todo o fluxo para deduzir o que acontece.

Para fazer a chamada da API vamos precisar de alguns dados, obviamente o número do pedido é um deles, mas a política da empresa pede que a pessoa tenha uma identificação mínima com o CPF. Aí, alguém que entende do usuário comenta que o CPF já pode ter sido preenchido em um outro fluxo, e pedir novamente diminui a boa experiência de um chatbot, então o fluxo atualizado fica:

Vemos que começa a ficar um pouco mais complexo… Mas ainda não acabou, sabemos que a chamada da API pode retornar os seguintes status:

• aguardando pagamento
• dentro do armazém
• saiu para entrega
• entregue
• pedido cancelado
• pendente ação

Nesse ponto a pessoa técnica só sabe que tem estes status, mas o “pendente ação” não faz muito sentido para ele. A gerente explica que como os clientes gostam de customizar o violão deles, as vezes é necessário confirmar algum detalhe antes da produção. Vamos adicionar isso no fluxo em forma de botões para guiar os usuários, já que é algo que pode ser complexo e confundi-los.

Ok, mas ainda não acabamos — lembra da companha de fidelização? Pois é, ainda temos que adicionar este caso (se você já tinha esquecido, ta aí um bom motivo para usar estes tipos de mapeamento).

Podemos expandir o exemplo para bem mais casos, mas vamos manter a sanidade.

Vemos que algo simples quando conversado pode se expandir em muitos outros pontos que precisam ser estruturados. Algo que aparentava ser 3 blocos com uma estimativa de 4 dias pode facilmente acabar virando algo maior depois de feita as devidas perguntas.

“A segunda vantagem é o shared understanding, uma pessoa que não tenha participado da reunião inicial pode pegar o mapa de fluxo e implementar seguindo um diagrama”

Essa é a primeira vantagem, enxergar o escopo real da demanda, mas a segunda vantagem é o shared understanding, uma pessoa que não tenha participado da reunião inicial pode pegar o mapa de fluxo e implementar seguindo um diagrama. Além disso, enquanto ele está sendo construído, temos o entendimento geral de todas as partes, o porquê dele ter sido desenhado, e não uma suposição que todos tenham tido um mesmo entendimento — afinal, isso raramente é verdade.