Como fazer uma URA com IA que identifica o beneficiário e consulta o status da guia sem alucinar

O problema: a ligação chega antes do contexto

Em uma operadora de saúde, muitas ligações repetem os mesmos pedidos: a segunda via de um boleto, a situação de uma guia, uma autorização em andamento. Quando todas chegam direto ao atendente, a fila cresce e o beneficiário repete a mesma informação a cada transferência.

Colocar um modelo de linguagem na URA não resolve isso por si só. Um agente de voz que responde com fluência, mas sem ler o sistema, pode inventar um status plausível. Numa consulta de guia, esse erro chega ao beneficiário como se fosse informação oficial.

O desenho precisa partir de três perguntas: quem está ligando, qual sistema responde ao pedido e o que acontece quando a resposta não pode ser confirmada.

URA tradicional × URA conversacional com IA

Na URA tradicional, o beneficiário navega por um menu de opções e, para qualquer caso fora dele, espera um atendente. Na URA conversacional, ele diz o que precisa com as próprias palavras, e o agente reconhece o pedido e o direciona.

A diferença está na entrada da conversa. As regras da operação continuam as mesmas: quem pode consultar o quê, em qual sistema e com qual identificação. Uma URA conversacional sem integração só reconhece o pedido; ela não consegue concluí-lo. Por isso, compare os desenhos pelos fluxos que chegam ao fim com uma informação confirmada, não pela naturalidade da voz.

O que dá para automatizar com segurança na URA de uma operadora, e o que não

Bons candidatos são pedidos com começo e fim claros, uma fonte de dados definida e uma resposta que não depende de julgamento. Por exemplo: identificar o beneficiário com os dados que o fluxo exige, enviar a segunda via de um boleto, consultar e informar o status de uma guia ou autorização registrado no sistema, e reconhecer o pedido para direcioná-lo à fila adequada.

Decidir uma autorização assistencial fica fora do agente. Consultar o status de uma guia é diferente de autorizar um procedimento. A decisão continua com os responsáveis e os processos da operadora.

Diagnóstico, orientação clínica e atos clínicos ou regulatórios também ficam fora. O agente não avalia sintomas nem substitui a análise de um profissional.

Gerar ou inferir um status que não leu não é uma opção. Se a consulta não retorna uma informação confirmada, não há resposta a dar ao beneficiário. Há uma transferência a fazer.

Pedidos fora dos fluxos cobertos vão para a fila adequada. A ampliação para novos fluxos depende de novas integrações e de outro ciclo de validação.

Voz, URA ou chat: qual canal para qual pedido

O canal acompanha o hábito de quem procura a operação e o tipo de pedido. Antes de escolher, verifique por qual canal cada pedido chega hoje à sua operação. Quando a ligação é a porta de entrada para pedidos como status de guia e boleto, a URA é o lugar do primeiro fluxo.

Para escolher, avalie onde o pedido já chega hoje, se a resposta cabe em uma frase falada ou precisa de documento, link ou anexo, e como a transferência funciona em cada canal. As regras de identificação, consulta e transferência deste guia valem para todos os canais.

Identificação do beneficiário

A identificação vem antes da transação. O agente coleta e valida os dados que a operação exige para aquele fluxo e só então consulta ou envia algo.

Defina com a operação quais dados identificam o beneficiário em cada fluxo e onde eles são validados. Defina também o que acontece quando a validação não se completa, seja uma nova tentativa, o pedido de outro dado ou a transferência, e quais informações coletadas seguem com a ligação se uma pessoa precisar assumir.

Sem identificação confirmada, o agente não consulta nem informa dados do beneficiário. A ligação segue para o atendimento humano com o que já foi coletado.

Consulta de status via sistema-fonte (grounding)

O status que o beneficiário ouve deve ser o que o sistema-fonte devolveu pela API naquele atendimento. O modelo organiza a conversa e a resposta. A informação vem da consulta.

A transcrição da ligação mostra o que foi dito, mas não comprova que a consulta aconteceu. A evidência é o registro da chamada à API e do retorno do sistema-fonte.

Quando transferir para a equipe, e com qual contexto

Transfira quando a identificação não se completa, quando a consulta não confirma a informação, quando o pedido está fora dos fluxos cobertos e quando o beneficiário pede para falar com uma pessoa.

Transferir não é devolver a ligação ao início. O atendente recebe a identificação e as informações coletadas, e a ligação vai para a fila adequada ao pedido. O objetivo é reduzir transferências entre setores e evitar que o beneficiário repita o que já informou.

Combine com a equipe quais filas recebem cada tipo de pedido, quais informações aparecem para o atendente no momento da transferência e como registrar o motivo: identificação incompleta, consulta sem confirmação, pedido fora do escopo ou pedido do beneficiário. Essas definições têm um responsável pelo processo, que decide quando ajustar filas, motivos e recorte.

Uma transferência iniciada não confirma que o pedido foi resolvido. Registre também se a ligação chegou à fila e foi assumida. O exemplo interativo de voz e URA mostra um encaminhamento com confirmação da transferência, em cenário fictício.

Como medir sem inventar número

Defina a medida antes da implantação e compare condições equivalentes.

Mesmo recorte. Compare o tempo de atendimento dos fluxos automatizados com o mesmo tipo de pedido antes da mudança, e não com a média de todas as ligações.

Resolvido não é o mesmo que respondido. Conte como resolvida só a ligação que terminou com o pedido atendido e sem transferência. Mantenha à parte as consultas sem confirmação e as transferências.

Período e origem declarados. Todo número publicado precisa informar o período, os fluxos incluídos e quem mediu.

Sem referência, sem comparação. Quando não houver medida anterior, a primeira entrega é construir essa referência. Não use uma estimativa como resultado.

Onde os dados da ligação circulam

Uma ligação com identificação passa por telefonia, reconhecimento e síntese de voz, modelo, APIs da operadora, gravação e painéis. Para cada etapa, mapeie quais dados passam por ali, onde são processados e armazenados, quem tem acesso e por quanto tempo os dados são retidos.

Leve esse mapa ao encarregado da operadora antes do piloto. O guia sobre Shared SaaS e Dedicated mostra como registrar requisitos, rotas de dados e responsáveis em cada modalidade de implantação.

Evidências: Unicall / Sistema Unimed Paraná

A Júlia foi integrada à URA da Unicall, no Sistema Unimed Paraná. Ela identifica o beneficiário, envia a segunda via do boleto e consulta o status de guias e autorizações pelas APIs dos sistemas da operação. Quando necessário, transfere a ligação com contexto para a fila adequada.

Resultados reportados nos fluxos automatizados. O TMA passou de 8 minutos para 2 minutos, uma redução de 75% por chamada. No primeiro mês de operação, 12% das chamadas foram resolvidas integralmente pela IA.

Alcance dos números. São indicadores desta operação e dos fluxos automatizados descritos. Não valem como total das ligações da Unicall nem como garantia para outros contextos. A operação reúne uma base de 850 mil beneficiários e 18 singulares da Unimed integradas. O número de 850 mil descreve a base de beneficiários, não o total de pessoas atendidas pelo agente.

Cobertura na imprensa. A Gazeta do Povo noticiou a entrega do projeto em reportagem publicada em 28 de outubro de 2025. Os indicadores acima vêm do caso publicado pela Starya.

Perguntas frequentes

A IA pode informar o status de uma guia sem consultar o sistema? Não. O status informado deve ser o que o sistema-fonte devolveu pela API. Se a consulta não confirma a informação, o agente não responde com uma estimativa. Ele transfere a ligação com contexto.

Consultar o status de uma guia é o mesmo que autorizar um procedimento? Não. A consulta lê uma situação registrada. A decisão sobre uma autorização assistencial continua com os responsáveis da operadora e fica fora do escopo do agente.

O que acontece quando a API de consulta falha? O agente informa que não conseguiu confirmar e transfere a ligação para a fila adequada, com a identificação e as informações coletadas. O registro separa essa ocorrência de uma consulta concluída.

O que uma URA com IA pode automatizar em uma operadora de saúde? Pedidos com começo e fim claros e uma fonte de dados definida, como a identificação do beneficiário, a segunda via de boleto, a consulta de status de guia e o direcionamento para a fila certa. Decisões assistenciais, orientação clínica e atos regulatórios ficam com a equipe.

Quais resultados a Unicall reportou? Nos fluxos automatizados, o TMA passou de 8 para 2 minutos. No primeiro mês, 12% das chamadas foram resolvidas integralmente pela IA. São indicadores dessa operação e desses fluxos.

Por onde começar em outra operadora? Por um ou dois fluxos com começo e fim claros, como segunda via de boleto e status de guia. Para cada um, defina a identificação exigida, o sistema-fonte, a API e o destino da transferência.

Quando o caminho precisa mudar

Se o sistema-fonte ainda não oferece uma API para o pedido, comece pelo reconhecimento e pelo direcionamento para a fila certa, e deixe a consulta para depois da integração. Se a identificação exigida não pode ser validada pela URA, mantenha o fluxo com transferência logo após o reconhecimento do pedido. Se não houver medida anterior do tempo de atendimento, construa essa referência antes de comparar resultados.

Um ponto de atenção: avaliar a URA pela naturalidade da voz, sem conferir se o status informado veio do sistema-fonte.

O roteiro está pronto para avançar quando…

• Cada fluxo tem identificação exigida, sistema-fonte, API e destino de transferência definidos.
• O agente não informa um status que não leu no sistema-fonte, e isso foi testado com consultas que falham.
• O registro separa consulta concluída, consulta sem confirmação e transferência, com o motivo de cada transferência.
• Dados, acessos e retenção da ligação foram mapeados e levados ao encarregado da operadora.

Leve o mapa de fluxos para a equipe de atendimento e para os responsáveis pelos sistemas. Compare com o caso da Unicall e com o guia sobre passagem para a equipe antes de liberar o piloto.