Portal de encomendas B2B para distribuidores

Um portal de encomendas B2B deixa os clientes aprovados verem o seu próprio catálogo e os seus preços, colocarem e repetirem encomendas e acompanharem os documentos, tudo sincronizado com o ERP. Delimite o âmbito por fases — contas, preços e encomendas primeiro, pagamentos e aprovações a seguir — porque um projeto de desenvolvimento de software que tenta nascer completo chega tarde e é usado a meio.

O que é um portal de encomendas B2B?

Um portal de encomendas B2B é um canal web com a sua marca onde os distribuidores aprovados e os clientes de comércio entram e fazem negócios por conta própria: consultam o catálogo visível para a sua conta, veem os preços acordados com eles, montam uma encomenda ou repetem uma anterior e encontram os documentos que pertencem à sua conta — cotações, encomendas, faturas, notas de crédito, entregas. O ERP continua a ser o sistema de registo; o portal é a janela para ele, com regras sobre o que cada conta pode ver e fazer.

Vale a pena separar o portal de três vizinhos com quem se confunde frequentemente:

Uma loja online. Preços de retalho, registo aberto, pagamento por cartão. Um portal de distribuidores é o oposto: o acesso concede-se por conta, os preços são contratuais e o pagamento segue os termos acordados e não um checkout.

Uma área de cliente num site de marketing. Útil para transferências e tickets de suporte, mas sem catálogo, preços e lógica de encomendas não elimina uma única chamada ao balcão de vendas.

Uma lista de preços em PDF por correio eletrónico. O estado em que a maioria dos distribuidores vive antes de um portal: exata no dia em que é enviada, errada na semana seguinte e não pesquisável por conta.

O que distingue um projeto de um simples site é a integração: o catálogo, as listas de preços, a posição de crédito e os documentos em aberto vivem em sistemas que já gerem a empresa, e o portal tem de concordar com eles por conta, por moeda e por momento. As secções abaixo tratam isto como a questão central de âmbito e não como detalhe técnico, porque a maioria dos projetos de portal decepcionantes falhou nessa concordância e não no design.

Tabela de funcionalidades: essenciais, desejáveis, para depois

As páginas de funcionalidades dos fornecedores listam tudo de uma vez. Delimitar o âmbito por fases é o que mantém a primeira versão publicável. A tabela ordena as funcionalidades recorrentes pelo que a primeira versão precisa, pelo que a segunda costuma acrescentar e pelo que pode esperar por dados de utilização reais:

Tabela A: funcionalidade | finalidade | fase (1/2/3) | dependência do ERP

Funcionalidade	Finalidade	Fase	Dependência do ERP
Contas de cliente e início de sessão	Cada distribuidor vê apenas os seus próprios dados	1	Contas e contactos
Listas de preços por conta	Preços contratuais, grupos de preços ou precificação escalonada por conta	1	Listas de preços e grupos de preços
Catálogo com visibilidade por conta	Os produtos que cada conta pode comprar, com documentos e imagens	1	Dados mestres de produto, regras conta-produto
Encomenda rápida e repetição	Números de artigo, CSV ou folha de carregamento, repetir a última encomenda	1	Dados mestres de produto, regras de encomenda mínima
Submissão da encomenda no ERP	A encomenda torna-se um documento de ERP, não um correio eletrónico	1	API de encomendas ou canal de integração
Estado da encomenda e visibilidade de documentos	Faturas, notas de crédito e entregas visíveis por conta	2	Arquivo de documentos ou sistema de tesouraria
Cotações e conversão de cotação em encomenda	Pedido de preço, aprovação, conversão numa encomenda	2	Documentos de cotação no ERP
Limites de crédito e prazos de pagamento líquido	Mostrar à conta a sua posição e os seus prazos; bloquear a submissão de encomendas fora das regras	2	Dados de crédito e prazos no ERP
Pagamentos no portal	Liquidação online contra faturas ou encomendas	3	Gateway de pagamentos mais conciliação no ERP
Funções de aprovação de encomendas	O comprador propõe, o aprovador autoriza, limites por função	3	Dados de aprovação ou fluxo do lado do portal
Catálogo e documentos multilíngues	Idioma de comércio por mercado ou por conta	3	Traduções de produto, modelos de documento
Seguimento e notificações de expedição	Estado da expedição sem telefonar ao balcão de vendas	3	Dados logísticos ou de transporte

A fase 1 é a versão que muda comportamentos: se um distribuidor consegue entrar, ver os seus preços, repetir a encomenda do mês passado e fazê-la chegar ao ERP, o canal do telefone e da folha de cálculo começa a fechar-se sozinho. As fases 2 e 3 acrescentam as camadas do dinheiro e da governação, que precisam de que as decisões de crédito, finanças e aprovação da organização estejam tomadas antes de o software as poder suportar.

Integração com ERP e CRM

A integração decide se o portal é um espelho do negócio ou um folheto com início de sessão. Quatro questões precisam de resposta escrita antes de qualquer arquitetura ser escolhida:

Direção da sincronização. Os dados mestres — contas, produtos, preços, prazos — fluem do ERP para o portal. Encomendas, pedidos de preço e pagamentos fluem de volta. Qualquer outra coisa precisa de um responsável explícito: quem pode alterar um preço, e onde é que essa alteração fica?

Frequência da sincronização. Lote noturno, atualização periódica durante o dia ou quase em tempo real. A regra honesta: preços e posição de crédito justificam uma sincronização mais frequente do que as imagens de produto, pelo que uma estratégia mista é normal — dados críticos mais vezes, conteúdo de catálogo menos vezes.

Tratamento de falhas. Quando o ERP está em baixo ou um registo falha na validação, o que faz o portal: enfileira, rejeita ou mostra o último estado conhecido com um aviso claro? A falha silenciosa é como um distribuidor acaba por encomendar ao preço da semana passada, o que se torna uma disputa sua e não dele.

Conciliação. Como sabe que cada encomenda do portal se tornou exatamente um documento de ERP — sem duplicados, sem lacunas, sem registos meio convertidos? A resposta é um relatório operacional que alguém lê diariamente durante os primeiros meses, e é um dos testes de aceitação abaixo.

Dois padrões de implementação cobrem a maioria dos projetos. O caminho nativo do ERP constrói o portal como extensão das próprias capacidades do ERP, o que minimiza o número de sistemas que têm de concordar mas herda os limites de front-end do ERP. O caminho da plataforma executa uma plataforma de comércio — Shopify e sistemas semelhantes são os exemplos habituais no material dos fornecedores — e liga-a ao ERP através de middleware ou conectores; essa via compra flexibilidade de front-end e uma interface de administração familiar ao custo de mais um sistema a manter em sincronização. A página ERP à medida versus comercial trata a versão mais ampla desta questão construir ou comprar, e a checklist de RFP para fornecedores transforma ambas as opções em perguntas que se podem pontuar numa proposta.

Catálogos multilíngues e multimoeda

Os exportadores esbarram nas duas questões cedo, e resolvê-las já na primeira fase custa menos do que as corrigir a posteriori.

Idiomas. O catálogo precisa de traduções de nomes de produto, categorias e documentos; a estrutura de contas precisa de uma preferência de idioma por conta, para o portal não pedir ao mesmo comprador que escolha em cada visita. Dois pontos práticos: decida quem é dono das traduções e o seu ritmo de atualização — um catálogo meio traduzido lê-se pior do que um só em inglês para o comprador que repara — e decida se os documentos (cotações, faturas) seguem o idioma da interface ou ficam no idioma que o seu sistema financeiro exige. Essa segunda questão não é técnica: uma fatura no idioma errado é um problema de contabilidade.

Moedas. Os preços acordados numa moeda devem ser mostrados nessa moeda independentemente da localização do visitante; misturar moedas de exibição com moedas contratuais é como começam as disputas. Se uma conta opera em mais de uma moeda, a regra tem de viver nos dados do ERP e não nas definições do portal, e o portal nunca pode ser o lugar onde se inventa uma conversão.

Ambos os temas interagem com o plano por fases: um exportador que vende a três mercados pode lançar a fase 1 nos idiomas que esses três mercados efetivamente usam nas encomendas e acrescentar mais idiomas de catálogo quando o mercado crescer. A regra geral para o trabalho de idiomas em sites comerciais — um responsável, um ficheiro de origem, uma via de atualização — está descrita na página de marketing na internet, e aplica-se a um catálogo de portal da mesma maneira.

Segurança e funções de acesso

Um portal é uma porta para os seus dados comerciais, por isso as questões de design são questões de acesso:

O acesso concede-se, nunca se autoatribui. Cada conta é criada pela sua equipa contra uma conta de ERP; a alternativa — registo aberto com um passo de aprovação — convida ruído e dilui quem é cliente.

Permissões baseadas em funções. Um comprador pode montar e submeter encomendas dentro de um limite; um aprovador pode libertá-las; um leitor pode apenas consultar documentos. Os limites por função fazem parte dos termos comerciais e não um detalhe técnico pensado à última hora — codificam quem na organização do seu cliente os pode comprometer.

Isolamento por conta. O modo de falha mais grave nesta classe de produto é um distribuidor ver os preços ou documentos de outro. A visibilidade de dados por conta deve ser testada explicitamente, e é um dos testes de aceitação abaixo.

Rastro de auditoria. Quem colocou a encomenda, quem a aprovou, quem alterou um preço e quando — guardado como dados e não como ficheiros de log que alguém tem de ser convencido a ler. As disputas no comércio resolvem-se por este rastro com mais frequência do que por memória.

Identidade e início de sessão único. Para distribuidores maiores, o SSO para o seu próprio diretório é um requisito frequente que vale a pena delimitar tarde e não cedo — a maioria das contas funciona feliz com convites e palavras-passe até que uma sede peça federação.

Proteção de dados. Os dados de cliente no portal ficam sob os mesmos deveres que a empresa já tem para os seus registos de clientes; para operações na Turquia é o quadro da KVKK e para clientes europeus o GDPR, tema tratado em detalhe na página de subcontratação no contexto de trabalhar com um parceiro de desenvolvimento.

Software à medida ou plataforma de comércio

A escolha não é à medida versus comercializado no abstracto; é sobre que camada está efetivamente a comprar.

Tabela B: rota | o que obtém | o que assume | serve quando

Rota	O que obtém	O que assume	Serve quando
Portal nativo do ERP	Um único sistema de registo, preços e crédito já consistentes, menos interfaces	Front-end e mobilidade limitados pelas capacidades próprias do ERP; os ciclos de lançamento do ERP governam o portal	O ERP é moderno, o seu módulo de portal cobre a maioria da fase 1 e o TI interno o sabe administrar
Plataforma de comércio + conector de ERP	Administração familiar, boa experiência de front-end e de telemóvel, trabalho de catálogo rápido	Um segundo sistema a manter em sincronização; manutenção do conector; duas vias de atualização	A experiência de compra importa tanto como os dados, e alguém é dono da integração a longo prazo
Portal à medida	Encaixe exato nas regras comerciais, incluindo as peculiares que definem o seu comércio	Responsabilidade total: segurança, desempenho, atualizações, todo o ciclo de vida	O processo diferencia genuinamente o negócio e nenhuma plataforma o suporta — o teste é se uma funcionalidade padrão mais uma alteração de processo chegariam para o efeito

A rota do meio é a escolhida pela maioria dos exportadores da primeira vez, e o erro a evitar é tratá-la como a barata: um conector é um produto mantido, e o seu custo é recorrente. O quadro de decisão desta questão — configurar, comprar ou construir — é tratado por extenso na página ERP à medida versus comercial; o que esta página acrescenta é o teste específico do portal: seja qual for a opção, a lista de preços por conta e a encomenda para o ERP têm de ser comprovavelmente corretas, e a rota escolhida deve ser a que torna isso comprovável ao custo recorrente mais baixo.

Lançamento por fases e testes de aceitação

Um lançamento de portal falha em silêncio quando «funciona» significa «a demonstração funcionou». Cada fase deve trazer testes de aceitação por escrito, executados com contas reais e dados reais:

Visibilidade do catálogo por conta. Entre como dois distribuidores diferentes; cada um vê exatamente o seu próprio conjunto de produtos e nem um rastro do outro. Testado de propósito, não presumido.

Exatidão dos preços. Para uma amostra de contas e artigos, o preço do portal é igual ao preço do ERP — incluindo as regras por trás dele (grupo de preço, escalão, acordo). Este é o teste que protege a relação comercial; um preço errado num portal é pior do que um preço errado numa cotação, porque o cliente viu-o como o acordo vigente.

Integridade da encomenda. Uma encomenda colocada no portal torna-se exatamente um documento de ERP, com artigos, quantidades, unidades e preços corretos — e o relatório de conciliação mostra-o. Teste também o caminho de falha: uma encomenda bloqueada por uma regra deve dizê-lo claramente em vez de falhar em silêncio.

Estado e documentos. Uma fatura e uma entrega registadas no ERP aparecem na vista de portal da conta certa, com o estado certo, dentro da janela de sincronização acordada.

Prazos e limites. Crédito e prazos de pagamento por conta exibidos corretamente, e onde as regras dizem que uma encomenda deve ser bloqueada ou assinalada, ela é bloqueada ou assinalada — testado no limite e não no meio confortável.

Os hábitos diários. Repetição, encomenda rápida por número de artigo e pesquisa — com as listas de produtos de dois distribuidores reais seus, não com o catálogo de demonstração. A adoção vive ou morre por estes três caminhos, e custam uma fração da construção para serem bem testados.

A ordem de lançamento importa tanto quanto os testes: um mercado piloto ou um punhado de contas primeiro, o feedback deles incorporado, e depois abertura mais alargada. A alternativa — um anúncio de lançamento a todos os distribuidores no mesmo dia — converte as primeiras semanas de correções inevitáveis num custo de credibilidade, e os distribuidores que encontram um preço errado na primeira semana voltam muitas vezes ao telefone durante meses. A lógica do piloto é a mesma descrita para trabalhos de software na página de subcontratação, e a disciplina de avaliação das equipas que constroem portais está na checklist de RFP.

Perguntas frequentes

Precisamos primeiro de um ERP?

Não um novo — mas precisa dos dados mestres num sítio de confiança: contas, produtos, listas de preços e prazos. Se esses dados vivem só em folhas de cálculo, o portal vai automatizar os erros da folha de cálculo por conta, o que é pior do que ficar no telefone. Nesse caso, a sequência honesta é estabilizar primeiro os dados (muitas vezes num ERP existente que está subutilizado) e o portal depois; a página de Odoo para empresas de comércio trata essa decisão pelo lado do ERP.

Os clientes podem ter as suas próprias listas de preços?

Sim — a precificação por conta é o núcleo desta classe de produto e não um extra: grupos de preços, precificação escalonada ou acordos individuais, tudo guardado no ERP e mostrado por conta. A regra por que vale a pena insistir é que o portal nunca calcule um preço por conta própria; mostra o que o ERP guarda, e cada preço que um distribuidor vê pode ser rastreado até um acordo que a sua equipa fez.

Como se aprovam as encomendas?

Duas camadas, normalmente. Dentro da organização do cliente, a aprovação é dele: um comprador propõe, um aprovador autoriza, opcionalmente dentro de limites — o portal pode carregar essas funções na fase 3. Dentro da sua própria organização, a encomenda chega ao ERP e segue o seu tratamento de encomendas normal; o portal não substitui os controlos do seu balcão de vendas, elimina a redigitação e a chamada telefónica à volta deles.

O portal pode lidar com vários idiomas?

Sim, e deve — mas delimite o âmbito por fase. Traduções de catálogo, preferência de idioma por conta e documentos traduzidos são três trabalhos diferentes; lance a fase 1 nos idiomas que os seus mercados ativos usam nas encomendas e acrescente o resto com procura real. Os pontos de governação — um responsável para as traduções, uma via de atualização — estão na secção multilíngue acima.

Quem é dono dos dados?

São seus — as contas, os preços, as encomendas, os documentos e o histórico continuam a ser registos da empresa, no ERP. Vale a pena dizer isto no contrato com quem constrói o portal: acesso ao alojamento, código-fonte ou configuração, e exportação dos seus dados à saída, tudo nomeado. A página de subcontratação cobre propriedade intelectual e termos de saída no contexto mais amplo do contrato de desenvolvimento.

Como integramos os distribuidores?

Comece pelas contas que mais encomendam, convide-as pessoalmente e dê-lhes três coisas na primeira mensagem: o seu início de sessão, a sua lista de preços visível no ecrã e uma pessoa para quem ligar. Depois observe o sinal de adoção que efetivamente importa — não os inícios de sessão, mas a quota do volume de repetição que chega pelo portal. O trabalho em paralelo (encomenda no portal, depois confirmada por telefone) é normal durante semanas; termina quando o portal está comprovadamente certo em preços e documentos, e é para isso que servem os testes de aceitação acima.

Fontes e normas

O conjunto de funcionalidades típico aqui descrito (contas, listas de preços por conta, repetição, faturas e notas de crédito, visibilidade por conta, funções com limites, prazos líquidos, gateways de pagamento) segue as listas de capacidades descritas pelos fornecedores para portais de encomendas B2B em geral; não se alega nesta página nenhum resultado de desempenho, custo nem prazo.
Os padrões de implementação (portal nativo do ERP; plataforma de comércio como a Shopify sincronizada com o ERP através de middleware ou conectores) são descritos como as duas vias recorrentes; não é alegada nenhuma parceria com qualquer fornecedor de plataforma.
As afirmações de processo e governação seguem as páginas deste site: ERP à medida versus comercial, checklist de RFP para fornecedores, Odoo para empresas de comércio e subcontratação de TI a partir da Turquia (deveres de proteção de dados, propriedade intelectual e termos de saída, desenho do piloto).
Não aparecem nesta página exemplos de clientes, orçamentos de portal nem durações de projeto; o âmbito, a faseamento e os termos comerciais fixam-se por projeto na cotação.

Páginas relacionadas

Desenvolvimento de software · ERP à medida versus comercial · Checklist de RFP para fornecedores · Odoo ERP para empresas de comércio · Marketing na internet · Pedir uma cotação