A integração CRM ERP deve começar pela definição do evento que autoriza o pedido, dos campos obrigatórios e de quem decide cada dado. Depois, é preciso validar a venda, confirmar o pedido no destino e guardar as referências entre os sistemas. A matriz e o checklist abaixo orientam esse planejamento, mas dependem das regras da empresa e das interfaces disponíveis nos sistemas escolhidos.
Uma venda aprovada precisa chegar à operação com informações e autorizações claras. Use um contrato de dados: um acordo sobre campos, validações, estados e responsáveis.
O exemplo deste guia é hipotético, não foi testado e não pressupõe compatibilidade com um ERP específico. Os nomes de campos são conceituais; a implementação exige conferir a documentação dos sistemas escolhidos.
Quando a venda está pronta para virar pedido
Defina o que autoriza a criação antes de configurar o envio. Uma regra proposta é exigir oportunidade em estado elegível, aprovação comercial registrada e cadastro validado. Essa combinação precisa ser aprovada pelas áreas, não deduzida de um rótulo da tela.
Na documentação de negócios do HubSpot, negócios representam transações com contatos ou empresas e percorrem etapas até ganho ou perda. A API usa identificadores internos de etapa e pipeline. Isso descreve o estado comercial; não comprova autorização para criar pedido ou faturar no ERP.
Registre o conteúdo aprovado
Registre cliente, itens, quantidades e condições aprovados. Antes do envio, compare-os com os dados atuais; mudanças relevantes devem voltar para decisão.
Registre motivo de bloqueio e responsável. “Cadastro incompleto” precisa indicar uma ação, como revisar o endereço exigido pelo destino.
Monte a matriz da integração CRM ERP
A matriz deve mostrar origem, destino, autoridade sobre o campo, validação e responsável pela exceção. “Sistema mestre” significa, aqui, a origem aprovada para decidir um dado. Não é um recurso que todo software oferece nem uma regra de sincronização em duas direções.
Neste exemplo, o CRM concentra informações comerciais e o ERP decide os estados do pedido. Dados fiscais ficam sujeitos à autoridade definida pela área cadastral. Essa distribuição é uma proposta para discussão, não uma regra aplicável a qualquer empresa.
Separe contato, cliente e oportunidade
Um contato comercial não deve ser convertido automaticamente em cliente apto ao pedido. A documentação de contatos do HubSpot trata contatos como informações sobre pessoas e permite associá-los a outros registros. Isso não define os requisitos de cadastro fiscal do seu ERP.
Preserve os identificadores originais e documente a correspondência entre os registros. Não substitua o vínculo pelo nome exibido: o nome do contato não basta para decidir qual empresa receberá o pedido.
Título
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
| Informação | Origem e destino | Autoridade proposta | Validação | Responsável pela exceção |
|---|---|---|---|---|
| Referência de cliente | Registro comercial e correspondência com cliente no ERP | Cada sistema mantém seu ID; integração mantém o vínculo | Conferir correspondência sem identificar empresa pelo nome do contato | Cadastro/administrativo |
| Contato, telefone e e-mail | CRM para contato necessário ao pedido | CRM | Conferir preenchimento e formato aceito pelo destino | Comercial |
| Dados fiscais e cobrança | Cadastro aprovado para ERP; referência retorna ao CRM | Área cadastral define por campo | Conferir requisitos documentados; bloquear divergências | Cadastro/financeiro |
| Oportunidade e aprovação | CRM para condição de criação | CRM para etapa e versão aprovada | Conferir estado atual, aprovação e cliente associado | Gestor comercial |
| Produto e condições | Catálogo e proposta aprovada para itens | ERP para códigos e unidades; comercial para proposta | Conferir código, unidade, quantidade e valor conforme destino | Operação/comercial |
| Pedido e referência | Venda para ERP; ID do pedido retorna ao CRM | ERP para pedido; integração para vínculo | Verificar aceite e confirmação pela referência suportada | Integrações/operação |
| Status operacional | ERP para acompanhamento no CRM | ERP | Mapear estados documentados, sem equiparar ganho a pago | Operação/financeiro |
Não há lista universal de campos fiscais neste exemplo: confira os requisitos do ERP escolhido. Defina também o significado de cada estado retornado. Autoridade comercial não autoriza sobrescrita ampla; alterar telefone e cadastro de cobrança são decisões diferentes.
Trate pendências antes de criar ou atualizar
Separe erro de informação de indisponibilidade temporária. Reenviar um cadastro incompleto não corrige o conteúdo; a pendência precisa chegar a quem pode revisar o dado.
Uma proposta de tratamento para esse fluxo é:
- Campo obrigatório ausente: bloquear a passagem, indicar o campo e encaminhar ao responsável cadastral, sem inferir dados fiscais.
- Produto sem correspondência: pedir revisão à operação, sem criar um item genérico automaticamente.
- Cliente divergente: conferir o vínculo antes de enviar ou alterar o pedido.
- Valor ou itens alterados: suspender o envio e obter decisão sobre a nova versão.
Mudança posterior não significa atualização autorizada
Imagine que o comercial altere os itens depois da aprovação. Se o pedido ainda não existe, a nova versão precisa passar pela regra de aprovação. Se já existe, a operação deve avaliar seu estado e decidir se a alteração é permitida.
Reabertura comercial e cancelamento operacional também devem ter tratamentos próprios. Não transforme uma mudança de etapa em exclusão de pedido, estorno ou emissão fiscal automática. Registre quem aprova os efeitos posteriores e qual operação o destino documenta.
Confirme o pedido e devolva o estado ao CRM
Guarde o ID da oportunidade, a referência de envio e o ID confirmado do pedido para relacionar origem e destino.
A ausência de resposta não prova falha na criação. A orientação da Microsoft sobre comunicação entre serviços alerta que uma chamada pode ter sido executada mesmo quando o solicitante não recebe a resposta. Repetir uma operação não idempotente pode executá-la novamente; idempotência significa que a repetição não produz um efeito adicional.
Se a resposta for incerta, consulte pela referência que o destino suporta. Se a confirmação não for confiável, encaminhe para revisão antes de criar novamente. Uma consulta vazia isolada não elimina a possibilidade de execução concorrente ou de um pedido ainda não localizado.
Separe confirmação de nova tentativa
O padrão de novas tentativas da Microsoft distingue falhas transitórias de situações em que repetir não tende a funcionar. Defina espera, limite e encaminhamento após falha conforme o serviço; não aplique repetição indiscriminada à criação de pedidos.
Na confirmação, verifique o resultado de negócio, não apenas a conclusão de uma etapa técnica. Depois, devolva ao CRM somente o estado operacional autorizado e documentado, sem transformar “ganho” em “faturado” ou “pago”.
Onde o n8n pode entrar
A documentação do HTTP Request no n8n orienta configurar parâmetros e corpo conforme a API do serviço. Nesse planejamento, consulta, envio e conferência seriam operações separadas, condicionadas às interfaces efetivamente disponíveis.
Isso não é um workflow pronto nem prova de compatibilidade com seu ERP. Para conhecer o contexto de orquestração, consulte o artigo sobre integrações com n8n, sem dispensar a validação técnica do destino.
Checklist de homologação e responsabilidades
Homologação é a conferência do comportamento antes de liberar o processo. A tabela abaixo é um plano sugerido de testes a executar, não um relato de testes realizados.
| Cenário | Resultado esperado no exemplo | Evidência a conferir | Aprovador |
|---|---|---|---|
| Venda elegível com dados válidos | Pedido criado e vinculado | Pedido relido e referências nos sistemas | Comercial/operação |
| Campo obrigatório ausente | Envio bloqueado e pendência indicada | Campo faltante e responsável registrados | Cadastro |
| Produto sem correspondência | Criação suspensa para revisão | Item divergente identificado | Operação |
| Alteração após aprovação | Nova decisão antes do envio | Versão aprovada comparada à atual | Gestor comercial |
| Pedido já existente | Vínculo conferido antes de qualquer ação | ID e estado relidos | Operação |
| Resposta perdida | Sem repetição cega da criação | Consulta de confirmação ou pendência | Integrações/operação |
| Reabertura ou cancelamento | Efeitos submetidos à decisão apropriada | Decisão e tratamento documentados | Operação/financeiro |
| Retorno de status | CRM recebe apenas o estado mapeado | Estado de origem e valor retornado | Operação |
O comercial aprova o disparo; cadastro aprova os dados; operação e financeiro decidem os efeitos sobre o pedido. A equipe de integrações responde pela leitura e confirmação. O dono do processo reúne essas aprovações para decidir a liberação.
Principais conclusões
- Defina uma autorização de pedido que não dependa apenas da etapa ganha no CRM.
- Documente autoridade, correspondências, validações e responsáveis por campo.
- Encaminhe dados ausentes e mudanças posteriores para decisão antes de avançar.
- Confirme o pedido e preserve referências antes de considerar nova criação.
- Homologue os caminhos de sucesso, pendência e resposta incerta com as áreas responsáveis.
Perguntas frequentes
Uma oportunidade ganha no CRM já autoriza criar um pedido no ERP?
Não por si só. A empresa precisa definir o evento autorizado, a aprovação necessária e as validações que permitem criar o pedido.
Quais campos e identificadores devem acompanhar a venda aprovada?
O planejamento deve contemplar referências de cliente e oportunidade, itens e condições aprovadas. Os campos efetivamente obrigatórios dependem da documentação e das regras do ERP escolhido.
Qual sistema deve prevalecer quando CRM e ERP mostram dados diferentes?
Prevalece a autoridade aprovada para aquele campo, não um sistema escolhido para tudo. No exemplo, o CRM decide dados comerciais e o ERP decide estados do pedido, com autoridade cadastral definida separadamente.
Como distinguir contato comercial de cliente cadastrado no ERP?
Trate-os como registros com finalidades e identificadores próprios. Documente sua correspondência e valide os requisitos do cliente no destino, sem inferi-los a partir do contato.
O que fazer quando faltam campos ou o produto não tem correspondência no destino?
A proposta é bloquear a passagem e encaminhar a pendência ao responsável. Não preencha dados fiscais por inferência nem substitua o produto por um item genérico automaticamente.
Como tratar alteração de valor, itens ou cliente depois da aprovação?
Compare os dados atuais com a versão aprovada e peça nova decisão quando houver mudança relevante. Se o pedido existe, a operação deve avaliar seu estado antes de autorizar atualização.
Como confirmar que o pedido foi criado antes de repetir uma tentativa?
Use a referência suportada pelo destino para reler e conferir o pedido. Se o resultado continuar ambíguo, registre a pendência e intervenha antes de repetir a criação; uma consulta vazia isolada não garante ausência.
O que precisa entrar no checklist de homologação e quem aprova as exceções?
Inclua caminho válido, campos ausentes, correspondências inválidas, alterações, pedido existente, resposta perdida, cancelamento e retorno de status. Distribua as aprovações entre comercial, cadastro, operação, financeiro e integrações conforme a decisão envolvida.
Avalie as interfaces antes da implementação
Use a matriz como documento de decisão entre as áreas e leve as lacunas à análise técnica dos sistemas escolhidos. Para avaliar interfaces, acessos e limitações antes de implementar esse fluxo, veja a análise de viabilidade da integração de sistemas.
