Quando a IA dá um preço errado a um cliente

Em resumo

Uma resposta errada numa chamada com IA raramente é um mistério. Entra por uma de cinco portas: Fonte desatualizada, Fonte em falta, Pergunta mal ouvida, Erro de consulta ou Fora da alçada. Quatro delas começam fora do modelo: Fonte desatualizada e Fonte em falta começam na fonte, Pergunta mal ouvida no reconhecimento de fala e Erro de consulta numa consulta ao sistema. Só a porta Fora da alçada começa no próprio agente, quando oferece mais do que lhe é permitido.

Por isso, a prevenção faz-se sobretudo nas fontes e nos limites de alçada. Todas as respostas passam pelo mesmo filtro: vêm de uma fonte aprovada, a fonte está atualizada, a resposta está dentro do limite de alçada, e cada número, data e valor passa por uma confirmação. Se uma resposta falhar uma verificação, segue-se a saída segura: o agente passa a chamada à equipa ou propõe voltar a ligar mais tarde.

Mesmo assim, algumas respostas erradas vão passar. Para essas, há um protocolo fixo: Conter, Identificar, Corrigir, Registar, Voltar a testar. A dimensão de um incidente é dada pela sua janela de exposição: do momento em que a resposta errada se tornou possível até ao momento em que foi corrigida. Essa janela não depende do modelo. Depende da rapidez com que a sua fonte acompanha uma mudança no negócio, com que a empresa deteta um problema e com que o contém.

Todos os números de exemplo deste guia foram criados para o efeito: não são dados da DRING nem do setor.

As cinco portas por onde entra uma resposta errada

Cada porta tem o seu próprio controlo.

Só a porta Fora da alçada se fecha com o limite de alçada. As outras quatro fecham-se com trabalho nas fontes, na confirmação e nas consultas. Um erro de Fonte em falta acaba num palpite do agente, mas começa numa lacuna da fonte, e a primeira verificação do filtro de respostas trava esse palpite. Para falhas de consulta, como um sistema que não responde a tempo, veja o nosso artigo sobre porque é que chamar ferramentas não é o mesmo que automatizar.

Prevenção: o filtro de respostas

O filtro de respostas é uma sequência fixa de passos, igual para todas as respostas. Antes de o cliente ouvir a resposta, há três verificações: a resposta está numa fonte aprovada? A fonte está atualizada? A resposta está dentro do limite de alçada? Depois, o agente repete cada número, data e valor para o cliente confirmar, antes de prometer ou marcar seja o que for. Um «não» em qualquer das três verificações envia a chamada para a saída segura.

Fontes aprovadas, cada uma com um responsável e uma data de entrada em vigor

Faça a lista de todas as fontes a partir das quais o agente pode responder: a tabela de preços, a política de devoluções, a base de conhecimento, a consulta de encomendas. Cada uma delas é uma fonte aprovada. Atribua a cada uma um responsável pela fonte, a pessoa que a altera quando o negócio muda. Dê a cada versão uma data de entrada em vigor, a data e a hora a partir das quais essa versão é válida.

Mantenha uma única fonte aprovada por tema. No incidente de exemplo mais abaixo, a tabela de preços do site e a fonte do agente eram documentos separados, e só um deles mudou a tempo.

Verificação 1: a resposta está numa fonte aprovada?

Se a resposta não estiver numa fonte aprovada, o agente segue para a saída segura. Um palpite bem-intencionado continua a ser um erro de Fonte em falta.

Verificação 2: a fonte está atualizada?

Introduza cada nova versão com a sua data de entrada em vigor antes de a mudança acontecer. Assim, a fonte está atualizada no momento em que o preço muda, e não quando alguém se lembrar de a editar. Se vier aí uma mudança e a nova versão ainda não estiver pronta, passe o tema para a saída segura até que esteja.

Verificação 3: a resposta está dentro do limite de alçada?

O limite de alçada estabelece o que o agente pode dizer ou fazer sem intervenção de uma pessoa. Escreva-o tema a tema, em três níveis:

«Tem de passar à equipa» quer dizer saída segura: uma pessoa atende já a chamada ou volta a ligar mais tarde para confirmar. O nosso guia sobre como desenhar a passagem para pessoas explica o que essa pessoa deve receber com a chamada.

Depois, a confirmação: cada número, data e valor

Numa linha com ruído, sessenta e setenta confundem-se facilmente. Por isso, o agente repete cada número, data e valor que diz ou com base no qual vai agir, e o cliente confirma antes de se prometer ou marcar seja o que for. A confirmação também apanha uma Pergunta mal ouvida, porque o cliente ouve de que plano o agente está a falar. Um exemplo, já depois da correção do incidente descrito mais abaixo:

• Cliente: «Olhe, quanto é que está agora o plano de proteção?»
• Agente: «O plano de proteção custa 14 € por mês. Repito: catorze euros por mês. É desse plano que o senhor está a falar?»
• Cliente: «Sim, catorze. É esse mesmo.»

E o mesmo agente no limite da sua alçada:

• Cliente: «Na semana passada, o vosso site dizia doze. Não me faz por doze?»
• Agente: «Não consigo alterar o preço nesta chamada, mas um colega pode analisar o seu caso. O senhor prefere que lhe passe já a chamada, ou que ele lhe volte a ligar?»

Teste o filtro antes de cada nova versão

Antes de cada nova versão, teste pelo menos um caso por porta:

• Fonte desatualizada: um preço novo com uma data de entrada em vigor. As chamadas anteriores a essa data recebem o preço antigo, e as posteriores recebem o preço atual.
• Fonte em falta: perguntas que nenhuma fonte aprovada cobre. O agente chega à saída segura.
• Pergunta mal ouvida: nomes de produtos parecidos, com ruído de fundo. A confirmação apanha o produto errado.
• Erro de consulta: uma consulta que falha, não devolve nada ou devolve outra encomenda. O agente não inventa um resultado e chega à saída segura.
• Fora da alçada: um pedido de desconto ou de reembolso. O agente passa a chamada à equipa.

O nosso guia sobre como testar um agente de IA de voz antes de entrar em produção mostra como construir a bateria de testes completa.

Um incidente de exemplo: uma mudança de preço que escapou ao agente

Exemplo, e não dados reais. Um retalhista aumentou o preço do seu plano de proteção de 12 € para 14 € por mês, com entrada em vigor na segunda-feira às 9h00. A tabela de preços do site mudou a tempo. A fonte aprovada do agente era um documento separado, e ninguém o atualizou quando o preço mudou. Na quarta-feira às 10h30 chegou a primeira reclamação: um cliente a quem tinham dito 12 € e a quem foram cobrados 14 €. O documento foi corrigido na quarta-feira às 14h00, e foi esse o passo Conter. A janela de exposição foi de segunda-feira às 9h00 a quarta-feira às 14h00: 53 horas.

O passo Conter só aconteceu 3 horas e 30 minutos depois da primeira reclamação, e durante esse tempo quem ligava ainda podia ouvir 12 €. Passar à equipa as perguntas sobre o preço do plano, poucos minutos depois da reclamação, teria evitado isso enquanto o documento era corrigido.

Depois das 14h00, a equipa passou ao passo Identificar. Procurou o plano nas transcrições da janela e depois leu todas as chamadas que o mencionavam:

As três últimas linhas somam as 120 chamadas que mencionam o plano: 46, mais 61, mais 13. Por isso, os clientes afetados são 46, e não 900. Contactar os 900 teria confundido 854 clientes que nunca ouviram 12 €. Contactar só o cliente que reclamou teria deixado 45 clientes afetados com um preço errado. Na quinta-feira, a equipa contactou os 46 clientes afetados para lhes dar o preço atual.

Duas mudanças teriam encurtado a janela. Com o novo preço e a sua data de entrada em vigor introduzidos na fonte aprovada antes de segunda-feira, a janela teria sido de 0 horas. Com uma verificação diária que compara o preço dito em cada chamada com a tabela de preços atual, a primeira verificação, na terça-feira às 8h00, teria assinalado as chamadas com 12 €. Se a fonte tivesse sido corrigida nessa altura, a janela teria sido de 23 horas em vez de 53.

O protocolo de resposta: cinco passos

Quando uma resposta errada chega aos clientes, siga os mesmos cinco passos, pela mesma ordem. Conter vem antes de Identificar: enquanto a equipa procura as chamadas, os novos clientes que ligam ainda podem ouvir a resposta errada.

Identificar quer dizer encontrar os clientes afetados, não toda a gente que ligou. Parta da janela de exposição, restrinja ao tema e depois leia as chamadas. Se a sua equipa responde a partir da mesma fonte, verifique também as chamadas dela.

Corrigir exige uma política definida antes do primeiro incidente. A empresa mantém o preço errado que foi dito, ou explica o preço atual? É uma decisão de política comercial. Tome-a de antemão, ponha-a por escrito e entregue-a a quem faz as chamadas de correção. Saber se um preço indicado vincula a empresa é uma questão para os seus consultores jurídicos, e este guia não lhe dá resposta.

Registar usa sempre os mesmos campos do registo de incidentes, para que os incidentes possam ser comparados. A entrada do incidente de exemplo:

O que medir

Três números mostram se o filtro e o protocolo funcionam:

• Taxa de respostas erradas nas chamadas revistas: chamadas revistas com informação errada, divididas pelas chamadas revistas. É a parte de informação errada da taxa de ações erradas do nosso artigo sobre critérios de sucesso de um piloto de IA de voz, por isso as duas taxas continuam comparáveis. Atribua a cada resposta errada a sua porta: a contagem por porta mostra onde trabalhar a seguir.
• Duração da janela de exposição: por incidente, em horas. No exemplo, 53 horas: 49 horas e 30 minutos até à primeira reclamação e, depois, 3 horas e 30 minutos até à correção.
• Tempo entre o primeiro sinal e o passo Conter: desde a primeira reclamação, o primeiro problema encontrado na revisão ou o primeiro alerta da verificação até ao passo Conter. No exemplo, 3 horas e 30 minutos.

Nenhum filtro garante uma taxa de respostas erradas de zero, e um mês sem incidentes não prova que o filtro funciona. Como explica o artigo sobre o piloto, zero ações erradas em 300 chamadas revistas continua a ser compatível com uma taxa real de até cerca de 1 %.

A revisão aleatória também pode deixar escapar um tema restrito, ou apanhá-lo tarde. No exemplo, 46 das 900 chamadas da janela foram afetadas, cerca de 5 em cada 100, todas sobre o mesmo plano. Uma verificação diária do preço dito em cada chamada face à tabela de preços atual olha para todas as chamadas sobre esse tema, e não para uma amostra.

Onde entra a DRING

Salvaguardas, passagem para uma pessoa, análise pós-chamada, testes e monitorização fazem parte da base comum de todos os pacotes da DRING. Neste guia, o limite de alçada é uma salvaguarda, a saída segura apoia-se na passagem para uma pessoa e a verificação diária apoia-se na análise pós-chamada.

A análise pós-chamada pode devolver campos adicionais definidos pela sua empresa, através da API, do seu CRM, do painel e dos relatórios. Um deles pode ser o preço dito em cada chamada, o que torna possível uma verificação diária face à tabela de preços atual. A nossa página de análise de chamadas mostra o painel e os relatórios.

Cada agente da DRING passa por 1 000 a 10 000 conversas simuladas, criadas para a sua empresa, antes da primeira chamada real. As simulações testam o filtro antes do arranque. Não substituem o protocolo de resposta nas chamadas reais.

Se vier aí uma mudança de preço ou de política na sua linha, peça que a DRING lhe ligue. Tenha à mão a sua tabela de preços e o documento a partir do qual o seu agente responde. A nossa equipa pode analisá-los consigo, à luz das cinco portas.