Bem na demo, mal nas chamadas reais: que camada falhou?

Em resumo

Um agente de voz que passa na demonstração e falha nas chamadas reais não piorou de repente. As chamadas reais atravessam as mesmas sete camadas que a demonstração, do áudio da linha e do reconhecimento de fala às ferramentas, à passagem para pessoas e à medição. A demonstração nunca pôs à prova a camada que agora falha em condições reais.

Por isso, não comece por reescrever o prompt. Pegue nas chamadas reais que falharam, faça cada uma percorrer as camadas pela ordem e atribua-a à primeira camada que falhou. A camada com mais chamadas é a que está a falhar, e é a primeira a corrigir. Faça essa única correção, volte a testar as mesmas chamadas e compare.

Este artigo é para uma linha que já está em produção. Se a linha ainda não arrancou, comece pelo nosso guia sobre como testar um agente de IA de voz antes de entrar em produção.

Porque é que a demonstração correu bem

Uma demonstração é um teste amigável. Quem liga conhece o guião, fala com clareza numa sala silenciosa e espera que o agente acabe de falar. O registo de teste está limpo: a encomenda existe e o horário está livre.

Os clientes reais interrompem. Ligam do carro ou de um armazém, usam palavras e abreviaturas da sua região e fazem perguntas sobre assuntos relacionados para os quais o fluxo não foi pensado. Às vezes, nem são a pessoa que o fluxo esperava: atende o contabilista em vez do dono, atende um familiar, ou a chamada vai parar a outro departamento.

Cada uma destas condições põe à prova uma camada diferente. Uma boa demonstração mostra que as camadas aguentam quando tudo chega limpo, não qual delas falha primeiro com tráfego real.

As sete camadas por onde passa uma chamada

Todas as chamadas atravessam as mesmas camadas, pela mesma ordem. Uma falha numa das primeiras camadas produz sintomas nas seguintes, por isso os sintomas, sozinhos, apontam muitas vezes para o sítio errado.

• Áudio da linha e telefonia: a chamada é estabelecida, o áudio passa nos dois sentidos sem atraso nem eco e a chamada termina como deve ser.
• Reconhecimento de fala: o que o cliente disse passa a texto.
• Conhecimento: os factos que o agente pode usar, como políticas, detalhes de produto e respostas às perguntas mais comuns.
• Decisão: a lógica da conversa, ou seja, o que dizer ou perguntar a seguir, quando confirmar, quando passar a chamada e como terminar.
• Ferramentas e ações no sistema: as consultas e os registos que o agente faz no CRM, no sistema de marcações ou no de tickets.
• Passagem para pessoas: a transferência ou a chamada de retorno, e o contexto que o seu colega recebe.
• Medição: o resultado registado corresponde ao que aconteceu de facto.

Há ainda um ponto onde a chamada pode falhar, e não é uma camada da IA: o lado do negócio. Algumas chamadas falham porque não há stock nem horário livre, ou porque os dados do seu próprio sistema estão desatualizados. O agente fez o seu trabalho e a empresa não conseguiu dar resposta. Conte estas chamadas à parte e encaminhe-as para o responsável por esse processo.

Comece pelos clientes reais, não pela folha de testes

Reúna todas as chamadas reais de um período recente, e não os cenários da sua folha de testes. Depois, retire as chamadas de teste internas: o mesmo número e as mesmas falas de guião, repetidos com poucos minutos de intervalo. Quem testa não fala como um cliente real.

A seguir, verifique numa amostra as etiquetas de resultado. Se as chamadas que foram parar ao correio de voz contam como conversas, ou as marcações concluídas contam como falhas, o próprio conjunto de chamadas falhadas está errado. A medição é a última camada, mas é a primeira a verificar.

Por fim, ouça o áudio. A transcrição mostra o que o reconhecimento ouviu, e só a gravação mostra o que o cliente disse.

Tabela de diagnóstico: do sintoma à camada

Use a tabela com uma chamada falhada de cada vez e encontre a prova antes de atribuir a camada.

Conte cada chamada falhada uma vez, na primeira falha

É assim que lemos as chamadas falhadas na DRING. Cada chamada falhada percorre as camadas pela ordem e recebe uma única etiqueta: a primeira camada que falhou. Uma frase mal ouvida que leva a uma resposta errada e depois a uma marcação falhada é uma falha de reconhecimento, não três problemas.

Com um único valor por chamada, as contagens somam o total de chamadas falhadas, e a maior contagem mostra onde uma correção pode recuperar mais chamadas.

A alternativa habitual é etiquetar cada sintoma onde quer que apareça. Contadas desta forma, as 200 chamadas falhadas do exemplo abaixo receberam 355 etiquetas. A decisão foi a camada com mais etiquetas, 104, porque uma frase mal ouvida costuma tornar errada também a resposta seguinte. No entanto, a decisão foi a primeira falha em apenas 40 chamadas. As etiquetas de sintoma sobrepõem-se, o seu total não corresponde ao número de chamadas falhadas e fazem todas as camadas parecer urgentes. Mostre-as à parte, se for útil, mas ordene as correções pelas primeiras falhas.

Os números desta secção são um exemplo criado para este artigo, e não dados de uma implementação real.

Neste exemplo, o reconhecimento de fala é a camada por onde começar: é a primeira falha em 62 de 200 chamadas. As 22 chamadas do lado do negócio não são um defeito da IA. Nenhuma alteração ao agente cria um horário livre ou corrige uma tabela de preços desatualizada no seu próprio sistema.

Reconhecimento de fala: a maioria das correções está na camada de decisão

A primeira falha mostra onde a chamada se desviou, nem sempre onde está a correção. Numa linha telefónica, muitos erros de reconhecimento não se resolvem na camada de reconhecimento: o áudio é comprimido e um empilhador pode fazer mais barulho do que a voz. A conversa tem de continuar certa quando o texto está errado, e esse trabalho faz-se na camada de decisão:

• Não responda a uma frase que não encaixa. Quando o texto ouvido não corresponde à pergunta que o agente acabou de fazer, o agente não age com base nele nem abre um tema novo. Diz que não percebeu e volta a perguntar.
• Mantenha uma lista de palavras mal ouvidas. As palavras que o reconhecimento erra nas chamadas reais entram numa lista, e o agente confirma-as com uma pergunta em vez de adivinhar.
• Use os dados do sistema. Quando a encomenda ou o registo já são conhecidos, o agente lê os dados ao cliente e pergunta: «É esta a sua encomenda?»
• Acrescente uma lista de palavras-chave no fim. Uma lista de nomes e termos de produto é um ajuste barato no reconhecimento, mas vem depois dos três passos anteriores.

Um exemplo escrito para este artigo, não uma chamada real: uma frase mal ouvida, tratada de duas formas.

A primeira resposta transforma um erro de reconhecimento numa encomenda cancelada. A segunda guarda a parte que encaixa e volta a perguntar o resto. Para saber mais sobre esta camada, veja como a IA de voz corrige o que ouve mal.

Ferramentas e passagem: confie no log, não na frase

Um agente que diz «A sua consulta está marcada» produziu uma frase, não uma marcação. Em cada ação, verifique o log da ferramenta: o pedido foi enviado? O que voltou? Havia um ID de registo? O agente só deve confirmar uma ação depois de uma resposta bem-sucedida. O nosso guia sobre registo no CRM explica o que uma chamada deve deixar no sistema.

A passagem falha de forma igualmente silenciosa. A transferência acontece, mas o resumo chega tarde ou nem chega. Ouça os primeiros segundos depois de cada transferência. Se o seu colega pergunta porque é que o cliente está a ligar, a passagem falhou. O guia sobre como desenhar a passagem para pessoas mostra o que o contexto deve incluir.

O fim da chamada: conte as despedidas

Muitos fluxos terminam a chamada com um temporizador ou assim que a tarefa fica concluída. Nas chamadas reais, isto corta as pessoas a meio de uma pergunta ou de um agradecimento. O agente não deve desligar antes de ouvir a despedida do cliente.

Em cada chamada que o agente terminou, leia a última frase do cliente antes de o agente desligar. Havia nela uma despedida? A percentagem de chamadas sem despedida é a sua taxa de chamadas cortadas, e pertence à camada de decisão.

Corrija uma camada de cada vez

A tabela das primeiras falhas define a ordem do trabalho:

1. Escolha a camada da IA com a contagem mais alta. O lado do negócio segue para o respetivo responsável.
2. Faça uma única alteração pensada para essas chamadas. Nas falhas de reconhecimento, essa alteração costuma ficar na camada de decisão, como vimos acima. Com duas alterações ao mesmo tempo, não há forma de saber qual delas ajudou.
3. Repita o teste com as mesmas chamadas falhadas. Passam a ser a sua bateria de testes de regressão: as mesmas falas dos clientes e, sempre que possível, as mesmas condições de áudio.
4. Compare as contagens de primeiras falhas antes e depois no mesmo tipo de tráfego: a mesma campanha, o mesmo tipo de lista ou o mesmo horário de chamadas de entrada. Uma lista mais fácil faz qualquer alteração parecer boa.

Espere que algumas chamadas mudem de camada em vez de desaparecerem. Uma chamada que agora passa no reconhecimento pode falhar mais à frente, nas ferramentas. Isso é progresso: a próxima correção fica à vista. O Agent Factory, a forma como a DRING constrói, testa e melhora os agentes, segue a mesma regra: uma alteração de cada vez, testada antes de entrar em produção.

Onde entra a DRING

Se um processo em produção está a render menos do que devia, peça uma chamada de retorno e traga-o para a conversa. Tenha à mão uma amostra de chamadas falhadas, com as gravações, se a sua política o permitir, e o resultado a que cada chamada devia ter chegado. A nossa equipa pode analisá-las consigo como este artigo descreve e ver onde cada uma falhou primeiro.

As alterações que mexem nos seus próprios sistemas são avaliadas à parte. As ações que um agente pode executar num CRM dependem da edição do CRM, das permissões e do acesso à API. Na DRING, é possível definir campos de análise adicionais e devolvê-los pela API, pelo CRM, pelo painel e pelos relatórios. A primeira camada que falhou pode ser um deles.

Cada agente que a DRING constrói passa por 1 000 a 10 000 conversas simuladas, criadas para a sua empresa, antes da primeira chamada real. Ainda assim, as chamadas reais mostram o que a simulação não apanhou. Por isso, depois do arranque, a melhoria parte de quem liga de verdade.