Formulário integrado ao CRM: como saber se algum lead se perde?

Para saber se algum contato está se perdendo, não basta comparar quantos envios o formulário recebeu com quantos registros novos apareceram no CRM. Totais iguais podem esconder uma perda compensada por outro fenômeno, e totais diferentes podem ter explicação inofensiva. Uma forma de avaliar é conferir cada envio individualmente: para cada submissão, existe um registro ou uma atividade correspondente no CRM, dentro de um prazo combinado?

Essa checagem vem antes da análise de resultados. Comparar o que cada ferramenta de medição mostra é outro assunto, tratado em GA4 e CRM com números diferentes. Aqui a pergunta é mais básica: o contato que preencheu o formulário chegou ao time comercial, e chegou em tempo útil?

Por que o total sozinho engana

Há pelo menos três situações em que a soma não conta a história inteira. Primeiro, um envio de uma pessoa que já está na base pode atualizar o contato existente em vez de criar um novo, e então o CRM mostra menos registros criados sem que nada tenha sido perdido. Segundo, um envio feito no fim da janela pode chegar ao CRM depois dela e aparecer na semana seguinte. Terceiro, uma perda real pode ser compensada por registros de outra origem ou por duplicatas, e o total fecha mesmo com um contato faltando.

Por isso a proposta é reconciliar por identificador. Cada envio recebe uma identificação (o código da submissão, o e-mail ou o horário, conforme o que o seu formulário guarda), e a conferência procura esse envio no CRM, seja como contato criado, seja como atividade registrada num contato existente.

A rotina semanal de reconciliação

A planilha tem uma linha por envio de um único formulário, em uma janela fixa (por exemplo, de segunda a domingo). Registros de outros formulários, de telefone ou de indicação ficam de fora, porque misturar grupos esconde a divergência. Se o volume for grande demais para conferir linha a linha, uma alternativa é conferir todos os envios de alguns dias escolhidos e manter a contagem total nos demais, sabendo que a conferência parcial cobre menos.

Um exemplo hipotético: numa semana, o site registra 42 envios. Na conferência individual, 36 viraram contatos novos, 3 atualizaram contatos que já existiam, 2 eram testes da equipe e 1 não foi encontrado. Somando, 36 + 3 + 2 + 1 dão os 42 envios, e só uma linha precisa de investigação. Note que comparar apenas 42 envios com 36 contatos novos sugeriria seis perdas, número que a conferência individual reduz a uma. No sentido inverso, se o CRM mostrasse 42 contatos novos, a conclusão apressada seria de integração perfeita, mas só a conferência individual revelaria se algum deles veio de outra origem enquanto um envio real ficou de fora.

Falhas comuns e quem investiga

As causas abaixo são possibilidades a verificar, não um diagnóstico de qualquer operação específica. A divisão de responsabilidade também é sugestão e deve ser adaptada ao seu time.

• Validação que barra o contato legítimo: a web.dev explica que o navegador valida o formato no front-end e que os dados também precisam ser validados no servidor antes de serem armazenados ou compartilhados. Se as regras dos dois lados divergem, um envio aceito na tela pode ser recusado depois. Responsável sugerido: quem mantém o site.
• Campo obrigatório no CRM sem equivalente no formulário: o registro pode ser rejeitado por falta de dado. Responsável: quem administra o CRM.
• Filtro de spam agressivo: a web.dev cita CAPTCHA e campo oculto (honeypot) como proteções contra robôs e lembra que elas precisam continuar utilizáveis por pessoas reais. Se mal configuradas, podem descartar contatos legítimos. Responsável: site, com apoio de marketing.
• Conexão interrompida ou credencial vencida: a automação que liga site e CRM pode parar sem aviso. Responsável: quem criou ou mantém a integração.
• Duplicidade tratada como contato já existente: o CRM pode fundir ou ignorar o novo envio, e a nova mensagem não chegar a quem atende. Responsável: administração do CRM e comercial.
• Atraso na chegada: o registro existe, mas aparece horas ou dias depois. Compare o horário do envio com o da criação no CRM e defina de antemão o prazo aceitável para o seu fluxo de atendimento.

Como decidir se vale revisar

Em vez de adotar um limite de perda aceitável tirado de média de mercado, defina uma regra verificável. Uma proposta: a integração passa na semana quando 100% dos envios reais têm correspondência no CRM dentro do prazo combinado, e cada exceção (teste interno, spam filtrado de propósito) está anotada na planilha com a justificativa. Envio real sem correspondência, ou fora do prazo, entra como divergência a investigar, sem tolerância implícita.

Com essa regra, o resultado de cada semana fica claro. Se todas as linhas têm correspondência ou exceção documentada, a planilha funciona como monitor. Se as mesmas causas reaparecem ao longo de várias semanas, a revisão tem justificativa concreta. Uma semana limpa, porém, mostra apenas que aquela semana passou na conferência, e não garante o comportamento das seguintes. Se o volume conferido foi parcial, vale lembrar que o que ficou fora da amostra continua sem verificação.

Há ainda a questão dos dados pessoais. A web.dev recomenda coletar o mínimo necessário, usar HTTPS e tratar com cuidado as informações pessoais. Ao revisar a integração, verifique se cada campo enviado ao CRM é realmente usado. Também vale rever as perguntas do formulário, assunto de perguntas no formulário de primeiro contato.

Comece com um formulário e uma janela fixa, registrando identificação e horário de cada envio. A lista de divergências deve mostrar quem investiga e qual prazo falta cumprir. Nas semanas seguintes, verifique se os mesmos problemas reaparecem: é essa recorrência, junto das falhas encontradas, que orienta a revisão da integração.