Indústrias, distribuidores e atacadistas que resistiram à digitalização por anos estão sendo empurrados por um fator simples: o comprador do outro lado mudou. O profissional que faz o pedido de reposição hoje compra tudo o que é pessoal pelo celular, e não entende por que o pedido profissional dele ainda depende de uma planilha enviada por e-mail para um representante.
A reação natural é levar para o B2B a plataforma que funciona no varejo. É aí que a maior parte dos projetos fracassa, e o fracasso raramente é atribuído à causa certa.
Principais pontos do artigo
- E-commerce B2B não é varejo com login, é um modelo comercial diferente.
- Seis mecanismos que existem no B2B simplesmente não têm equivalente no B2C.
- O representante comercial não é obstáculo ao digital, é parte do desenho.
- A integração com o ERP deixa de ser acessória e passa a ser o núcleo do projeto.
- O Magento carrega esses conceitos nativamente, mas eles exigem modelagem, não configuração.
Os seis mecanismos que o varejo não tem
Preço por cliente. No varejo, o preço é do produto. No B2B, o preço é da relação entre produto e cliente. O mesmo item tem valores diferentes conforme contrato, histórico, volume acumulado e política comercial. Isso não é desconto, é tabela. Uma plataforma que trata preço como atributo do produto não modela isso sem gambiarra.
Catálogo por cliente. Nem todo cliente vê todo produto. Há exclusividade por região, por canal, por contrato. Há item que só existe para determinado perfil. A visibilidade do catálogo passa a depender de quem está autenticado, o que inverte a lógica de indexação e de cache do varejo.
Unidade de venda e múltiplo de embalagem. O produto é vendido por caixa, por fardo, por pallet, com múltiplo mínimo e conversão entre unidades. Um carrinho que aceita quantidade unitária livre gera pedido que o ERP não consegue faturar, e o problema aparece na expedição, não no checkout.
Representante comprando em nome do cliente. O vendedor precisa acessar a conta do cliente, montar o pedido, aplicar a política daquele cliente e submeter. Isso exige personificação controlada, com registro de quem fez o quê. Não é um recurso de conveniência, é requisito de auditoria comercial.
Hierarquia e aprovação. Na empresa compradora, quem monta o pedido frequentemente não é quem aprova. Existe alçada por valor, existe centro de custo, existe fluxo de aprovação. Sem isso, o pedido é montado no sistema e aprovado por fora, o que anula boa parte do ganho da digitalização.
Crédito, prazo e limite. A maior parte das vendas B2B não é paga no ato. Existe limite de crédito, condição de prazo negociada, título em aberto. O checkout precisa consultar essa posição no ERP em tempo real e bloquear ou liberar conforme a regra, o que transforma o fechamento do pedido em uma operação integrada, não local.
Por que copiar o varejo produz projeto travado
Cada um desses seis mecanismos, quando não é modelado desde o início, vira uma customização acoplada no fim do projeto. E customização acoplada tem um custo que aparece depois: ela precisa ser revalidada a cada atualização de plataforma, a cada patch, a cada mudança no ERP.
O padrão que observamos é sempre o mesmo. O projeto entrega uma loja bonita e funcional para o cliente que compra à vista, com preço de tabela e quantidade unitária. Ou seja, para o cliente que menos representa o faturamento. Os clientes que representam o volume continuam comprando pelo representante, porque o sistema não modela a realidade comercial deles. Seis meses depois, a conclusão interna é que o mercado B2B não adota digital, quando o que aconteceu foi que o digital não modelou o B2B.
O representante não é o obstáculo
Existe uma leitura comum de que o e-commerce B2B substitui a força de vendas, e ela produz resistência interna justificada. Na prática, os projetos que funcionam fazem o contrário.
O digital assume a recompra previsível, o pedido de reposição, a consulta de posição e o acompanhamento de entrega. Isso libera o representante do trabalho de digitação e o devolve à função comercial: negociação, abertura de conta, ampliação de mix. O ganho não é redução de equipe, é redirecionamento de tempo para atividade que gera margem.
Quando o representante enxerga a plataforma como ferramenta dele, com acesso à conta do cliente e visibilidade do que está acontecendo, a adoção acontece. Quando ele enxerga a plataforma como substituta, a adoção não acontece, e nenhuma decisão técnica corrige isso.
O que a nossa experiência multi-indústria mostra
Atendemos operações em agronegócio, autopeças, alimentos e distribuição, e um padrão se repete entre setores muito diferentes: o gargalo quase nunca está na loja. Está na integração com o ERP e na modelagem de política comercial.
Isso tem uma consequência prática para quem está planejando um projeto B2B. Se o cronograma dedica a maior parte do tempo à camada de apresentação e trata a integração como uma fase final, o projeto vai atrasar. A ordem correta é inversa: modelar política comercial e integração primeiro, porque é o que define o que a interface precisa mostrar.
O Magento tem esses conceitos disponíveis, incluindo tabela de preço por cliente, lista de compra, cotação e estrutura de conta com múltiplos usuários. Mas eles são estrutura, não configuração pronta. Ativá-los sem modelar a política comercial da empresa produz um B2B genérico que não atende ninguém em particular.
Por onde começar sem travar o projeto inteiro
A complexidade descrita acima leva muitas operações a adiar indefinidamente, esperando o momento em que será possível fazer tudo. Esse momento não chega, e a alternativa não é fazer menos, é sequenciar melhor.
O recorte que costuma funcionar é começar pela recompra de um grupo definido de clientes ativos. São clientes que já compram, já têm cadastro no ERP, já têm tabela de preço definida e já sabem o que querem pedir. O ganho para eles é imediato e o risco de erro comercial é baixo, porque não há negociação nova envolvida.
Esse recorte exerce quase toda a infraestrutura difícil, ou seja, preço por cliente, unidade de venda, consulta de crédito e integração de pedido, mas em um universo controlado, com clientes conhecidos e volume previsível. Se algo falhar, falha com quem você consegue telefonar.
Depois que esse fluxo está estável, as camadas seguintes, aprovação hierárquica, acesso do representante, catálogo segmentado e cotação, entram sobre uma base já validada. A ordem inversa, começar pelo caso mais complexo para provar que a plataforma dá conta, é a que produz projeto de dois anos sem entrega intermediária.
Como a Trezo trata esse cenário
A Trezo trabalha exclusivamente com Magento há mais de 16 anos, em operações de médio e grande porte nos setores de eletrônicos, beleza, farma, alimentos, agronegócio e autopeças. Somos parceiros AWS Partner Network e certificados ISO 27001, o que significa que infraestrutura e tratamento de dados seguem processo auditado, não improviso.
Se essa conversa está em aberto na sua operação e você ainda não tem um diagnóstico escrito para levar à diretoria, vale meia hora. Fale com nossos especialistas.
Perguntas frequentes
Dá, e em muitos casos é a melhor decisão, desde que a arquitetura separe o que precisa ser separado: visibilidade de catálogo, política de preço e fluxo de checkout. O erro é tratar o B2B como um modo secundário do B2C. Quando as duas operações compartilham catálogo e estoque mas divergem em preço, unidade e condição, a modelagem precisa refletir isso desde o início.
O prazo é definido pela complexidade da política comercial e pela profundidade da integração com o ERP, não pelo tamanho do catálogo. Operação com tabela de preço simples e ERP com API madura anda rápido. Operação com política por cliente, alçada de aprovação e crédito consultado em tempo real é projeto de vários meses, e a maior parte desse tempo é de integração e regra, não de interface.
Depende de quais dos seis mecanismos você usa. Parte deles é atendida por recursos disponíveis na edição comunitária com desenvolvimento. O módulo comercial entrega cotação, conta empresarial com hierarquia e lista de compra prontos. A conta a fazer é o custo do módulo contra o custo de construir e manter o equivalente, considerando que o equivalente precisará ser revalidado a cada atualização.
