Checklist de testes para agentes de voz antes da publicação

Transforme tarefas em critérios de aceitação

Um checklist de testes de agente de voz deve cobrir a tarefa normal e as decisões que mudam seu resultado. Prepare pedidos completos, dados ausentes, correções, fontes indisponíveis e solicitações fora do escopo. Escreva a resposta e a ação esperadas antes de executar; ouvir uma resposta convincente não basta para aprovar o caso.

Inclua situações que exigem uma saída: assunto fora do escopo, solicitação incompleta e pedido para falar com uma pessoa. Defina quem dará continuidade e como a pessoa será informada.

Use texto e voz para investigar problemas diferentes

O teste por texto no Tigy ajuda a revisar instruções e ferramentas sem depender do áudio. O teste por voz permite conferir reconhecimento de fala, pronúncia, pausas e interrupções.

Salve as alterações antes de comparar duas rodadas. Use o mesmo cenário e mude um aspecto por vez; do contrário, fica difícil identificar o que produziu uma melhora ou um novo erro.

Dê espaço aos caminhos menos convenientes

Peça para repetir, corrija um nome e faça uma pausa no meio da frase. Simule ausência de informação e indisponibilidade de uma ferramenta usando um ambiente de teste.

• O dado corrigido substitui o anterior?
• O agente espera a frase terminar?
• A ação usa os parâmetros confirmados?
• A falha recebe uma explicação sem resultado inventado?
• A conversa termina com um próximo passo compreensível?

Registre evidências e repita após mudanças

Revise transcrição, ações e os dados disponíveis da execução. Anote o cenário, a versão testada, o resultado esperado e o observado. Mantenha os casos que revelaram problemas para testar novamente.

Comece o piloto com volume e escopo que a equipe consiga acompanhar. Novos documentos, instruções ou integrações podem mudar o comportamento; rode o checklist novamente antes de ampliar o atendimento.

Uma matriz para baixar e preencher

A matriz usa dados fictícios e oito cenários. Preencha o resultado observado, referência da execução e evidência externa quando houver uma ação. As células em branco são destinadas ao seu teste; não representam uma medição já feita.

Comece com texto para conferir instruções e ferramentas, depois repita em voz os casos de reconhecimento e interrupção. Registre versão ou configuração avaliada, canal e data. Marque aprovação somente quando a evidência satisfizer o critério; uma resposta convincente não basta para uma escrita.

Corrija uma causa por rodada e repita o caso que falhou junto dos casos que já passavam. Preserve a matriz anterior para comparar. Abra o arquivo CSV, um formato de tabela, em uma planilha ou editor de texto. Você pode baixá-lo sem acessar sistemas internos.

Execute os casos sem contaminar a produção

Para testes que criam ou alteram registros, peça à equipe de integração uma conexão de teste, com chave de acesso própria e dados fictícios. Combine quais registros podem ser modificados. Se o teste envia uma notificação, confira o destinatário antes de começar: uma conversa de teste ainda pode acionar um sistema real.

Teste sucesso, resposta vazia, validação recusada e indisponibilidade. Para escrita, inclua uma tentativa cujo retorno se perde depois da operação. O adaptador precisa permitir descobrir o estado sem duplicar a ação. Repita o cenário com uma correção de dado durante a conversa.

Ouça o áudio completo. Confira se a pessoa consegue fornecer o identificador, interromper e pedir repetição. Testes em texto não mostram esses problemas. Depois valide a chamada telefônica pelo número do piloto e revise o registro correspondente no workspace certo.

Transforme o checklist em uma decisão de publicação

Dê a cada item um estado e uma evidência. Um caso não executado permanece pendente; não deve receber aprovação por semelhança com outro. Registre falhas e a mudança que pretende corrigi-las, repetindo os cenários afetados.

Defina quais erros impedem a publicação, quem decide e qual canal alternativo atende durante uma interrupção. A equipe precisa conseguir interromper o piloto de forma operacional, além de alterar o agente. Planeje como corrigir o rascunho, salvar, testar e publicar novamente antes de depender desse procedimento.

Depois da publicação, execute uma conversa nova e confirme o comportamento no canal real. Preserve a matriz como referência para próximas versões. O checklist continua útil quando documentos, ferramentas e telefonia mudam, pois uma alteração externa pode afetar o atendimento mesmo com o prompt intacto.

Escreva o resultado esperado antes de iniciar o teste

Um teste útil começa com uma expectativa independente da resposta produzida. Se a pessoa responsável escreve o critério depois de ouvir o agente, pode aceitar uma resposta convincente que não corresponde à tarefa. Registre intenção, dados iniciais, ação permitida e resultado esperado. O critério deve permitir apontar por que uma execução passou ou falhou.

Para uma consulta fictícia de pedido, o caso pode especificar um código válido e um retorno conhecido do sistema de teste. A expectativa é consultar esse código e explicar o estado sem alterar a previsão para uma garantia. Outro caso usa um código incompleto: a expectativa é pedir o restante antes de consultar. O conjunto avalia decisões distintas, embora ambas as conversas tratem de pedidos.

Não descreva o sucesso apenas como “responder corretamente”. Escreva qual fonte sustenta a resposta e qual condição precisa ser preservada. Para uma política de troca, por exemplo, o agente deve citar o prazo aprovado e explicar a condição que se aplica ao item. Se a regra não cobre o caso, o resultado esperado pode ser admitir a insuficiência e apontar o contato apropriado.

Inclua critérios negativos. O agente não deve prometer consulta sem ferramenta, confirmar escrita sem retorno ou inventar dados ausentes. Esses critérios evitam que uma frase agradável esconda um erro de autoridade. Avalie também se perguntas desnecessárias expõem dados ou atrapalham a tarefa, mesmo quando a resposta final está correta.

Use dados fictícios que exercitem o contrato real. Um identificador impossível de validar talvez teste apenas uma rejeição inicial. Para avaliar uma consulta bem-sucedida, prepare um registro de ensaio que siga as regras do sistema. Separe os casos destinados a testar validação daqueles destinados a testar a explicação de um resultado válido.

Combine variações de linguagem e condição operacional

Uma coleção de perguntas completas e bem escritas deixa de fora boa parte do atendimento por voz. As pessoas usam abreviações, interrompem uma frase, respondem fora de ordem e mudam de ideia. Para cada intenção principal, prepare uma versão direta, uma versão informal e uma versão com informação ausente. Depois acrescente condições de sistema, como retorno vazio ou indisponibilidade.

Não é necessário testar todas as combinações imagináveis de uma só vez. Priorize combinações que mudam a decisão ou o risco. Uma correção de número antes de uma consulta é importante; uma correção antes de uma operação de escrita pode ser ainda mais relevante. Uma frase de cortesia diferente, sem mudança de intenção, geralmente merece menos atenção que um resultado ambíguo da ferramenta.

Inclua mudança de intenção dentro da chamada. A pessoa começa pedindo disponibilidade, escolhe um horário e depois decide não reservar. O agente deve acompanhar a decisão atual e evitar criar uma reserva com base na intenção anterior. Outro caso começa com uma dúvida comercial e termina com um pedido de suporte. A resposta final não deve manter o destino escolhido no início.

Teste informações conflitantes. Um cliente pode afirmar que um serviço é gratuito quando a fonte aprovada descreve condições específicas. A expectativa é explicar a informação disponível com clareza e sem concordar automaticamente. Use também uma pergunta que cita uma política antiga, para conferir se a fonte atual prevalece.

Para voz, inclua pausas naturais, nomes do domínio e sequências numéricas. Ouça se a confirmação é compreensível e se a pessoa consegue corrigir um campo. Uma transcrição aparentemente correta não prova que a voz pronunciou o código de forma inteligível. Texto e áudio fornecem evidências diferentes sobre a mesma execução.

Por fim, teste o pedido de atendimento humano e o encerramento. A pessoa pode pedir uma pessoa antes de explicar o assunto ou concluir que não precisa continuar. O agente deve respeitar essas mudanças dentro das opções disponíveis. Avaliar apenas o início e a resposta central deixa de fora o momento em que a conversa realmente entrega ou abandona o resultado.

Use falhas para construir um conjunto de regressão

Quando um caso falha, registre a entrada, a versão testada e o comportamento observado. Classifique a causa provável antes de alterar a configuração: instrução, fonte, parâmetro, execução de ferramenta ou condição de áudio. Faça a mudança correspondente e repita o caso. Depois repita um caso próximo que já passava, para verificar se a correção não deslocou o problema.

O conjunto de regressão deve preservar situações que já causaram erro e comportamentos essenciais do serviço. Ele não precisa crescer com cada frase diferente; mantenha casos que representem uma decisão distinta. Uma coleção menor, com critérios claros, pode ser mais útil do que muitas perguntas sem avaliação consistente.

Antes de publicar, combine os resultados com uma revisão de operação. O destino de transferência atende? As credenciais de produção foram configuradas pelo responsável? A equipe sabe identificar uma solicitação pendente? Testes de conversa não substituem essas verificações, mas devem revelar quando o resultado depende delas.

Documente o que ainda não foi validado. Se todos os ensaios aconteceram por texto, não declare qualidade de reconhecimento de fala. Se só houve consulta, não declare capacidade de escrita. Um relatório de teste preciso permite ampliar o piloto com uma expectativa realista e transforma cada nova condição em uma verificação concreta.