Primeiramente, reduza o POC (Proof of Concept) para uma tarefa de negócios específica e mensurável.
As tarefas que devem ser selecionadas devem ter regras claras, volume de comunicação previsível, resultados que podem ser verificados posteriormente e que podem ser corrigidas em caso de erros. Por exemplo, criar um pedido de serviço após coletar informações de reparo é mais adequado do que "resolver todos os problemas de atendimento ao cliente". Antes de iniciar, é importante definir claramente os pontos de entrada de atendimento, campos necessários, ações permitidas, ações proibidas, condições para transferência para atendimento humano e quem fornece a API da empresa e o ambiente de teste. Se não for possível definir limites, a validação se tornará apenas uma avaliação subjetiva.
Primeiramente, estabeleça os padrões para o processo manual, e então discuta como a IA pode melhorá-lo.
Sem um valor de referência, não é possível determinar se o POC (Processo de Onboarding) está melhorando. É importante registrar quem está responsável por cada tarefa, como o sucesso é definido, quais são os erros comuns, os tempos de espera, os dados que precisam ser reintroduzidos e como a intervenção manual é realizada. O valor de referência não precisa ser um KPI bonito; um pequeno conjunto de casos reais e confirmados é mais útil do que suposições feitas pela própria fornecedora. Ao comparar, é necessário usar as mesmas tarefas, condições de chegada semelhantes e uma definição de sucesso consistente.
Os casos de teste com o "teste de ouro" devem incluir caminhos para resultados normais, ambíguos e de falha.
Inicialmente, a equipe de negócios, o atendimento ao cliente e o responsável pelo sistema devem elaborar juntos as entradas, as perguntas esperadas, os campos necessários, as ações permitidas e o estado final. Em seguida, essas informações devem ser entregues ao sistema para testes repetidos. Os casos de teste não devem seguir um padrão rígido de frases, mas devem incluir variações na fala do usuário, dados ausentes, palavras com a mesma pronúncia, ruídos de fundo, silêncios, interrupções, tempo limite de API e a necessidade de interação humana. Além disso, ao lidar com nomes, endereços, valores monetários ou informações de identificação, é preciso verificar se a IA repete a confirmação, em vez de apenas comparar com o texto original.
Critérios mínimos de teste para um POC (Proof of Concept) de atendimento ao cliente por voz com IA| Contexto | O que observar | Resultados verificáveis |
|---|
| Concluído com sucesso | Campos obrigatórios, ordem de perguntas de acompanhamento e chamadas de ferramentas. | CRM/Solicitação/Status de atribuição e histórico de chamadas devem estar em concordância. |
| Informações imprecisas ou confusas. | Verificar novamente e substituir os valores antigos? | Mantenha apenas os dados de confirmação mais recentes, evitando a criação de novas ordens. |
| Mal-entendido verbal | Baixa autoestima, perguntas repetitivas e necessidade de intervenção humana. | O erro não foi registrado diretamente no sistema principal. |
| Erro de tempo limite ou rejeição da API | Resposta, tentativa novamente, pendente e idempotência | É importante não anunciar o sucesso prematuramente, pois isso pode dificultar o acompanhamento do estado final. |
| Requerimentos para pessoas físicas ou situações de alto risco | A rota de encaminhamento se conecta ao contexto. | Campos já preenchidos e com informações confirmadas, bem como problemas não resolvidos. |
Os indicadores devem estar relacionados às tarefas, e não apenas à taxa de acerto.
A precisão do reconhecimento de voz não garante o sucesso da tarefa. Erros em transcrições individuais podem não afetar o resultado. A avaliação deve considerar a conclusão da tarefa, a correção dos campos necessários, o sucesso na chamada de ferramentas, a ocorrência de mal-entendidos ou fallback, a transição planejada, a atualização inesperada, a desistência do usuário, o atraso na resposta e a quantidade de correção manual. Cada um desses aspectos deve ter uma base clara e fontes de dados, por exemplo, utilizando "chamada de teste dentro do intervalo" como critério, e cruzando informações de registros telefônicos, eventos do modelo, logs da API e o estado final do sistema corporativo.
Critérios de avaliação que abrangem desde a qualidade da interação até os resultados do sistema.| Indicador | Definição | Evitar erros de interpretação |
|---|
| Taxa de conclusão de tarefas | Porcentagem de chamadas que atendem aos critérios de abrangência e que resultam no estado final correto. | Não se pode considerar apenas a conclusão de uma conversa como a conclusão de uma tarefa. |
| Verificação da precisão dos campos obrigatórios | Campo verificado e correspondência com a resposta real | O valor médio não deve mascarar campos importantes como endereço e valor. |
| A ferramenta foi executada com sucesso. | A API funcionou com sucesso e não apresentou efeitos colaterais repetidos ou erros. | Atraso na comunicação online não pode ser automaticamente considerado um fracasso ou um sucesso. |
| Mal-entendidos e mecanismos de fallback | O sistema não consegue interpretar ou acessar a frequência de perguntas repetidas. | É importante distinguir entre questionamentos relevantes e discussões improdutivas. |
| Intervenção manual | Solicitação de transferência, atualização automática e solicitação do usuário. | A substituição de mão de obra não é sempre um fracasso, e deve ser analisada caso a caso. |
A altura da entrada deve ser definida de acordo com o custo do erro.
Não existe uma linha de corte única que se aplique a todos os sistemas de IA para atendimento telefônico. O custo de corrigir erros de horário e dados de pagamento é completamente diferente; mesmo em uma única tarefa, um erro de um único caractere no endereço pode ser mais grave do que uma linguagem inadequada. A abordagem é dividir os erros em três categorias: aqueles que podem ser automaticamente retentados, aqueles que exigem revisão manual e aqueles que não podem ser executados automaticamente. Em seguida, estabelecer um limite para cada categoria e designar responsáveis. Se o número de amostras for insuficiente, apenas podemos dizer que o POC ainda não identificou problemas específicos, e não podemos inferir que o ambiente de produção certamente atingirá os resultados desejados.
A inspeção final (POC) também deve incluir testes de falha para verificar se o sistema pode operar mesmo em condições de erro.
Durante o serviço em produção, é comum encontrar problemas como interrupção de conexão de rede, tempo de resposta excessivo, falhas na API corporativa, falta de vagas e manutenção do fornecedor. Durante o processo de teste (POC), é importante verificar quais tipos de falhas ocorrem, em que estado os dados ficam, quem recebe as notificações e se é possível tentar novamente de forma segura após a resolução. A interface do usuário e o painel de operações devem exibir claramente os erros de forma compreensível, sem mascarar as exceções, para que a equipe de suporte não acredite que o problema foi resolvido.
O GoGoCha pode ser usado como evidência estrutural, e não como dados de inspeção genéricos.
O GoGoCha disponibiliza estudos de caso que comprovam que a Falcon implementou soluções de inteligência artificial para atendimento telefônico, back-end de compartilhamento de tarefas, filas, notificações em tempo real e integração com sites, LINE e aplicativos, além do back-end. Os estudos de caso não apresentam métricas como taxa de reconhecimento, tempo médio de resposta, taxa de sucesso, economia de recursos humanos ou acordos de nível de serviço (SLA) para chamadas, portanto, esses dados não podem ser usados para estabelecer padrões para outras empresas. A nova prova de conceito ainda deve ser realizada utilizando o ambiente telefônico, a linguagem do público-alvo e os dados de tarefas da empresa em questão.
Quais são os entregáveis que devem ser produzidos antes de apresentar o POC (Produto Mínimo Viável) para a versão final?
Mantenha, no mínimo, os seguintes casos de teste com versões fixas, detalhes dos resultados, riscos não resolvidos, arquitetura do sistema, fluxo de dados, permissões, monitoramento, processos de intervenção manual e recuperação. A versão final também deve incluir testes de pico de utilização, sistema PBX/SIP real, redundância, políticas de gravação e permissões de operação. O POC (Proof of Concept) indica apenas que o projeto é promissor, mas não implica que ele possa ser implementado diretamente sem adaptações.
