# Integração de sites B2B com CRM: preparar a entrega dos pedidos

[Ler este artigo na ENQAVIA](https://enqavia.com/pt/articles/b2b-website-crm-integration/)

Por ENQAVIA · Publicado em 2026-10-17

A integração de sites B2B com CRM liga os pedidos do site ao sistema de gestão de relações com clientes, mas o resultado útil é um pedido que a pessoa certa consegue encontrar e tratar. Defina esta passagem durante o desenvolvimento do site, antes de escolher um conector ou desenhar um painel comercial.

Um comprador pode pedir uma peça de substituição, um orçamento de fabrico ou uma visita de manutenção. Estes pedidos exigem acompanhamentos diferentes, mesmo quando chegam pelo mesmo site. Este guia explica o que incluir no documento de requisitos; não pressupõe que o seu site já tenha uma ligação ao CRM.

## Defina o registo de que a equipa comercial precisa

Decida se cada envio cria um contacto, um pedido, uma oportunidade comercial ou vários registos relacionados. Um formulário preenchido não é automaticamente uma oportunidade qualificada. A equipa pode precisar de verificar a área de serviço ou a adequação técnica.

Escreva um critério de aceitação: «Um pedido válido cria um registo rastreável, preserva os requisitos do comprador e chega a uma equipa designada». Combine o tratamento de remetentes já existentes. Atualizar um contacto não deve substituir o responsável pela conta nem eliminar pedidos anteriores.

Inclua estas decisões nos [requisitos de desenvolvimento do site industrial](https://enqavia.com/pt/#services). Para perguntas visíveis e validação, consulte o [guia de formulários de pedido de orçamento](https://enqavia.com/pt/articles/rfq-form-design/). A especificação da integração começa pelo destino da informação submetida.

## Faça a correspondência dos dados antes da ligação

Prepare um mapa de campos com a equipa comercial e o responsável pelo CRM. Para cada valor, registe origem, destino, formato, valores permitidos e tratamento de dados em falta. Distinga uma resposta vazia de «ainda não definido».

O exemplo hipotético abaixo corresponde a um fornecedor que recebe pedidos de componentes. Ilustra decisões de correspondência, sem descrever um produto CRM específico.

| Informação do site | Destino previsto | Regra a combinar |
| --- | --- | --- |
| E-mail do contacto | Registo de contacto | Procurar um contacto existente sem juntar pessoas diferentes |
| Referência do produto | Linha do pedido | Conservar a referência estável e a designação legível |
| Quantidade e unidade | Linha do pedido | Manter número e unidade juntos, sem presumir peças |
| Mensagem do comprador | Descrição do pedido | Preservar o sentido e as quebras de linha dentro dos limites definidos |
| Página e idioma escolhido | Contexto do pedido | Guardar a página relevante sem parâmetros de URL confidenciais |
| Referência do envio | Registo de entrega | Acompanhar o mesmo pedido durante toda a passagem |

Os identificadores dos produtos devem vir dos mesmos registos usados pelo site. O [guia de sites com catálogo de produtos](https://enqavia.com/pt/articles/product-catalog-website/) explica essa base. Evite depender apenas das designações traduzidas: podem mudar sem que o produto mude.

## Atribua responsabilidades e preserve o pedido original

Escolha uma regra que a equipa consiga explicar, como família de produtos, zona de serviço ou responsável atual pelo cliente. Defina uma equipa de recurso para pedidos sem correspondência. Um registo sem responsável deve aparecer numa lista de revisão, não ficar esquecido.

Mantenha a mensagem original disponível quando a equipa acrescenta notas ou esclarece requisitos. A interpretação do comercial não deve substituir as palavras do comprador. Registe a origem e a hora de receção para distinguir um novo pedido de uma conversa anterior.

Num site com vários idiomas, envie separadamente o idioma escolhido e o país de entrega. Respondem a perguntas diferentes. O [guia de sites multilingues](https://enqavia.com/pt/articles/multilingual-manufacturing-website/) aborda a terminologia e a estrutura linguística. Uma regra automática de encaminhamento não basta para justificar uma promessa de prazo de resposta.

## Distinga aceitação, espera e entrega ao CRM

Uma mensagem de agradecimento no navegador não prova que o comercial tenha um registo utilizável. Defina cada etapa e o sistema que a confirma:

- **Aceite:** o serviço recetor validou e guardou o pedido para processamento.
- **Em fila:** o pedido aguarda entrega através de um processo combinado e acompanhado.
- **Entregue:** o destino confirma o registo previsto, com uma referência verificável.
- **Falhou:** uma etapa precisa de recuperação ou análise.

Também é necessário tratar resultados incertos. Se a ligação expirar depois de o CRM receber o pedido, o remetente pode não saber se a entrega foi concluída. Não mostre «entregue» apenas porque passou algum tempo. Também não peça uma repetição quando o pedido está guardado de forma fiável e aguarda processamento.

## Evite duplicados e permita recuperar falhas

Pedidos POST repetidos podem criar registos duplicados; a sua idempotência não é garantida. [Explicação da MDN](https://developer.mozilla.org/en-US/docs/Glossary/Idempotent).

Pergunte à equipa de desenvolvimento como identifica um envio durante novas tentativas. Uma repetição deve recuperar o resultado existente, enquanto um pedido realmente novo do mesmo e-mail deve continuar separado. O endereço não basta como critério: um comprador pode ter várias necessidades de aquisição.

Combine um número limitado de tentativas, os intervalos e um procedimento para analisar falhas persistentes. Valores de campo inválidos precisam de correção, não de reenvio interminável. Guarde informação de diagnóstico suficiente para identificar a etapa e a referência em causa, sem copiar mensagens completas para os registos técnicos habituais.

Designe quem verifica as exceções e quem pode repetir a entrega de um pedido. Inclua a recuperação e a manutenção do conector ao comparar o [custo de desenvolvimento de um site industrial](https://enqavia.com/pt/articles/manufacturing-website-cost/).

## Limite acessos e proteja as credenciais

As credenciais privadas do CRM pertencem a um ambiente de servidor aprovado ou a um serviço de integração gerido, não ao código da página, ao JavaScript descarregado ou a conteúdos públicos. Dê à ligação apenas as permissões necessárias às ações combinadas. Criar um pedido não exige automaticamente autorização para exportar toda a base de clientes.

Decida quais os dados necessários, onde são guardados, quem lhes acede e por quanto tempo. Se houver desenhos técnicos, defina separadamente um circuito de ficheiros controlado. Uma biblioteca pública de conteúdos não é um arquivo privado de pedidos. Ajuste a informação de privacidade ao processo real e obtenha a aprovação do responsável.

## Teste a passagem completa antes do lançamento

Use contactos fictícios e requisitos de exemplo num ambiente de testes autorizado. Verifique os registos de destino, não apenas a mensagem apresentada ao visitante.

| Teste | Evidência do resultado correto |
| --- | --- |
| Novo pedido válido | Campos, origem, responsável e referência de registo corretos |
| Contacto existente, necessidade nova | Contacto associado corretamente; pedido separado |
| Mesmo envio entregue duas vezes | Um pedido previsto, com referência de entrega consistente |
| Destino temporariamente indisponível | Pedido guardado ou claramente recusado; recuperação conforme o processo |
| Campo de destino inválido | Falha visível para a equipa responsável, sem falsa confirmação |
| Outro idioma e outra unidade | Significado, idioma e unidade originais preservados |

Na entrega do site, peça o mapa de campos, as regras de atribuição, as definições dos estados, o responsável pelos acessos e as instruções de recuperação. Registe quem mantém a ligação quando qualquer sistema muda. Para [discutir os requisitos do seu site](https://enqavia.com/pt/contact/), traga o percurso atual dos pedidos e os registos CRM que a equipa espera receber.