Como medir os resultados de um agente de voz com IA

Defina o resultado antes do piloto

O resultado de um agente de voz deve ser medido pela tarefa: resposta correta, consulta confirmada, agendamento registrado ou oportunidade aceita por vendas. Escolha uma definição verificável antes do piloto e identifique onde encontrar a evidência. Encerrar uma chamada é um evento técnico; resolver o pedido exige um critério de negócio.

Escreva o que entra no cálculo. Se você medir resolução, por exemplo, divida as demandas resolvidas pelo total de demandas elegíveis para aquele fluxo. Explique quais assuntos estão fora do escopo para evitar uma comparação enganosa.

Acompanhe qualidade e esforço

Combine o resultado principal com sinais que ajudam a interpretá-lo. Uma conversa encerrada pode esconder uma pessoa que desistiu. Uma transferência pode ser a decisão correta.

• Tarefa concluída e confirmação no sistema de destino.
• Motivos de encaminhamento e falhas de ferramentas.
• Repetição de contato sobre o mesmo problema.
• Clareza do contexto recebido pela equipe.
• Tempo e trabalho necessários para concluir a demanda.

Compare situações semelhantes

Registre uma referência do processo atual e escolha um período de piloto com volume e tipos de demanda comparáveis. Mudanças em horário, equipe ou campanha podem afetar o resultado, mesmo que o agente não tenha mudado.

Quando houver poucos casos, examine as conversas individualmente e evite transformar uma amostra pequena em promessa de desempenho. Registre também o custo de telefonia, modelos, integrações e trabalho humano para entender o custo por tarefa concluída.

Use os dados para decidir a próxima mudança

Classifique os problemas encontrados: conhecimento incompleto, instrução ambígua, integração indisponível ou pedido fora do escopo. Escolha um ajuste, teste novamente e observe se ele melhorou a métrica sem criar novos erros.

Os relatórios e a revisão de chamadas no Tigy ajudam a observar o atendimento. Alguns resultados comerciais, como uma venda concluída ou um agendamento confirmado, precisam ser verificados no sistema responsável. Combine essas fontes para decidir quando expandir o piloto.

Combine resultado, experiência e esforço

Escolha uma métrica principal ligada ao trabalho e algumas medidas de proteção. Para agendamento, acompanhe reservas confirmadas, duplicidades e correções. Para suporte, resolução verificável, repetição e encaminhamento. Para vendas, contato aceito pela equipe, dados corrigidos e próximo passo realizado.

Observe experiência por amostra: clareza, repetição de perguntas, interrupções e expectativa criada. Uma avaliação humana com critérios explícitos ajuda a identificar o motivo de uma nota. “Ruim” é pouco acionável; “confirmou uma reserva sem retorno do sistema” aponta uma condição que pode ser corrigida e testada.

Inclua esforço após a chamada. Um agente pode encerrar rapidamente e transferir trabalho para outra equipe. Cronometre revisão, correção e retorno no processo completo. O benefício operacional aparece quando o total melhora sem degradar o resultado. Métricas derivadas podem ser calculadas fora do Tigy combinando execuções e dados do sistema responsável.

Monte uma comparação que consiga explicar

Registre volume, tipos de pedido, horários e condições de atendimento antes do piloto. Compare recortes semelhantes: campanha nova, feriado e mudança de equipe podem alterar o resultado independentemente do agente. Se não houver comparação controlada, descreva o período observado e suas limitações.

Para comparar instruções, use o mesmo conjunto de cenários e mantenha ferramentas e documentos constantes quando possível. Mude uma variável e registre qual resultado deveria melhorar. Se você altera voz, fonte e regra de transferência ao mesmo tempo, uma diferença final não permite atribuir o efeito a cada mudança.

Em amostras pequenas, reporte contagens junto de percentuais. Cinco acertos em seis chamadas e cinquenta em sessenta produzem a mesma proporção, mas sustentam conclusões diferentes. Revise erros importantes individualmente e preserve-os no conjunto de testes. A decisão de expandir deve considerar gravidade, estabilidade e capacidade de tratar exceções.

Feche o ciclo entre análise e correção

Classifique falhas por origem: informação ausente, interpretação, campo incorreto, ferramenta, telefonia ou processo posterior. Corrija a fonte responsável e transforme a conversa em um cenário reproduzível com dados fictícios. A transcrição fornece evidência da fala; uma confirmação no sistema externo fornece evidência da operação.

Defina responsável, prazo de revisão e critério de retorno ao piloto. Problemas de conteúdo podem seguir um fluxo diferente de falhas de autorização. Evite uma fila em que tudo recebe a etiqueta “melhorar prompt”, pois isso esconde dependências que o texto não resolve.

Reavalie as métricas depois da correção e procure novos efeitos. Uma regra de confirmação pode melhorar acerto de campos e aumentar duração; isso pode ser um custo aceitável se reduz retrabalho. A avaliação precisa explicar a escolha, não perseguir todas as métricas na mesma direção.

Defina a população antes de calcular a taxa

Uma taxa de resolução só faz sentido quando o denominador está claro. Se o agente foi criado para consultas de pedido, misturar dúvidas de cobrança e contatos errados na mesma taxa pode esconder tanto o desempenho quanto a falta de escopo. Conte primeiro quantas conversas trazem uma solicitação elegível, quantas têm dados suficientes e quantas exigem atendimento fora das capacidades definidas.

Uma fórmula operacional simples é dividir solicitações elegíveis concluídas pelo total de solicitações elegíveis avaliadas. O termo “concluídas” precisa de evidência: retorno válido da consulta, registro confirmado ou resposta correta conforme a fonte aprovada. A fórmula é uma definição de trabalho, não um padrão universal. A empresa pode precisar de outro recorte, mas deve registrá-lo antes de comparar períodos.

Considere um exemplo fictício de cem conversas. Sessenta tratam de uma consulta que o agente pode fazer; vinte são dúvidas de outro setor; dez são chamadas sem solicitação identificável; dez terminam antes da coleta mínima. Se quarenta e oito das sessenta consultas elegíveis são concluídas, a taxa desse recorte é oitenta por cento. Dividir quarenta e oito por cem responde a outra pergunta: a proporção de todos os contatos que terminou naquela resolução. Ambos os números podem ser úteis, desde que tenham nomes diferentes.

Cuidado com exclusões que melhoram o indicador artificialmente. Remover todas as falhas de ferramenta do denominador produz uma visão limitada da conversa, mas não do serviço completo. Se quiser medir qualidade da resposta quando a API (interface de programação de aplicações) funciona, publique essa medida como recorte adicional. Mantenha também uma medida que mostre a experiência quando dependências falham.

Estabeleça regras para conversas com mais de uma intenção. Uma chamada pode resolver uma consulta de pedido e deixar uma alteração de endereço pendente. Você pode medir tarefas separadas e uma visão da chamada inteira. O importante é não escolher depois a unidade que deixa o resultado mais favorável.

Crie uma classificação que duas pessoas consigam aplicar

Antes de automatizar a análise, faça uma revisão manual de exemplos fictícios ou registros tratados conforme o processo da equipe. Use poucas categorias com critérios explícitos: concluído, parcialmente concluído, encaminhado, falha de fonte, falha de entendimento e abandono. Uma categoria deve descrever o resultado ou a causa; quando precisar das duas dimensões, registre-as em campos separados.

Dois revisores devem avaliar uma pequena amostra sem consultar a classificação um do outro. Onde discordarem, investigue a definição. “Encaminhado” pode significar que a ferramenta foi chamada para um revisor e que a equipe atendeu para outro. Essa divergência impede uma comparação confiável. Escreva exemplos de inclusão e exclusão até que o critério fique aplicável.

Não atribua intenção ao cliente sem evidência. Uma chamada encerrada depois da resposta pode significar satisfação, interrupção ou desistência. Se não existe confirmação ou resultado de sistema suficiente, use a categoria apropriada à incerteza. O relatório pode mostrar quantos casos não permitem conclusão; esconder essa dúvida transforma uma estimativa em certeza.

A análise de falhas precisa ligar a observação à origem. “Resposta errada” pode vir de documento ultrapassado, consulta correta ao pedido errado ou explicação que mudou o sentido do retorno. Registre o dado de entrada, a fonte disponível e a ação observada. Essa cadeia ajuda a escolher uma correção que realmente modifica o resultado.

Depois, transforme casos recorrentes em testes. Um relatório que apenas enumera problemas não melhora o agente. O teste precisa conter uma entrada reproduzível, uma expectativa e a evidência da mudança. Preserve uma versão anterior para comparar quando a alteração mexer em instruções, fontes ou ferramentas.

Compare períodos com a mesma regra de atendimento

Um agente pode parecer melhor depois de uma mudança porque passou a receber contatos mais simples. Compare a distribuição de motivos, horários e canais junto com o resultado. Se um período inclui telefone e outro apenas teste por texto, a diferença não mede somente a qualidade do prompt. O canal introduz reconhecimento de fala, turnos e condições de rede que o texto não avalia.

Use mediana e valores mais altos da distribuição para investigar duração e espera, quando os dados permitirem. Uma média pode esconder um pequeno conjunto de chamadas muito lentas. Relacione demora à tarefa e ao resultado: coletar dados necessários para uma reserva não é equivalente a repetir três vezes uma pergunta já respondida. O tempo deve ser interpretado pelo que aconteceu durante a conversa.

Ao calcular custo, declare o que entrou na conta. Uso da plataforma, telefonia, serviços externos e revisão humana podem pertencer a fontes diferentes. Um custo por chamada não é um custo por tarefa resolvida. Dividir o custo observado pelas resoluções confirmadas aproxima a medida do objetivo, desde que você mostre também o volume e a definição de sucesso.

A decisão de ampliar o piloto deve considerar falhas importantes mesmo quando a taxa geral melhora. Um pequeno número de registros duplicados ou confirmações indevidas pode merecer correção antes da expansão. Informe a quantidade observada e o contexto, sem transformar uma amostra curta em previsão estatística para todo o atendimento.