Integração de entregas com CRM: que dados circulam e como configurar a troca

O que quebra quando o CRM e a entrega vivem separados

O CRM cuida da relação com o cliente: é ali que ficam as negociações, os contatos, os prazos combinados e as condições de pagamento. O sistema de gestão de entregas cuida da execução: quem vai, em que ordem, e o que comprova que o serviço foi feito. Enquanto esses dois lados não se falam, existe uma pessoa no meio passando dados na mão — e o custo desse trabalho vai muito além do tempo gasto.

As consequências típicas dessa separação são estas:

• Digitação em dobro e erros de digitação. Um endereço digitado pela segunda vez é um endereço com chance de erro. O profissional vai parar no lugar errado, e o problema só aparece quando ele já está na rua.
• Status atrasados. O vendedor não enxerga o que está acontecendo com o pedido e responde ao cliente «já confirmo e retorno» em vez de dar uma resposta concreta. Cada confirmação dessas é mais uma ligação para o coordenador.
• Pedidos perdidos. A negociação avançou para a etapa «enviado para entrega», mas nunca chegou ao coordenador: ninguém percebeu até o cliente ligar.
• Relatórios que não batem. O CRM mostra um número de entregas, o sistema operacional mostra outro, e só um funcionário com boa memória para detalhes consegue explicar a diferença.

A integração elimina essa camada manual: o pedido aparece para o coordenador no momento em que a negociação chega à etapa combinada, e o resultado da execução volta para a ficha do cliente sem ninguém precisar contar a história. O resto — notificações, relatórios, telas mais confortáveis — é construído em cima dessa troca básica. Por isso, o projeto da integração deve começar pela pergunta «que fatos precisam circular e em que direção», e não por «quais botões apertar».

Que dados circulam entre o CRM e o sistema de entregas

A troca é quase sempre nos dois sentidos, e vale a pena descrevê-la em duas listas curtas — o que sai do CRM e o que volta. Do CRM para o sistema de entregas normalmente vão:

• o pedido ou a ordem: número, tipo de serviço, itens, observação do vendedor;
• o endereço de execução com detalhes de acesso — bloco, andar, autorização de entrada, para quem ligar no local;
• os contatos do destinatário e a janela de horário combinada;
• o valor e a forma de pagamento, se o profissional recebe dinheiro;
• a marcação de urgência ou prioridade — para o coordenador ver o que não pode ficar para amanhã.

De volta, do sistema de entregas para o CRM, retornam os fatos da execução:

• o profissional designado e a previsão de chegada;
• os status: aceito, a caminho, no local, concluído, não realizado;
• o motivo da não realização, escolhido de uma lista fechada — recusa, cliente não atendeu, endereço não encontrado, remarcação a pedido do cliente;
• os comprovantes: fotos, assinatura do destinatário, data, hora e local do registro;
• o pagamento recebido no local, quando é o entregador quem cobra.

À parte, é preciso combinar o que fazer com os cadastros de clientes e endereços. Se os dois lados criam registros, os duplicados aparecem já no primeiro mês: «Padaria Central Ltda» e «Central, Padaria Ltda» viram dois cadastros com históricos diferentes, e qualquer relatório por cliente passa a ser montado na mão. É mais simples eleger um sistema como dono do cadastro e deixar o outro como consumidor.

Uma prática que economiza semanas de troca de e-mails: antes de começar, liste os campos numa tabela de quatro colunas — nome no CRM, nome no sistema de entregas, direção da troca, o que fazer quando o valor vier vazio. Esse documento de uma página é o escopo técnico da integração.

Formas de integrar: API, webhooks e exportação por arquivo

Tecnicamente, dá para ligar os sistemas por caminhos diferentes. A escolha não depende da moda, e sim de quão rápido os dados precisam chegar e do que o seu CRM permite fazer.

• Integração por API. Os sistemas conversam diretamente. É a opção mais flexível: transmite qualquer conjunto de campos e a lógica fica inteiramente sob controle. Em troca, exige configuração e clareza sobre que chamada é acionada em cada evento.
• Webhooks. O próprio CRM avisa quando a negociação chega à etapa combinada, e o sistema de entregas avisa quando o status muda. Os dados são atualizados quase na hora e sem consultas repetidas, mas é preciso pensar antes nas novas tentativas: se o destinatário estava fora do ar, o evento não pode sumir sem deixar rastro.
• Exportação por arquivo. Os pedidos seguem em lote, em horários definidos, por exemplo a partir de uma planilha. É o começo mais rápido: não exige desenvolvimento e serve bem quando os pedidos são fechados de manhã e mudam pouco ao longo do dia.
• Conector intermediário. Um serviço-ponte separado acerta os formatos, guarda as correspondências e as regras. Faz sentido quando a origem não é uma só: parte dos pedidos vem do CRM, parte do sistema de gestão, parte de um formulário no site.

Não existe resposta universal, mas existe um critério simples. Se o cliente espera o status no mesmo dia e o vendedor atende ligações do tipo «cadê o meu pedido», você precisa de troca por eventos. Se a demanda é fechada na véspera e é estável, a exportação por arquivo dá conta, e só vale complicá-la quando aparecer um problema concreto que ela não resolve.

O itlogist tem integração com AmoCRM, Bitrix24, 1С e Excel — os pedidos entram em operação a partir da origem de sempre, sem redigitação. O que acontece com o pedido depois — distribuição entre os profissionais, rotas no mapa em tempo real, aplicativo móvel do entregador com fotos e checklists, portal do contratante com os status — está reunido na página Recursos do itlogist.

Fonte da verdade, chave de correspondência e tratamento de erros

A maior parte dos problemas de integração não é técnica, é de combinado. Abaixo estão quatro perguntas cujas respostas determinam se a troca vai funcionar sem supervisão diária.

• Chave de correspondência. Por qual campo o pedido na entrega é ligado à negociação no CRM — número da negociação, identificador interno, número do pedido. A chave precisa ser única, imutável e trafegar nos dois sentidos. Ligar por telefone ou endereço desmorona no segundo pedido do mesmo cliente.
• Fonte da verdade de cada campo. Quem manda no endereço, quem manda no horário de entrega, quem manda no valor. Se o vendedor mudou a janela no CRM e o coordenador mudou no sistema de entregas, quem vence não é quem clicou por último, e sim quem a regra definiu.
• Modelo de status único. As etapas do funil no CRM e os status de execução são coisas diferentes. É preciso uma tabela explícita de correspondência: que status operacional move a negociação para que etapa e quais transições são proibidas. Sem isso, a negociação começa a voltar de etapa a cada nova tentativa de entrega.
• Comportamento em caso de erro. O que acontece se o endereço vier vazio, o cliente não for encontrado ou o destino não responder. O cenário que funciona: o pedido não se perde em silêncio, ele vai para uma fila de reprocessamento ou para uma lista de análise manual — e alguém é responsável por essa lista.

Há mais duas coisas de que costumam lembrar tarde. A primeira: o reenvio não pode gerar duplicado — se o evento chegou duas vezes, a segunda tentativa tem de atualizar o pedido existente, não criar outro. A segunda: as permissões — a conta de integração vê e altera apenas o necessário para a troca, e o acesso dela não fica preso a um funcionário específico que um dia vai embora levando a senha junto.

Ordem de implantação: de um cenário ao fluxo completo

Não vale a pena subir a integração inteira de uma vez. A sequência que funciona é esta, e normalmente cabe em poucas iterações curtas.

• Descreva um cenário do início ao fim. Pegue o tipo de pedido mais comum e percorra o trajeto inteiro, da etapa no CRM até o registro de conclusão. Os casos fora do padrão — devoluções, recusas parciais, novas visitas — entram na segunda etapa.
• Aprove o mapa de campos. Aquela mesma tabela de quatro colunas. Enquanto ela não estiver validada pelos dois lados, é cedo para começar a configurar.
• Arrume os dados. Endereços padronizados, telefones atualizados, observações sobre acesso. A integração acelera também a passagem de lixo: um endereço ruim apenas chega mais rápido ao profissional.
• Teste com um fluxo de ensaio. Uma dezena de pedidos nos dois sentidos, incluindo os propositalmente errados: sem endereço, duplicado, cancelado depois de designado.
• Elimine a passagem manual. Assim que a troca começar a rodar, o caminho antigo precisa ser desligado. Dois processos em paralelo sempre terminam em divergência de dados e em discussão sobre qual dos dois está certo.
• Combine o suporte. Quem acompanha a fila de erros, em quanto tempo reage, o que faz quando um dos sistemas fica indisponível.

Para conferir o resultado, ajudam alguns indicadores simples, medidos antes e depois: quanto tempo passa entre a negociação chegar à etapa combinada e o pedido aparecer para o coordenador, quantos pedidos ainda são cadastrados na mão, com que frequência os vendedores ligam para a central perguntando o status. Esse último costuma ser o primeiro a mudar — é por ele que se percebe que a informação passou a circular pelo sistema, e não pelas pessoas.

A barreira de entrada aqui é mais baixa do que se imagina: a implantação leva 7 dias, sem contratos de longo prazo, e a plataforma foi pensada para equipes de 5 a 100 profissionais. Ou seja, dá para testar a ligação com o CRM no fluxo real de pedidos e comparar com a base registrada já no mês seguinte.