Quando a digitação do pedido começa a pesar, três caminhos aparecem na mesma conversa: um portal B2B para o cliente comprar sozinho, EDI para o sistema dele falar com o seu, ou um agente de IA que lê o pedido do jeito que ele já manda. Os três tiram pedido da mão de quem digita, mas cada um pede uma coisa do cliente, serve a uma fatia da base e tem um custo com outra forma. Dos seis caminhos para tirar a digitação do time, estes são os três que decidem quem muda: o cliente, os dois sistemas ou você. Este artigo compara os três por esse critério e termina com a tabela de decisão por tipo de cliente.
O que é portal B2B, o que é EDI e o que faz o agente de IA?
Portal B2B é um site seu em que o cliente entra, vê o catálogo com o preço dele e faz o pedido. EDI é a troca de arquivos entre o sistema do cliente e o seu, num layout combinado, sem digitação. Agente de IA é o programa que lê o pedido como o cliente mandou e o lança no ERP; uma pessoa decide a exceção.
| Portal B2B | EDI | Agente de IA no ERP | |
|---|---|---|---|
| Quem digita o pedido | o cliente, no seu portal | ninguém: sai do sistema do cliente e entra no seu | ninguém: o agente lê o que o cliente mandou |
| O que o cliente precisa fazer | mudar o jeito de comprar: entrar com usuário e senha e montar o pedido | ter sistema e TI, e entrar num projeto de integração com você | nada; continua mandando PDF, planilha, e-mail ou WhatsApp |
| O que você precisa ter | o portal, integrado ao ERP, com catálogo e preço por cliente em dia | módulo ou operadora de EDI, layout combinado por cliente, homologação | cadastro em ordem e o caminho de pedido do ERP liberado |
| Para quem funciona melhor | cliente médio ou grande, recorrente, que compra do catálogo e não tem ERP emitindo a ordem de compra | cliente grande, com TI, que exige ou aceita integração | todo cliente que não vai mudar: o pequeno, o eventual, o que vem pelo representante e o grande que manda a ordem de compra em PDF |
Nenhum dos três é "o certo". A maioria das empresas que vende para outras empresas acaba com dois deles, e às vezes com os três, cada um cobrindo uma fatia da base de clientes.
Qual é a diferença de fundo entre os três?
A diferença está em quem se adapta a quem. No portal, o cliente se adapta a você. No EDI, os dois sistemas se adaptam a um layout combinado, num projeto por cliente. No agente, você se adapta ao cliente: ele manda como sempre mandou e o trabalho de entender fica do seu lado, feito por software.
Esse critério explica a maior parte do que dá certo e errado em cada caminho. Portal e EDI entregam o pedido já estruturado, no formato do ERP, e por isso são os caminhos mais limpos quando o cliente adere. O problema é a adesão: ela depende do cliente, e o cliente que mais digita hoje é o que menos quer mudar. O agente resolve a adesão porque não pede nada ao cliente, e paga por isso com a leitura: o pedido chega bagunçado, e alguém, ou algo, precisa interpretar.
A conta que vale fazer antes de escolher é a da base de clientes, não a da tecnologia. Quantos clientes exigem ou aceitam EDI? Quantos entrariam num portal, de verdade, pedido após pedido? E quantos vão continuar mandando o PDF do sistema deles, a planilha de sempre ou a lista pelo WhatsApp? Os seis canais por onde o pedido chega são a régua para essa conta.
Quando o portal B2B serve?
Quando você tem clientes médios e recorrentes que compram do catálogo, com frequência, e que ganham algo ao entrar: ver estoque, preço negociado, histórico, segunda via, status da entrega. O portal serve bem a esse cliente. Serve mal ao cliente grande com sistema próprio e ao pequeno que pede pelo WhatsApp.
| O portal B2B funciona quando | O portal B2B trava quando |
|---|---|
| o cliente compra do seu catálogo, com reposição regular | o cliente tem ERP próprio e a ordem de compra sai de lá, em PDF |
| o preço, o desconto e a condição de cada cliente estão certos no portal, iguais aos do ERP | o preço do portal diverge do que o vendedor combinou, e o cliente liga para o vendedor |
| há algo a mais para o cliente ver: estoque, histórico, boleto, rastreio | o portal é só um formulário de pedido; aí o cliente prefere mandar a lista |
| o vendedor ganha com a adesão do cliente, ou pelo menos não perde | o vendedor vê o portal como concorrente e não indica |
| a empresa tem quem cuide do catálogo, das fotos e do cadastro todo dia | o catálogo envelhece e o cliente para de confiar |
O portal tem um valor que os outros dois caminhos não têm: ele é vitrine e autoatendimento ao mesmo tempo. Quando a base tem esse cliente médio e recorrente, ele costuma ser um bom investimento, desde que integrado ao ERP pelo caminho oficial de pedido, com preço e estoque vindos de lá. A integração do portal com o ERP é o que decide se o pedido do portal entra sozinho ou vira mais uma fila para digitar.
O portal tira a digitação da fatia que aderir; para o resto da base, a conta da digitação de pedidos continua valendo.
Quando o EDI serve?
Quando o cliente é grande, tem TI e exige ou aceita integrar o sistema dele ao seu. No Brasil, isso é comum com grandes redes de varejo, indústria automotiva e grandes distribuidores: o pedido chega por EDI, e muitas vezes a nota e o aviso de embarque voltam por ali. Para esse cliente, EDI é condição de fornecimento.
Vale saber o que EDI envolve, porque o nome esconde um projeto:
- Um layout combinado por cliente. O padrão mais comum no varejo é o EDIFACT (as mensagens de pedido, aviso de embarque e fatura); a indústria automotiva tem padrões próprios do setor, e o ANSI X12 aparece em subsidiárias de empresas norte-americanas. Na prática, cada cliente grande tem o seu layout, com campos e códigos próprios, e a homologação (o teste em que a TI dele aprova a troca) é com ele.
- Uma operadora no meio, na maioria dos casos. Os arquivos trafegam por uma operadora de EDI, que cobra pela conexão e pelo volume de mensagens, ou por uma conexão direta combinada com o cliente.
- O lado do ERP. Os ERPs de porte costumam receber pedido por EDI, por módulo próprio ou por integração de terceiro; qual dos dois vale no seu sistema é o que se confere antes de prometer prazo ao cliente. O que esse caminho faz é traduzir o arquivo para o pedido de venda, e o código do item do cliente precisa estar casado com o seu no cadastro.
- Manutenção. Layout muda, o código do produto muda no cliente, a operadora muda o jeito de transmitir. Cada mudança é uma rodada com a TI do cliente.
Por isso o EDI compensa para os dois ou três clientes que concentram volume e já exigem o canal, e não compensa para o cliente médio ou pequeno, mesmo quando ele topa: o projeto por cliente custa o mesmo para quem manda poucos pedidos por mês. O prazo de cada ligação nova depende da homologação do lado do cliente, e é ele quem dita o ritmo.
Quando o agente de IA serve?
Quando o pedido vem de clientes que não vão mudar o jeito de comprar: o cliente grande que manda a ordem de compra em PDF gerada pelo ERP dele, o cliente médio que manda planilha, o pequeno que manda pelo WhatsApp, e o representante. É a fatia que portal e EDI não alcançam, e é nela que a digitação está.
O agente lê o pedido como chegou, casa cliente e itens com o cadastro do ERP, confere contra as regras comerciais e grava pelo caminho do sistema; o que foge do padrão espera uma pessoa. Uma pessoa aprova o que tem risco; o agente registra tudo o que faz. O passo a passo, as regras comerciais e o caminho em cada ERP (Protheus, SAP Business One, Sankhya, Senior, Omie, Bling) estão no guia da entrada de pedidos no ERP, e o caso do WhatsApp tem artigo próprio.
O que o agente exige está do seu lado, não do lado do cliente: cadastro de clientes e itens em ordem, tabela de preço por cliente no ERP e o caminho de pedido do sistema liberado. Sem cadastro, a fila de exceção cresce; sem API ou rotina de pedido, não há por onde gravar.
Foi para essa fatia que montamos o nosso ambiente de teste: uma distribuidora fictícia com 10 clientes e 50 pedidos, todos de canais que portal e EDI não cobrem (30 em PDF de três layouts, 10 em planilha e 10 por WhatsApp). Nenhum dos 10 clientes manda por portal ou EDI: o ambiente foi montado para a fatia que chega fora do formato, que é onde a digitação acontece.
Qual caminho para cada tipo de cliente?
A decisão é por perfil de cliente, não por empresa inteira. Olhe a base e divida em cinco grupos, pelo que cada cliente manda hoje e pelo que ele aceitaria mudar; cada grupo tem um caminho que resolve e um que não vale o esforço, e a mesma empresa costuma ter três ou quatro desses grupos.
| Perfil do cliente | O que ele manda hoje | O caminho que resolve | O que não vale o esforço |
|---|---|---|---|
| Grande, com TI, que exige integração | pedido por EDI, ou vai exigir | EDI, com o módulo do ERP e a operadora que ele usa | portal: ele não vai digitar no seu |
| Grande ou médio, com ERP próprio, sem exigência de EDI | ordem de compra em PDF, por e-mail | agente de IA lendo o PDF do sistema dele; integração direta entre os dois ERPs quando o volume dele justificar | EDI: o projeto não compensa; portal: ele não adere |
| Médio e recorrente, que compra do catálogo | planilha, e-mail, ligação para o vendedor | portal B2B para quem aderir; agente para o resto | esperar que todos adiram ao portal; agente para quem já compra sozinho no portal |
| Pequeno e eventual | WhatsApp, e-mail curto, foto | agente de IA, com o resumo de confirmação | portal e EDI: adesão perto de zero; o agente, sem o telefone e o cadastro desse cliente em ordem, só enche a fila |
| Representante ou vendedor externo | repassa o pedido do cliente no formato que recebeu | app de força de vendas (o do artigo sobre digitação) para o pedido que ele monta; agente para o que o cliente manda direto | obrigar o cliente a passar pelo representante |
Lida assim, a base vira uma pirâmide. No topo, poucos clientes grandes com EDI, um projeto para cada. No meio, os recorrentes que o portal consegue atrair, e os que não aderem ficam com o agente. Na base, o volume de pedidos pequenos e variados, que portal e EDI não alcançam. O que a tabela responde é a proporção entre os três, não qual deles.
O que pesa no custo de cada caminho?
Os três custam de jeitos diferentes. O portal custa por existir e por ser mantido. No EDI, a conta é por cliente ligado e por mensagem. O agente tem o mapeamento e o piloto no começo, e depois o uso. Vale comparar o custo por cada pedido que deixou de ser digitado.
| Portal B2B | EDI | Agente de IA no ERP | |
|---|---|---|---|
| Para começar | o portal (assinatura ou desenvolvimento) e a integração com o ERP | o módulo do ERP ou a operadora, e um projeto de homologação por cliente | o mapeamento do volume e do cadastro, e o piloto com clientes e canal definidos |
| Para manter | catálogo, preços e cadastro em dia; suporte ao cliente que não consegue logar | mensalidade da operadora, volume de mensagens, cada mudança de layout | o uso do agente e a pessoa que decide as exceções |
| O que encarece | adesão baixa: o custo fixo dividido por poucos pedidos | ligar cliente pequeno: o mesmo projeto para pouco volume | cadastro bagunçado: fila de exceção cheia |
| O que barateia | cliente recorrente que compra sozinho e ainda consulta estoque e boleto | clientes grandes que já exigem o canal: o projeto se paga no volume | começar pelo canal de maior volume e menor variação, em geral o PDF por e-mail |
Para a conta do agente em específico, o que entra e o que encarece sem necessidade está em quanto custa um agente de IA. Para os três, a régua é a mesma: quantos pedidos por mês deixam de ser digitados, e quanto custa cada um deles pelo caminho escolhido.
O que costuma dar errado na escolha?
Os erros mais comuns são tratar os três como concorrentes, lançar o portal sem plano de adesão, ligar EDI com cliente que não tem volume, medir o portal por cadastros em vez de pedidos, ligar o agente com o cadastro bagunçado e deixar o representante fora da conta. Todos são de decisão, não de tecnologia.
- Escolher um e descartar os outros. O portal não alcança o pequeno, o EDI não compensa para o médio, o agente não é o caminho mais limpo para quem já manda estruturado. Cada fatia da base tem o seu.
- Portal sem adesão planejada. Lançar e esperar: o cliente continua mandando a lista. Adesão se constrói cliente a cliente, com o vendedor junto e com um motivo para o cliente entrar.
- Medir o portal pelo cadastro. Cadastro não é uso. A medida é a fatia dos pedidos que entrou pelo portal no mês, por cliente.
- EDI com cliente sem volume. O projeto por cliente custa o mesmo para quem manda pouco. Para esse cliente, o agente lê o PDF que o ERP dele já gera.
- Preço do portal diferente do ERP. O cliente vê um preço, o vendedor combinou outro, o pedido vira ligação. Preço e condição vêm do ERP, pelo caminho oficial, ou o portal não se sustenta.
- Cadastro bagunçado em qualquer dos três. O portal mostra preço errado, o EDI não casa o código do item e o agente enche a fila de exceção, pelo mesmo motivo. O que arrumar antes está no guia.
- O mesmo pedido por dois caminhos. O cliente manda por EDI e por e-mail, ou pelo portal e pelo WhatsApp "para confirmar". Sem controle de duplicidade, entram dois.
- O representante fora da conta. Ele é o canal de boa parte da venda externa. Se o portal ou o agente o deixam de lado, ele volta a mandar a planilha por e-mail, e a digitação volta junto.
Por onde começar?
Comece pela base de clientes, não pela tecnologia: liste quem exige EDI, quem aderiria a um portal de verdade e quem nunca vai mudar, e conte os pedidos de cada grupo por mês. Com essa conta, a proporção entre os três caminhos aparece sozinha. Em três passos:
- Conte os pedidos por canal e por cliente, por uma semana (um mês, se os clientes grandes pedem com menos frequência): PDF por e-mail, planilha, WhatsApp, representante, portal, EDI. A conta de quanto isso custa hoje está no artigo sobre digitação de pedidos.
- Separe a base nos cinco perfis da tabela acima e marque, para cada cliente grande, se ele exige EDI ou se manda ordem de compra em PDF.
- Escolha o primeiro caminho pelo volume: se os dois ou três maiores clientes exigem EDI e ainda não têm, é por ali; se a maior parte dos pedidos vem em PDF, planilha e WhatsApp, é pelo agente; se há uma fatia recorrente que ganharia com autoatendimento, o portal entra depois, sobre o cadastro já arrumado.
Como o agente de pedido funciona, do mapeamento ao piloto, está na página do agente de pedido no ERP. A primeira conversa é esta: Diagnóstico de IA na operação em 30 minutos: qual decisão o seu time mais repete?
Perguntas frequentes
O que é EDI?
É a troca eletrônica de documentos entre o sistema do cliente e o seu, num layout combinado, sem digitação nos dois lados. No pedido, o cliente envia o pedido de compra por EDI e, muitas vezes, espera a nota e o aviso de embarque de volta pelo mesmo canal. No Brasil é comum com grandes redes de varejo, indústria automotiva e grandes distribuidores.
Portal B2B substitui o EDI?
Não. O cliente que exige EDI não vai digitar no seu portal; o portal serve ao cliente médio e recorrente que aceita comprar sozinho. Os dois convivem, cada um com a sua fatia da base.
O agente de IA substitui o portal B2B?
Não é a ideia. O agente cobre o cliente que não vai mudar o jeito de comprar; o portal atende o que ganha com autoatendimento, como consultar estoque, boleto e histórico. Em muitas empresas os dois convivem, e o agente cobre a fatia que não aderiu ao portal.
Preciso dos três?
Depende da base. Empresa que vende para grande varejo e também para o pequeno costuma precisar de EDI e de agente; empresa com base recorrente de médios pode somar o portal. Empresa cujos clientes mandam todos PDF e WhatsApp resolve com o agente. A tabela por perfil de cliente é a régua.
O cliente grande que manda ordem de compra em PDF precisa de EDI?
Não necessariamente. Se ele não exige EDI, o PDF que o ERP dele gera é regular e o agente lê, identificando os itens pela tabela que casa o código dele com o seu. O EDI vale quando o cliente exige ou quando o volume dele justifica o projeto.
O agente lê o pedido que vem do portal ou do EDI?
Não precisa. Esses pedidos já chegam estruturados, e o próprio ERP ou o módulo de EDI os lança. O agente entra nos canais em que o pedido chega fora do formato: PDF, planilha, e-mail e WhatsApp.
Em que ERP cada caminho entra?
Portal, EDI e agente entram pelo mesmo lugar: a API ou a rotina de pedido de venda do ERP, que aplica as validações do sistema. Nos ERPs de porte, como Protheus, SAP Business One, Sankhya e Senior, o EDI entra por módulo próprio ou por integração de terceiro, conforme o ambiente; Omie e Bling têm API pública e já integram o pedido de loja virtual e marketplace.
O cliente que usa EDI também pode mandar pedido por e-mail?
Pode, e acontece: o pedido vem por EDI e o comprador reenvia por e-mail "para garantir". Os dois canais precisam de um controle de duplicidade em comum, pelo número do pedido do cliente, senão entram dois. É um dos motivos para o EDI e a leitura de e-mail conversarem no mesmo lugar.
