CRM fragmentado trava IA agêntica, mostra índice da ServiceNow

A promessa da IA agêntica em CX é agir, não só responder. Mas um conteúdo patrocinado pela ServiceNow publicado na Customer Experience Dive em 5 de outubro de 2026 traz um número que deveria preocupar qualquer time de RevOps antes de aprovar o próximo contrato de IA: apenas 9% das empresas fizeram progresso significativo com IA agêntica para fluxos autônomos de múltiplas etapas, segundo o AI Maturity Index da própria ServiceNow.

O motivo apontado pela fonte não é falta de modelo bom. É que a maioria das empresas está tentando colar agentes em cima de um CRM que nunca foi desenhado para orquestrar trabalho entre áreas. Ele foi construído para registrar interação com cliente, não para disparar e acompanhar um processo que atravessa financeiro, fulfillment e atendimento de campo. Isso é exatamente o problema que RevOps resolve todo dia manualmente, só que agora a IA também tropeça nele.

O CRM foi feito pra registrar, não pra orquestrar

A fonte explica que camadas de copiloto, chat e agente conversacional mudam a interface (o cliente ou o vendedor agora falam em linguagem natural em vez de preencher formulário), mas isso não resolve o problema de execução. Uma IA pode manter uma conversa convincente sem conseguir concluir a ação por trás dela, porque a ação depende de sistemas que o CRM nunca integrou de forma confiável.

O dado que sustenta isso: só 16% das organizações substituíram amplamente seus sistemas legados fragmentados por uma plataforma mais integrada, segundo o mesmo índice da ServiceNow. Isso quer dizer que, na imensa maioria das empresas, o CRM convive com anos de integração ponto a ponto e código customizado que ninguém documentou direito. É dívida técnica disfarçada de personalização.

O exemplo que todo RevOps já viveu

A fonte descreve um caso que soa familiar: um assistente de voz para cliente impressiona na demonstração, mas na produção não entende como o negócio funciona de verdade. Assim que a solicitação sai do CRM e chega em faturamento ou fulfillment, o agente transfere para um atendente humano. O trabalho continua indo parar no contact center, só que agora o cliente passou primeiro por um chatbot frustrante.

Para quem desenha playbook e onboarding, esse é o retrato exato do que acontece quando o fluxo de ponta a ponta nunca foi mapeado. Não é falha de IA: é falha de processo que a IA só deixou visível mais rápido. Antes, um atendente humano cobria a lacuna sem ninguém perceber que ela existia.

O mapa que precisa existir antes do agente

A fonte propõe uma sequência que, na prática, é trabalho de RevOps antes de ser trabalho de engenharia de IA:

1. Definir o resultado de negócio desejado (reembolso concluído, troca de plano efetivada, garantia aprovada).
2. Mapear o fluxo inteiro, do pedido até a resolução, atravessando CRM, ERP e qualquer outro sistema envolvido.
3. Documentar qual contexto de cliente, qual política e quais guardrails de segurança são necessários para cumprir esse fluxo.
4. Só então tratar a camada técnica: unificar dados e contexto, conectar os sistemas e implementar a governança.

Essa ordem importa porque inverte o erro mais comum: comprar o agente primeiro e descobrir depois que o fluxo que ele deveria executar nunca foi desenhado. RevOps que já mantém mapas de processo de vendas e CS tem vantagem real aqui, porque esse exercício de mapeamento é o mesmo que já faz para forecast e para handoff entre funções.

Quem é dono de quê

A fonte não detalha papéis internos, mas o recorte de RevOps exige essa divisão explícita, porque fundação de dados sem dono vira responsabilidade de todo mundo e de ninguém.

Sem essa divisão, o time de CS costuma ser o primeiro a sentir o estrago: um agente que não enxerga o histórico de ticket ou o status de contrato oferece uma solução genérica, erra a promessa feita ao cliente e gera o tipo de atrito que aparece depois como queda na receita líquida retida do trimestre.

Como medir se a fundação está pronta

Não adianta perguntar "a IA está funcionando" sem métrica. Antes de expandir o uso de agentes, RevOps consegue testar a fundação com perguntas objetivas:

• O agente consegue identificar, sem intervenção humana, o que o cliente possui e a que tem direito hoje?
• Quantos handoffs manuais um pedido típico ainda percorre entre sistemas antes de ser resolvido?
• A taxa de resolução no primeiro contato por IA muda a projeção de churn do mês seguinte, ou só desloca o atrito para outro canal?
• O dado que alimenta o forecast de expansão vem de um só lugar, ou de múltiplas instâncias com formatos diferentes espalhadas entre sistemas como ERP e CRM, como a fonte descreve?

Em resumo: se a resposta para qualquer uma dessas perguntas for "depende de quem você pergunta na empresa", a fundação ainda não está pronta para suportar decisão autônoma de IA, por melhor que seja o modelo escolhido.

Quando não vale a pena mexer tudo de uma vez

A fonte é explícita num ponto que vale repetir para quem está sob pressão de orçamento: a correção não precisa ser rip-and-replace. Dá para começar pequeno, com um time, uma geografia ou um único caso de uso, como só o canal conversacional.

Isso muda o cálculo de ROI que RevOps apresenta para a diretoria: em vez de prometer autonomia total do CRM em um ano, o caminho mais honesto é escolher um fluxo de alto volume e baixa complexidade (por exemplo, atualização cadastral ou segunda via de fatura), provar que ele sai do início ao fim sem handoff manual, e só então estender a mesma arquitetura de dados para fluxos de renovação e expansão, onde o custo de um erro de contexto é muito mais caro.

O ponto cego mais comum, segundo a leitura que dá para fazer do material da ServiceNow, é tratar a adoção de IA como projeto de ferramenta quando ela é, na raiz, projeto de dado e de processo. Quem já convive com playbook mal documentado e CRM com campos duplicados sabe que esse problema não nasceu com a IA agêntica: ela só tornou o preço de ignorá-lo mais visível, e mais caro.