Testar uma URA (ou IVR) é ligar para o seu sistema telefônico como um cliente faria e verificar se cada chamada termina no lugar certo. A maioria das URAs com defeito quebra nas emendas: uma mensagem que mudou sem que a regra de roteamento mudasse junto, uma transferência para uma fila que fechou às 18h, um modelo de voz que entende “farmácia” como “fala, Márcia”. Essas falhas só aparecem quando você faz chamadas reais pelo caminho telefônico real.
Este guia cobre os tipos de teste comuns para URAs de teclado e de voz, e depois o que muda quando quem atende o telefone é um agente de voz com IA. Resumindo: um menu de teclado tem um roteiro correto por caminho, enquanto um agente de voz tem muitas conversas aceitáveis e um único resultado correto. Seus testes precisam verificar o resultado.
Os tipos de teste de URA
| Teste | O que responde | Quando rodar |
|---|---|---|
| Funcional | Este caminho toca as mensagens certas e termina no destino certo? | Ao criar ou alterar um caminho |
| Regressão | Todos os caminhos ainda funcionam depois de uma mudança? | Antes de cada versão |
| Reconhecimento de voz | O sistema entende as palavras que as pessoas realmente usam? | Ao adicionar uma intenção, um idioma ou um novo público |
| Carga | Continua funcionando no pico de volume esperado? | Antes do lançamento e dos picos sazonais |
| Estresse | O que quebra primeiro acima do pico, e quebra de forma segura? | Antes do lançamento, depois de mudanças de infraestrutura |
| Resistência | Algo piora depois de horas de tráfego normal? | Antes do lançamento |
| Experiência | Quanto tempo as pessoas esperam, e o som está certo? | Continuamente, a partir das chamadas de produção |
| Contingência | O que acontece quando um sistema interno, uma fila ou a operadora cai? | Antes do lançamento, depois a cada trimestre |
Os testes funcionais e de regressão pegam a maioria dos problemas. Os de carga, estresse e resistência importam quando a URA fica na frente de uma central de atendimento com picos reais, como um período de matrículas, um recall de produto ou a segunda-feira depois do fechamento da fatura.
Testar um menu de teclado ou de voz
Uma URA tradicional é uma árvore. Cada nó tem uma mensagem e um conjunto fixo de entradas, então cada caminho pode ser escrito e verificado.
Comece exportando o fluxo de chamadas e transformando cada caminho em um caso de teste. Um caminho é a sequência de entradas mais o resultado esperado: aperte 2, depois 1, digite um número de conta, e a chamada deve chegar à fila de cobrança com a conta anexada. Inclua os caminhos que as pessoas tomam sem querer, não só os ideais:
- Nenhuma entrada, até o tempo esgotar
- Uma tecla inválida e depois uma válida
- Apertar
0ou dizer “atendente” em cada nível - Ligar fora do horário de atendimento
- Um número de conta que não existe
- Digitar antes de a mensagem terminar (quem conhece o menu faz isso)
Nos menus de voz, as entradas de teste são gravações. Use falantes diferentes, uma linha telefônica em vez de um microfone de estúdio e ruído de fundo, como um carro ou uma cozinha. As palavras devem ser as que os clientes dizem nos seus registros de chamadas, não os rótulos do menu: as pessoas perguntam da “minha conta” com muito mais frequência do que dizem “serviços de cadastro”.
Verifique os dados além do áudio. Um teste passa quando a chamada chega à fila de cobrança e a tela do atendente mostra a conta certa. Se a URA coletou o número mas a transferência o perdeu, a pessoa precisa repetir, e isso é uma falha mesmo que todas as mensagens tenham tocado corretamente.
Testar uma URA conversacional ou um agente de voz com IA
Quando um agente de voz com IA atende o telefone, comparar roteiros deixa de funcionar. O agente pode dizer “Claro, eu remarco para você” em uma chamada e “Certo, posso mudar essa consulta” na seguinte. As duas estão corretas. Um teste que compara o texto exato falha em toda execução e não diz nada.
Escreva cenários com um resultado esperado:
| Cenário | Comportamento de quem liga | Condição de sucesso |
|---|---|---|
| Remarcação | Dá nome e data de nascimento, pede quinta à tarde | Consulta remarcada na agenda; a pessoa ouve o novo horário |
| Identidade errada | Dá uma data de nascimento que não confere | Nenhum detalhe da consulta lido; outra forma de verificação oferecida |
| Mudança de ideia | Pergunta sobre cobrança, depois diz “na verdade, é sobre a entrega” | Trata a entrega; não transfere para cobrança |
| Interrupção | Começa a falar enquanto o agente está no meio da frase | O agente para de falar e responde ao novo pedido |
| Uma pessoa, já | Diz “quero falar com um atendente” na primeira frase | Transfere, ou dá a opção fora do horário, sem discutir |
| Sistema fora do ar | A API da agenda retorna um erro | O agente não diz que a reserva deu certo |
| Repetir um número | Dá um número de pedido de 10 dígitos com pausas | O agente repete todos os dígitos corretamente |
Rode cada cenário mais de uma vez. Um agente de voz pode passar em um cenário quatro vezes e falhar na quinta porque o pedido foi feito com outras palavras ou o modelo seguiu outro caminho na conversa. De cinco a dez execuções por cenário, com frases variadas, pegam a maior parte disso. Perfis ajudam: alguém com pressa, alguém confuso, alguém com sotaque regional forte, alguém em um ambiente barulhento.
Avalie cada execução de duas formas. As verificações objetivas leem seus sistemas: a consulta foi remarcada, a transferência chegou ao número certo, o agente encerrou a chamada? As verificações de julgamento leem a transcrição: o agente confirmou o novo horário em voz alta, manteve a educação quando a pessoa se irritou? Um juiz LLM com uma única pergunta precisa por métrica funciona bem para o segundo tipo. Um juiz a quem você pergunta “foi uma boa chamada?” devolve opiniões; um a quem você pergunta “a pessoa ouviu o novo horário antes de a chamada terminar? Responda sim ou não e cite a frase” devolve algo que você pode contar.
O guia de URA conversacional tem um conjunto de testes específico para roteamento, incluindo como ler um número de precisão de roteamento sem confiar demais nele.
Meça a latência no telefone, não nos logs
Quem liga percebe o atraso como o intervalo entre parar de falar e o agente começar. Esse intervalo inclui decidir que a vez de falar terminou, o LLM, a síntese de voz e a volta pelo provedor de telefonia e pela operadora. Um painel que mostra só o tempo até o primeiro byte da síntese de voz cobre uma parte disso.
Meça a partir de uma gravação da própria chamada. Grave os dois lados, marque o fim de cada fala de quem liga e o início de cada resposta, e informe a mediana e os 5% mais lentos. As chamadas mais lentas são as que recebem um “alô? você está aí?” e uma pergunta repetida.
As chamadas de saída ainda têm um limite rígido. Nos Estados Unidos, pela regra de chamadas abandonadas da TCPA, uma chamada conta como abandonada se a pessoa que atende não é conectada em até dois segundos depois de terminar a saudação. A 2X Solutions reduziu a latência de resposta de 500–900 ms para menos de 100 ms e baixou a taxa de chamadas abandonadas de 3,4% para menos de 1,25% em milhões de chamadas por mês. Se o seu agente faz ligações, meça o tempo entre o “Alô?” e a primeira palavra do agente em todo cenário de saída.
Testes de regressão quando os modelos mudam
Agentes de voz mudam de formas que os menus de teclado nunca mudaram. Uma nova mensagem, um novo LLM, uma nova voz ou um novo modelo de voz podem alterar caminhos que você não tocou. Trate cada um como uma nova versão e rode de novo todos os cenários.
Fixe o que puder. O Sonic, da Cartesia, tem snapshots datados como sonic-3.6-2026-08-27 que nunca mudam, então você pode rodar seus cenários contra um novo snapshot antes de passar a produção para ele. O Managed Agents salva cada mudança de configuração como uma versão; se uma nova mensagem falhar em um cenário que antes passava, você pode restaurar a versão anterior e continuar investigando.
Guarde as falhas. Toda chamada de produção que deu errado vira um novo cenário de regressão, com as palavras reais de quem ligou. Depois de alguns meses, esse conjunto é mais útil do que qualquer coisa que você conseguiria escrever no início.
Montar um chamador de teste com a Cartesia
Você pode montar um chamador de teste automatizado simples no Cartesia Managed Agents:
- Crie um agente de teste cujas instruções descrevam um cenário: quem ele é, o que quer e como deve reagir à URA.
- Ative a ferramenta de sistema
send_dtmfpara que o agente possa apertar teclas enquanto navega por um menu telefônico. - Faça uma chamada de saída do agente de teste para o número da sua URA. Para uma bateria completa, as chamadas em lote enfileiram até 5.000 chamadas e as discam até o limite de concorrência que você definir.
- Atribua métricas personalizadas ao agente de teste, cada uma com uma pergunta precisa para o juiz LLM, como “A chamada chegou à fila da farmácia?”. Depois exporte os resultados em CSV.
As mesmas métricas funcionam no seu agente de produção. O Managed Agents avalia cada chamada concluída com duas métricas integradas: se a chamada terminou sem falha do agente e o tempo até o primeiro byte de áudio na primeira resposta do agente. As métricas personalizadas que você atribuir se aplicam às chamadas seguintes, o que transforma o tráfego de produção em um conjunto de monitoramento.
Essa configuração serve para execuções de regressão e monitoramento em produção. As chamadas em lote dividem com o tráfego de produção o limite de concorrência de chamadas de agente da sua conta, então um teste de carga no nível do pico de uma central de atendimento precisa de um plano de capacidade próprio. Se você quer uma bateria de testes gerenciada ou uma equipe que faça os testes de carga por você, use um fornecedor especializado. A Cekura roda chamadores simulados contra agentes de voz antes e depois do lançamento e pode usar vozes da Cartesia nesses chamadores. A Cyara é a opção tradicional para URAs clássicas de centrais de atendimento. Coval e Hamming também testam agentes de voz com IA.
Por onde começar
Se você não testa nada hoje, comece com oito chamadas: os quatro motivos de contato mais comuns, uma chamada fora do horário, alguém que pede um atendente, uma entrada inválida e uma chamada com um sistema interno fora do ar. Faça-as manualmente uma vez pelo número real, anote o que aconteceu e depois automatize essas mesmas oito. Adicione cenários a partir das falhas reais conforme elas aparecem.
Se você vai trocar um menu de teclado por um agente de voz, rode os dois no mesmo conjunto de cenários antes de mudar. O guia de automação da central de atendimento cobre a implantação, e o guia de agentes de voz explica as partes que você está testando. Para testar um agente no seu próprio fluxo de chamadas, crie um no playground e ligue para ele.