Triagem com agentes: o funil inteiro operado por IA, a decisão por gente

A maioria das empresas que tentam IA atendimento ao cliente instala um chatbot na frente de uma planilha. O bot responde as perguntas que já estavam no FAQ, transfere todo o resto para a fila humana e o volume do time não muda. Isso não é automação: é uma tela de carregamento com voz sintetizada. A diferença entre essa solução e um sistema real de triagem com agentes está na arquitetura, não na tecnologia. E entender essa diferença é o que separa um projeto que vai para produção de um piloto que fica em apresentação de PowerPoint para sempre.

O problema real não é o volume de tickets, é o custo do julgamento repetido

Atendimento não é caro porque recebe muita mensagem. É caro porque cada mensagem exige que alguém leia, classifique, decida o caminho certo e então execute. A maior parte desse trabalho é repetível, previsível e não exige julgamento real. O que exige julgamento é a minoria, mas essa minoria fica enterrada no mesmo fluxo que as perguntas triviais. O resultado: analistas com formação real passam horas respondendo 'qual o prazo de entrega' enquanto o cliente com um problema de faturamento espera na mesma fila. Não é um problema de capacidade. É um problema de alocação. A pergunta correta não é 'como atender mais rápido', mas 'quais partes desse trabalho não precisam de um ser humano presente para acontecer'.

O que diferencia um agente de um chatbot de verdade

Um chatbot segue um fluxo. Se a pergunta não cabe no fluxo, ele transfere. Um agente executa: consulta o ERP, verifica o histórico do cliente, cruza com a política de atendimento, rascunha a resposta, avalia a confiança na resolução e decide se resolve ou escala. A diferença não é de linguagem natural. É de capacidade operacional. O agente não apenas responde, ele age sobre sistemas reais. Isso muda radicalmente o que pode ser resolvido sem intervenção humana. Um agente com acesso ao sistema de pedidos pode confirmar status, identificar atraso, consultar a política de compensação aplicável ao caso e rascunhar a comunicação com o cliente, tudo antes de qualquer humano ver o ticket.

Um agente que só conversa é um chatbot com vocabulário mais rico. A diferença está em quantos sistemas ele consegue tocar e quantas decisões ele consegue concluir sem transferir.

Como o funil de triagem com agentes funciona na prática

O funil começa com um agente de classificação. Ele lê a mensagem recebida, extrai intenção, urgência e contexto do histórico, e decide o roteamento: resolução automática, rascunho para aprovação humana ou escalonamento direto com briefing já preparado. Não existe 'fila geral'. Cada item sai com uma categoria, um grau de confiança e uma recomendação de ação. O segundo nível são agentes especializados por domínio: um para dúvidas de cobrança, um para status de pedido, um para reclamações com potencial de churn, um para questões que tocam sistemas como Protheus ou outros ERPs legados. Cada agente tem acesso definido aos sistemas e às políticas relevantes para seu domínio. O terceiro nível é humano. Mas o humano não recebe um ticket em branco. Recebe um briefing estruturado: o que o cliente disse, o que o sistema mostrou, o que o agente tentou, qual a recomendação. A decisão é humana. A instrução operacional é automática. Isso muda a natureza do trabalho de forma completa.

Onde a pessoa precisa estar: não é supervisão, é julgamento específico

O design errado coloca a pessoa para 'supervisionar' os agentes. Isso recria o problema original: humano na fila de tudo, agora revisando em vez de resolver, com a ilusão de que a IA ajudou porque a interface mudou. O design certo mapeia os pontos onde julgamento é insubstituível. Exceções com precedente legal. Clientes estratégicos com histórico complexo e relacionamento que tem valor além do ticket. Situações onde a política da empresa é ambígua e uma decisão vai criar um precedente para todos os casos seguintes. Nesses pontos, o agente para, resume o caso com toda a informação relevante e espera. A pessoa não está no fluxo contínuo. Ela está nos nós de decisão. É uma diferença de posição que muda o trabalho inteiro e, consequentemente, o perfil de quem faz sentido contratar e desenvolver para esse time.

A pessoa não deve estar no loop de tudo. Deve estar exatamente nos pontos onde errar tem consequência real e onde o contexto humano ainda não tem substituto.

Por que a maioria dos projetos de IA em atendimento não chega à produção

Levantamentos da McKinsey e da Deloitte indicam que a maioria dos pilotos de inteligência artificial não chega à produção. No atendimento, o padrão de falha é quase sempre o mesmo: a empresa testa a IA num ambiente controlado, com dados limpos e casos simples, e valida o piloto com sucesso. Quando expõe ao volume real, os casos de borda aparecem. O modelo erra em situações que não estavam no conjunto de teste. A equipe perde confiança no sistema. O projeto é 'pausado para revisão' e nunca volta. O problema central não é a qualidade do modelo. É que o piloto foi desenhado para validar a tecnologia, não para validar o sistema em condições reais. Um sistema de agentes em produção precisa ter monitoramento de confiança por categoria de caso, mecanismo de escalonamento automático quando a incerteza supera um limiar definido e capacidade de aprender com os casos onde o humano corrigiu o agente. Sem essas três peças, qualquer piloto vai esbarrar no mesmo muro independentemente de qual modelo esteja por baixo.

Integração com sistemas legados: o nó que derruba projetos bem intencionados

O maior obstáculo técnico não é o modelo de linguagem. É a integração com os sistemas onde os dados realmente vivem. CRM com API mal documentada e endpoints que mudam sem aviso. ERP legado como Protheus, com lógica de negócio embutida em regras que ninguém documentou porque 'sempre funcionou assim'. Planilhas que são a fonte da verdade de um processo crítico porque o sistema oficial nunca foi confiável o suficiente para assumir esse papel. Um sistema de agentes que não consegue ler o histórico real do cliente ou verificar o status real do pedido vai inventar respostas plausíveis com dados desatualizados. E um agente que inventa é operacionalmente pior que nenhum agente, porque cria uma confiança falsa que vai falhar exatamente no caso mais sensível. A abordagem que funciona começa pelo mapeamento dos sistemas de registro antes de escrever o primeiro agente. Cada agente recebe acesso definido, auditável e restrito ao que precisa para operar. Não é integração genérica com tudo: é contrato de acesso por domínio, com fronteiras claras entre o que o agente pode consultar e o que pode modificar.

O que ganho operacional real significa nesse contexto

Em um projeto de compras numa operação de mineração, a nossa equipe reduziu o tempo de processamento por pedido de 30 para 5 minutos e chegou a zero erros de lançamento no ERP. A mesma equipe passou a operar seis vezes mais volume sem aumento de headcount. Não pela substituição de pessoas, mas pela eliminação do trabalho que não exigia a presença delas. No atendimento ao cliente, a lógica é análoga. O ganho não está em 'atender mais rápido' como métrica de vaidade. Está em dois resultados concretos: primeiro, redirecionar o julgamento humano para onde ele gera resultado real, os casos que constroem ou destroem relacionamentos de valor. Segundo, tornar a operação escalável sem crescimento linear de time, o que muda a economia fundamental do atendimento conforme o negócio cresce.

Seis vezes mais volume com a mesma equipe não é mágica. É a diferença entre usar gente para executar trabalho repetível e usar gente para tomar decisões que importam.

Como avaliar se a sua operação está pronta para reconstruir o atendimento

Três perguntas definem se o momento é agora. Primeiro: o seu fluxo de atendimento tem categorias de caso bem definidas, mesmo que não estejam documentadas? Se a equipe sabe instintivamente que 'esse tipo de problema vai para fulano', existe uma taxonomia implícita que um sistema de agentes pode aprender e formalizar. Segundo: você tem acesso programático aos sistemas onde os dados vivem? Não precisa de API perfeita, mas precisa de acesso real e auditável. Integração via scraping ou exportação manual de planilha não sustenta um sistema em produção. Terceiro: existe alguém com autoridade para definir onde o agente deve parar e escalar, e com disposição para manter essa definição atualizada ao longo do tempo? Sem esse papel, o sistema vai ou escalar tudo, recriando o problema original, ou resolver casos que não deveria, criando risco operacional. Se as três respostas são 'sim, mesmo que parcialmente', o projeto pode começar com um piloto em domínio restrito. Se alguma é 'não sei', começa pelo diagnóstico de operação, não pelo agente. Construir o agente antes de entender o sistema é o caminho mais rápido para o piloto que fica em apresentação.

Quer ler a sua operação a fundo?