O agente de revisão de pedidos: automatizar a revisão de oportunidades assinadas entre o CRM e o ERP

Toda oportunidade assinada precisa ser revisada antes de virar pedido. Alguém do Order Management abre o registro, confere se os campos críticos estão completos e corretos, compara a data de assinatura do contrato com a data no sistema e só então fecha o negócio e empurra para o ERP. É um trabalho de consequência alta e julgamento baixo — e roda na velocidade do horário comercial de um time. Um agente de IA de revisão de pedidos faz a mesma revisão continuamente, aplica as mesmas verificações toda vez e escala para uma pessoa só quando alguma coisa realmente parece errada. Nos deployments que vemos, de 70% a 85% das oportunidades assinadas passam pela revisão sem toque humano, e o tempo até o pedido cai de horas ou dias para minutos. Abaixo: arquitetura, desenho das verificações no nível de campo, cobertura de CRM/ERP e manual de rollout.

Por que a revisão manual é o gargalo

O passo de revisão existe por bons motivos. Uma oportunidade assinada que chega ao ERP com data de início de contrato errada cria um problema de reconhecimento de receita. Uma entidade de faturamento errada cria uma nota que o cliente se recusa a pagar. Um SKU sem mapeamento cria um pedido de venda que falha ao salvar, às seis da tarde, no último dia do trimestre.

Então o controle está certo. O problema é a implementação, e ela falha de quatro formas previsíveis.

É serial e depende de pessoas. A capacidade de revisão é o número de pessoas multiplicado pelas horas de trabalho. Vendas não fecha negócio nessa agenda. Um negócio assinado na sexta às 19:00 numa região espera até segunda por um revisor de outra, e nada nesse atraso melhora a qualidade do dado.

O volume chega de forma desigual. Times de Order Management são dimensionados entre o dia médio e o pior dia. No fim do trimestre a fila dispara e a qualidade da revisão cai justamente quando a precisão mais importa — as revisões que mais precisam de atenção recebem a menor.

A consistência se degrada com o cansaço. Um checklist de 25 campos em 40 oportunidades é uma tarefa em que humanos são mensuravelmente ruins. Os erros também não são aleatórios: eles se concentram nos campos que exigem cruzar outro sistema, porque é essa a verificação que as pessoas pulam quando estão atrasadas.

Os dados de erro nunca são capturados. Quando um revisor corrige um número de pedido de compra ausente, a correção é feita e o sinal se perde. Ninguém aprende que as oportunidades de um time específico vêm sem número de pedido 30% das vezes. O processo corrige registros individuais, mas nunca corrige a si mesmo.

Um agente resolve os quatro, e o quarto é o que compõe.

O que o agente faz

Cinco estágios, orientados a eventos, rodando sempre que uma oportunidade entra no estágio de assinada pendente de processamento.

A propriedade de desenho importante é que o estágio 5 tem exatamente duas saídas. Não existe um terceiro caminho em que o agente decide que um achado provavelmente não é nada. Tudo o que ele não consegue resolver vira problema de uma pessoa, com a evidência anexada.

Por que extrair para um warehouse em vez de revisar no lugar

Revisar direto contra a API do CRM é mais simples de construir e pior de operar. Extrair primeiro os campos críticos para o Snowflake compra três coisas.

Você ganha um registro de auditoria. Para qualquer pedido, dá para mostrar os valores exatos que o agente viu, as verificações que rodou e o que concluiu — que é o que um auditor pede quando um controle automatizado fica no caminho da receita.

Você ganha reprodutibilidade. Quando uma regra muda, dá para reexecutar o novo conjunto contra os últimos seis meses de snapshots e ver o que teria pego ou marcado errado, antes de tocar em produção.

Você ganha os dados de erro que o processo manual jogava fora. Os achados caem numa tabela. Quais campos falham, em quais times, em quais formatos de negócio, com qual tendência — isso vira uma conversa mensal sobre consertar a entrada, em vez de um imposto permanente sobre o time de revisão.

Data do contrato contra data do sistema

Essa é a verificação que mais vale construir com cuidado, porque é a que humanos fazem com menos confiabilidade e a que tem a maior consequência a jusante.

O agente lê o contrato executado, extrai a data de execução e compara com a data de fechamento e a de início de contrato na oportunidade. Quatro resultados importam: as datas concordam; o contrato é anterior à data do sistema (entrada tardia, e o período de fechamento pode estar errado); o contrato é posterior (o registro foi fechado antes da assinatura, o que é um problema de controle); ou não há data de assinatura legível.

Só o primeiro segue automaticamente. Os outros três são exatamente os casos em que um revisor cansado aceita o valor do CRM porque está ali na tela e abrir o PDF custa mais trinta segundos.

O que "completo e correto" realmente significa

"Revisar todos os campos críticos" não é uma especificação. Na prática o conjunto de verificações se divide em seis tipos, e a distinção importa porque só dois justificam um modelo de linguagem.

Presença. Campos obrigatórios preenchidos, condicionados ao formato do negócio — uma assinatura plurianual exige campos que um serviço pontual não exige.

Formato e tipo. Códigos de moeda, identificadores fiscais, datas, listas de valores com valores válidos em vez de texto livre que um vendedor digitou.

Consistência entre campos. A duração do contrato batendo com as datas de início e fim. O preço líquido reconciliando com o de tabela e o desconto. A frequência de faturamento compatível com o prazo. O total da oportunidade coincidindo com a soma dos itens de linha.

Integridade referencial entre sistemas. Cada SKU resolvendo para um item ativo no cadastro do ERP. A conta resolvendo para um cliente do ERP com a subsidiária e a moeda corretas. Essa é a categoria que humanos pulam, e é a que faz as escritas no ERP falharem.

Temporal. Data de assinatura contra data do sistema, data de fechamento dentro de um período aberto, data de início não anterior à assinatura, datas de renovação alinhadas ao prazo anterior.

Política. Desconto dentro da faixa aprovada para aquele tamanho de negócio, condições de pagamento do conjunto aprovado, cláusulas fora do padrão com a aprovação jurídica que exigem.

As cinco primeiras são determinísticas. Construa como regras, não como prompts — são mais baratas, mais rápidas e não variam entre execuções. O modelo ganha o lugar dele nos dois trabalhos genuinamente difíceis: ler o documento executado para extrair datas, signatários, nomes de entidade e linguagem de prazo e reconciliá-los com os campos estruturados; e triar os achados num escalonamento sobre o qual uma pessoa consiga agir numa leitura, em vez de uma lista crua de trinta violações de regra.

Um agente que manda "12 verificações falharam" moveu o trabalho, não removeu. Um agente que manda "a entidade de faturamento no contrato é a subsidiária alemã mas a oportunidade aponta para a britânica — moeda e tratamento fiscal são ambos afetados" fez o raciocínio do revisor por ele.

O que o agente não deve fechar automaticamente

Limites honestos, e são configuráveis por organização. Negócios acima de um limite de ACV. Primeiros pedidos de uma entidade legal nova. Linguagem contratual fora do padrão. Estruturas multimoeda ou multissubsidiária. Qualquer coisa em que a confiança de extração do modelo sobre o documento seja baixa. Negócios atribuídos a revenda ou parceiro com implicações de divisão de receita.

Esses vão para uma pessoa por política, não porque uma verificação falhou. A maioria dos times começa com essa lista longa e a encurta conforme os dados de achados justifiquem.

Human-in-the-loop: desenhar o escalonamento

O escalonamento no Slack é uma superfície de produto, não uma linha de log. Quatro coisas fazem a diferença entre um canal que as pessoas trabalham e um canal que as pessoas silenciam.

Uma thread por oportunidade, com os achados, a evidência e um link direto para o registro. Achados ordenados para que o bloqueante apareça primeiro. Resolução capturada na thread e escrita de volta na tabela de revisão, para que o histórico de achados do agente fique completo. E uma regra de roteamento para que achados de preço cheguem ao deal desk em vez de a todo mundo.

A métrica a acompanhar não é quantos escalonamentos você recebe. É que proporção de escalonamentos acaba sendo um achado real. Abaixo de uns 70%, os revisores começam a limpar o canal por reflexo, e você reconstruiu o problema original com passos a mais.

Onde ele roda

Construímos esse padrão sobre uma plataforma de integração da qual a Atypical Tech é parceira, em vez de como serviço isolado, e a razão é que quatro dos cinco estágios são problemas de integração, não de IA.

A plataforma fornece a assinatura de eventos de mudança do CRM, então o estágio 1 é configuração em vez de um worker de polling que alguém precisa manter. Fornece conectividade bidirecional com CRM e ERP com mapeamento no nível de campo, então o estágio 5 escreve no ERP por um conector mantido em vez de código de API sob medida que quebra na próxima atualização. Cuida da sincronização com o warehouse do estágio 2, então a tabela de revisão no Snowflake fica atual sem um segundo pipeline. E oferece retentativa, replay, tratamento de dead-letter e observabilidade sobre tudo isso — que é o que você realmente precisa às 03:00, quando um pedido precisa ser criado e o ERP está em janela de manutenção.

Isso deixa o agente em si como a parte que vale construir: o conjunto de regras, o raciocínio sobre o documento, a lógica de escalonamento. Nos deployments que fizemos, isso é aproximadamente a diferença entre uma entrega de seis a oito semanas e um projeto de dois trimestres e — mais ao ponto — entre algo que o time do cliente consegue manter e algo que só o autor original entende.

Cobertura de CRM e ERP

O padrão não é preso a um stack. As duas pontas diferem sobretudo em como o gatilho é capturado e como o objeto de pedido é modelado.

Lado CRM — gatilho de oportunidade

Lado ERP — criação do pedido

O Odoo aparece com frequência suficiente no middle market da EMEA para valer ser citado como sexta opção; o padrão se mapeia ao objeto de pedido de venda dele sem dificuldade.

A conclusão é que a lógica de verificação é portável e o mapeamento de campos não é. Orce o trabalho de mapeamento com honestidade — é a parte que leva tempo real, e é a parte que determina se as verificações de integridade entre sistemas funcionam de fato.

Framework de decisão — cinco perguntas em ordem

Aplique ao seu processo real. Pare na primeira correspondência.

1. Os seus critérios de revisão estão escritos em algum lugar? Se não, comece por aí. Um agente automatiza uma especificação; ele não consegue inferir uma a partir de como três revisores trabalham. Uma semana documentando o conjunto de verificações é a semana de maior retorno do projeto.
2. O seu volume de revisão passa de umas 100 oportunidades assinadas por mês, ou trava pedidos fora do horário comercial? Abaixo disso, e sem lacuna de cobertura, conserte primeiro as regras de validação do CRM — mais barato, mais rápido, e elimina uma parte dos achados por completo. O argumento do agente é cobertura e consistência, e ambos precisam de volume ou de dispersão de fuso para compensar.
3. O agente consegue ler um contrato assinado, ou só os campos do CRM? A revisão só de campos vale construir e pega a maioria dos erros de completude. Mas a verificação de contrato contra sistema é onde vivem os maiores erros a jusante, então se o documento executado não estiver confiavelmente anexado à oportunidade, conserte isso primeiro.
4. Você já tem integração CRM–ERP no lugar? Se sim, o agente é uma camada de revisão em cima de um caminho existente: o projeto mais curto. Se não, você está construindo a integração e o agente juntos, e a integração é a metade maior. Dimensione assim.
5. Alguém é responsável pelos dados de achados? O agente vai te dizer, em um mês, exatamente quais campos falham e de onde vêm. Se ninguém assume agir sobre isso, você automatizou um controle em vez de consertar um processo — vale fazer, mas é cerca de metade do retorno disponível.

Quanto custa e o que devolve

Faixas indicativas de deployments de middle market. Cada número se move com o volume, a complexidade do conjunto de verificações e quanta integração CRM–ERP já existe — peça uma estimativa com escopo em vez de orçar por esta tabela.

Duas coisas que vale dizer com clareza. Primeiro, o retorno que a maioria dos times realmente sente é tempo de ciclo e sobrevivência ao fim de trimestre, não uma linha de headcount reduzida — os revisores passam para tratamento de exceções e para a melhoria de processo que os dados de achados agora tornam possível. Segundo, a taxa de aprovação automática é consequência da sua qualidade de dado, não do agente. Times que partem de higiene ruim no CRM veem 50–60% no primeiro mês, e o número sobe conforme os dados de achados dirigem correções a montante. Essa subida é a entrega real.

Rollout: modo shadow primeiro

A mesma disciplina de execução em paralelo que recomendamos para migrações de sincronização se aplica aqui, pelo mesmo motivo: você quer evidência antes de dar a um controle automatizado o caminho de escrita.

Rode o agente em somente leitura por 14 a 30 dias. Ele revisa cada oportunidade assinada, escreve o veredicto e os achados na tabela de revisão e não toma nenhuma ação. Os humanos continuam revisando normalmente.

Depois compare. Onde o agente aprovou e o humano não achou nada, essa é a sua população de aprovação automática. Onde o agente marcou e o humano não achou nada, essa é a sua taxa de falsos positivos — ajuste as regras até ela ser defensável. Onde o agente aprovou e o humano achou um erro real, essa é uma verificação faltando, e cada uma é uma regra a adicionar antes do go-live. Nada vira automático até a última categoria ficar vazia por um período sustentado.

Depois habilite a ação automática em fases: primeiro os formatos de negócio de maior confiança, condições padrão e ACV pequeno; então amplie o envelope conforme os dados sustentarem. Mantenha o caminho de escalonamento inalterado o tempo todo, e mantenha uma regra de que qualquer execução que o agente não consiga completar escala em vez de assumir um padrão.

Perguntas frequentes

O agente substitui o time de Order Management?
Não — ele muda no que eles passam o dia. Revisões simples se resolvem sem eles; eles cuidam de exceções, negócios fora do padrão e do trabalho de qualidade de dado a montante que os achados revelam. Times que tratam isso como exercício de headcount geralmente têm resultados piores que times que tratam como exercício de cobertura e qualidade, porque o segundo grupo de fato age sobre os achados.

O que acontece se o agente errar?
Projete para as duas direções. Um falso positivo custa uma revisão humana que aconteceria de qualquer jeito — barato. Um falso negativo empurra um pedido ruim para o ERP — caro, e é por isso que o modo shadow roda até essa categoria ficar vazia, por isso extrações de documento com baixa confiança escalam por política, e por isso toda ação automática é registrada com a evidência por trás, de modo que uma aprovação errada seja rastreável e corrigível.

Por que extrair para o Snowflake em vez de revisar o registro diretamente?
Trilha de auditoria, reprodutibilidade e analytics de achados. Dá para mostrar exatamente o que foi revisado e concluído para qualquer pedido, reexecutar regras novas contra snapshots históricos antes de implantá-las, e analisar quais campos falham e onde. Revisar no lugar não te dá nenhuma das três.

Precisamos de um agente de IA, ou regras de validação bastariam?
Em parte o segundo, e você deve construí-las primeiro — são mais baratas e determinísticas. O modelo é necessário para ler o contrato executado e reconciliá-lo com os campos estruturados, e para transformar uma lista crua de falhas de regra num escalonamento sobre o qual uma pessoa consiga agir numa leitura. Uma implementação bem-feita é sobretudo regras, com um modelo fazendo os dois trabalhos que as regras não conseguem.

Com quais combinações de CRM e ERP isso funciona?
Os cinco CRMs e cinco ERPs acima cobrem a maior parte do que vemos, e a lógica de verificação é portável entre todos. O que não é portável é o mapeamento de campos — em particular as verificações de integridade entre sistemas, que dependem de como o seu cadastro de itens e os seus registros de cliente estão estruturados. Assuma que o trabalho de mapeamento escala com o quanto o seu CRM é customizado.

Quanto tempo leva a implementação?
De seis a oito semanas é o típico onde a integração CRM–ERP já existe e os critérios de revisão estão documentados, incluindo a janela de modo shadow. Some bastante a isso se a integração estiver sendo construída ao mesmo tempo, ou se o conjunto de verificações precisar ser reconstruído a partir de como o time atual trabalha.

Ele roda junto com o nosso iPaaS atual?
Sim, e esse é o formato usual. O agente precisa do gatilho de evento, da escrita no warehouse e do caminho de escrita no ERP; onde uma plataforma existente já fornece algum deles, ele usa. Construir a camada de revisão sobre a plataforma de integração te dá retentativa, replay e observabilidade de graça, o que importa mais para os pedidos fora do horário que eram o motivo do exercício.

O que a revisão 24 horas muda de fato?
Uma oportunidade assinada fora do horário comercial vira pedido em minutos em vez de no começo do próximo dia útil. Na prática o efeito é maior entre fusos e no fim de período, onde a fila que se formava nos dois últimos dias do trimestre em boa parte deixa de se formar.

Com que rapidez pode ser construída a ligação CRM-ERP de que este agente depende?
Mais rápido do que a maioria das equipas espera — um parceiro certificado como Stacksync pode ter a sincronização bidirecional em tempo real entre o CRM e o ERP a funcionar em semanas. O que demora mais é exatamente aquilo que este artigo aborda: desenhar as regras de revisão e a lógica de escalonamento antes de ligar o agente a dados em direto que mudam rapidamente.

Fechamento — Próximos passos

Se a revisão de oportunidades assinadas é uma fila e não um passo do seu processo, a ordem de trabalho é: documentar o conjunto de verificações, confirmar que o contrato executado está confiavelmente anexado à oportunidade, e então rodar um agente em modo shadow por um mês e deixar os dados da comparação dizerem o que automatizar primeiro.

A Atypical Tech constrói esse padrão sobre uma plataforma de integração da qual somos parceiros, nas combinações de CRM e ERP acima. Se você quiser trabalhar o conjunto de verificações e o rollout contra o seu próprio stack, fale com a gente.

Sobre o autor

Bruno Galo — Fundador, Atypical Tech

Bruno Galo é o fundador da Atypical Tech, uma consultoria de NetSuite que atende clientes do middle market em toda a Ibéria. Ele é especialista em conectar sistemas de CRM e ERP para fluxos de order-to-cash sem fricção, construindo pipelines automatizados de gestão de pedidos que eliminam a entrada manual de dados entre os times de vendas e finanças. Como parceiro oficial de implementação da Stacksync, Bruno projeta e implanta agentes de IA sobre plataformas de integração para tratar roteamento de exceções, processamento de documentos e conciliação — transformando fluxos de pedidos fragmentados em sistemas confiáveis que se monitoram sozinhos.

LinkedIn

Fontes

Eventos de mudança do CRM

• Salesforce Developers — Change Data Capture: https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm
• Salesforce Developers — Pub/Sub API: https://developer.salesforce.com/docs/platform/pub-sub-api/overview
• HubSpot Developers — Webhooks: https://developers.hubspot.com/docs/guides/api/app-management/webhooks
• Microsoft Learn — Use change tracking to synchronize data with external systems (Dataverse): https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-change-tracking-synchronize-data-external-systems
• Zoho CRM — Webhooks in workflow rules: https://help.zoho.com/portal/en/kb/crm/automate-business-processes/actions/articles/webhooks-workflow
• Pipedrive Developers — Webhooks: https://developers.pipedrive.com/docs/api/v1/Webhooks
• Stacksync — plataforma de sincronização CRM-ERP em tempo real: https://www.stacksync.com/blog

Pedidos de entrada no ERP

• NetSuite, Oracle Help Center — Sales Order: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_159665260887.html
• SAP Business Accelerator Hub — Sales Order (A2X) OData API: https://api.sap.com/api/API_SALES_ORDER_SRV/overview
• Microsoft Learn — Data entities (Dynamics 365 Finance and Operations): https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities
• Oracle Fusion Cloud SCM — Sales Orders for Order Hub REST endpoints: https://docs.oracle.com/en/cloud/saas/supply-chain-and-manufacturing/26a/fasrp/api-order-management-sales-orders-order-hub.html
• Sage Intacct Developer — Order Entry API: https://developer.intacct.com/api/order-entry/

Reconhecimento de receita

• IFRS Foundation — IFRS 15 Revenue from Contracts with Customers: https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/
• FASB — ASC 606, Revenue from Contracts with Customers, o equivalente em US GAAP da IFRS 15, na FASB Accounting Standards Codification.