Omnicanal
Chatbots com IA: o que fazem bem e onde devem parar
Um bot avalia-se pelo que faz quando não sabe responder, não pelo que consegue responder. Onde um atendimento automático ajuda, onde tem de parar, e como se mede se está a ajudar.
5 min de leitura
Um chatbot que não sabe dizer «não sei» custa mais do que aquilo que poupa. Poupa o tempo de dez respostas simples e perde um negócio, porque insistiu três vezes com uma pessoa que já tinha percebido que estava a falar com uma máquina incapaz de a ajudar.
É esta a forma honesta de pensar um atendimento automático: não pelo que ele consegue responder, mas pelo que acontece quando não consegue. Tudo o resto é demonstração.
O que um bot faz bem, e é mais do que parece
Há tarefas em que um atendimento automático é claramente melhor do que uma pessoa, por uma razão que nada tem a ver com inteligência: está disponível.
- Perguntas com uma resposta única e verificável. Horário, morada, o que é preciso trazer, se aquele serviço existe, o que está incluído.
- Dizer em que estado está um pedido, quando essa informação existe num sistema e pode ser consultada com segurança.
- Recolher o que quem vai atender precisa de saber — o que a pessoa quer, para quando, como se chama, como se fala com ela. É o que evita ser a quinta pessoa a fazer as mesmas quatro perguntas.
- Dar sinal de vida às três da manhã. Não a resposta final: a confirmação de que a mensagem chegou e a hora a que alguém responde.
Note-se o que estas quatro têm em comum: a resposta certa existe e é verificável antes de a conversa começar. Não é o bot que a inventa. Onde isso deixa de ser verdade, o valor do automático cai a pique, e a mesma ferramenta que resolvia bem passa a produzir problemas com aparência de respostas.
Onde um bot deve parar
O limite não se define pela dificuldade da pergunta. Define-se pela consequência de uma resposta errada. Cinco linhas que não se atravessam:
- Preço negociado, condição especial, exceção. Tudo o que dependa de alguém decidir.
- Qualquer coisa com consequência legal ou contratual — garantias, responsabilidade, cancelamentos, dados pessoais.
- Reclamações. Quem está a reclamar quer, antes de tudo, ser ouvido por alguém. Um bot no meio agrava o que já estava mal.
- Assuntos cuja informação não existe escrita em lado nenhum. É aqui que um modelo de linguagem é mais perigoso: em vez de falhar de forma visível, responde bem — e errado.
- Conversas em que a pessoa já pediu para falar com alguém. Isto não se discute nem se tenta uma última vez.
Um bot que atravessa qualquer uma destas cinco linhas não está a poupar trabalho: está a adiá-lo com juros, porque alguém vai ter de refazer a conversa e ainda desfazer o que ficou dito. E há uma assimetria a ter em conta: uma resposta automática acertada passa despercebida, uma errada fica escrita e pode ser mostrada a terceiros.
«Não sei» é a resposta mais difícil de desenhar
É difícil por uma razão técnica incómoda: o sistema não sabe que não sabe. Um modelo de linguagem produz sempre uma resposta plausível, e a plausibilidade não distingue o que é verdade do que soa a verdade. Por isso o desenho não pode depender da confiança do próprio modelo. Tem de depender de regras exteriores a ele: assuntos que nunca responde, um número máximo de tentativas, palavras que passam a conversa imediatamente, e uma resposta de recurso quando nada encaixa.
Depois há a forma, que também conta. «Não tenho essa informação, vou passar a alguém da equipa que a tem» é uma boa resposta e mantém a relação inteira. Repetir a pergunta por outras palavras, ou responder ao lado com confiança, transforma um contacto interessado em alguém que vai procurar noutro sítio — e que não volta a escrever para dizer porquê.
Como se mede se está a ajudar
A medida que se usa por defeito — quantas conversas o bot fechou sozinho — é a pior de todas, porque premeia exatamente o comportamento errado: um bot que se recusa a passar tem números excelentes. Três medidas melhores:
- Conversas que precisaram de pessoa depois de o bot tentar, e quanto tempo se perdeu na tentativa. É o custo real do automático.
- Conversas que voltaram. A mesma pessoa, o mesmo assunto, dias depois. Uma conversa fechada que volta não foi resolvida, foi despachada.
- Quando passou, passou com contexto? Quem recebeu teve de perguntar de novo o que já tinha sido dito? Se teve, o bot não poupou nada.
Nenhuma destas se lê num painel bonito, e todas se leem numa amostra de conversas lidas à mão uma vez por semana. É trabalho chato e é o único que diz a verdade sobre o que os clientes viveram.
Antes de escrever o guião, escreva a lista do que ele não responde
É a inversão que muda o resultado. A lista das perguntas que o bot responde cresce sozinha com o uso, e cresce bem. A lista do que ele não responde tem de ser decidida por pessoas — de preferência pelas que atendem hoje, porque são elas que sabem em que conversas é que um erro custa um cliente.
Com essa lista na mão, o resto é desenho: que perguntas faz, que informação recolhe, e para quem passa quando para. Essa última parte tem artigo próprio, passar do bot para a pessoa certa, porque é a que mais vezes fica sem desenho nenhum. E se o objetivo é que o bot recolha informação útil, convém decidir antes o que é mesmo preciso para qualificar um contacto: um bot que faz as perguntas erradas depressa não ajuda ninguém.
O âmbito de atendimento automático que discutimos com quem nos procura está em omnicanal e IA, e a ordem por que o fazemos — primeiro a operação, depois o ecrã — em o nosso modelo.