CRM, e-mail e faturação: integrar dados sem criar duplicações

Ligar o CRM à plataforma de e-mail e ao programa de faturação é, tecnicamente, a parte fácil. Os três têm API. Em duas tardes há dados a circular nos dois sentidos.

O problema aparece três semanas depois, quando o mesmo cliente já existe quatro vezes e ninguém sabe qual das fichas é a boa. A integração de dados raramente falha nas ligações. Falha na identidade: na decisão, tomada antes de escrever a primeira automação, sobre o que faz de dois registos a mesma pessoa.

Quatro registos, um cliente

Uma padaria compra-lhe serviços. Veja o que os seus sistemas guardaram.

• No CRM: "Padaria Silva, Lda.", criada pelo comercial, com o e-mail pessoal do sócio.
• No programa de faturação: "PADARIA SILVA LDA", criada pela contabilidade, com NIF e morada fiscal.
• Na plataforma de e-mail: geral@padariasilva.pt, importado de um formulário do site.
• E outra vez na plataforma de e-mail, numa segunda audiência, o e-mail do sócio, recolhido numa feira.

Nenhum sistema está errado. Cada um guardou o que precisava de guardar. O CRM quer uma pessoa com quem falar, a faturação quer uma entidade fiscal, a plataforma de e-mail quer um endereço válido. São três definições diferentes de "cliente", e as três são legítimas.

O custo aparece quando os junta. O centro de ajuda do Mailchimp é explícito quanto a isto: se enviar a mesma campanha para duas audiências, um contacto que esteja nas duas recebe-a duas vezes. Não há aviso nenhum. Quem repara é o cliente.

O efeito mais caro, porém, é interno. Quando ninguém confia na ficha, toda a gente confirma tudo à mão antes de agir — e é assim que nasce grande parte do retrabalho entre equipas, que não aparece em relatório nenhum.

A chave decide-se antes da automação

Toda a integração de dados assenta numa chave: o campo que responde a "isto já existe?".

Em B2C, esse campo é quase sempre o e-mail. É único, é o próprio cliente que o escreve, e está presente nos três sistemas.

Em B2B português a resposta parece óbvia — o NIF — e é aqui que a coisa costuma correr mal.

O NIF é uma excelente chave para clientes empresariais. É atribuído pelo Estado, não muda com mudanças de morada nem de nome comercial, e o programa de faturação já o exige. Mas tem uma armadilha específica do mercado português: as faturas emitidas a consumidor final saem com o NIF genérico 999999990.

Se usar o NIF como chave sem tratar esta exceção, todos os clientes particulares colapsam num único registo gigante chamado "Consumidor Final". O resultado não é um duplicado. É o contrário de um duplicado: centenas de pessoas fundidas numa só, com o histórico de compras todo misturado. E, ao contrário de um duplicado, isto não salta à vista em nenhum relatório.

A regra prática é uma hierarquia, não uma chave única:

1. NIF, se existir e for diferente de 999999990.
2. E-mail normalizado, quando não há NIF utilizável.
3. Se não houver nenhum dos dois, cria-se um registo novo e marca-se como não confirmado. Nunca se adivinha.

O terceiro ponto é o que separa uma integração que envelhece bem de uma que vai apodrecendo devagar. Fundir dois registos por semelhança de nome é rápido de programar e praticamente impossível de desfazer.

Validar a chave, não confiar nela

Uma chave só serve se estiver certa. Um NIF mal digitado cria um cliente novo com a mesma eficácia com que criaria um duplicado.

Duas verificações resolvem a maior parte dos casos, e ambas correm em milissegundos.

A primeira é o dígito de controlo. O NIF português tem um dígito verificador calculado a partir dos oito anteriores. Um erro de digitação falha essa conta quase sempre. São dez linhas de código e apanham o problema antes de ele entrar no sistema.

A segunda é a validação externa. Para clientes empresariais, o sistema VIES da Comissão Europeia confirma se um número de IVA está registado e, consoante o Estado-Membro, devolve o nome e a morada oficiais. Serve para duas coisas: rejeitar números inválidos e preencher a ficha com a designação oficial, em vez de aceitar a variação que o comercial escreveu à pressa.

Vale a pena saber o que o VIES não faz. É um serviço público, sem chave de API, com indisponibilidades por país e sem garantia de tempo de resposta. Uma automação que dependa dele para gravar tem de tolerar falhas: guardar o registo, marcar a validação como pendente e voltar a tentar mais tarde. Bloquear a criação de um cliente porque um serviço externo está em baixo é trocar um problema pequeno por um maior.

No e-mail, normalizar significa pouco mais do que cortar espaços e passar tudo a minúsculas. Resista à tentação de ir além disso. Remover pontos, ou tudo o que vem depois de um sinal de mais, funciona no Gmail e está errado em muitos outros servidores — vai fundir pessoas diferentes.

Escrever com upsert, nunca com create

Esta é a mudança técnica com maior retorno e a menos discutida.

Uma automação que faz "criar cliente" cria um cliente sempre que corre. Se o fluxo repetir por causa de um tempo de espera esgotado, de uma nova tentativa automática ou de um webhook entregue duas vezes — coisas normais, não excecionais — fica com dois registos iguais.

A alternativa é o upsert: escrever contra a chave, não contra o sistema. "Se existir um cliente com este NIF, atualiza; se não existir, cria." A operação passa a ser idempotente. Correr dez vezes dá o mesmo resultado que correr uma.

A documentação da API REST da Salesforce descreve bem o mecanismo, e um detalhe que costuma passar despercebido: se a chave corresponder a mais do que um registo, a operação falha com erro e não escreve nada.

À primeira vista parece um defeito. É o contrário. Significa que o sistema se recusa a decidir sozinho quando os dados são ambíguos, e devolve o caso a uma pessoa. Uma automação que falha alto uma vez por mês é muito melhor do que uma que duplica em silêncio todos os dias.

Nem todas as ferramentas expõem upsert nativo. Vários programas de faturação obrigam a pesquisar primeiro e a criar depois — dois pedidos em vez de um. Funciona, desde que a pesquisa seja feita pela chave e não pelo nome, e desde que o fluxo trate o caso de dois pedidos simultâneos para o mesmo cliente.

Os duplicados que já lá estão

Há aqui uma nota que raramente é dita e que muda o plano de limpeza.

Nos programas de faturação certificados pela Autoridade Tributária, um documento emitido não se apaga nem se altera. É isso que a certificação garante. A consequência prática é direta: não pode simplesmente fundir duas fichas de cliente que já emitiram faturas, porque os documentos ficam ligados à ficha que os emitiu.

O que se faz é diferente e mais chato. Escolhe-se o registo canónico, marcam-se os restantes como inativos, impede-se a emissão de novos documentos contra eles, e guarda-se um mapeamento dos identificadores antigos para o novo — para que os relatórios históricos continuem a somar bem.

No CRM e na plataforma de e-mail há mais liberdade. Mas mesmo aí, funde-se com registo do que foi fundido. Uma fusão sem histórico é irreversível e, mais cedo ou mais tarde, alguém vai precisar de a reverter.

O que a ferramenta resolve e o que não resolve

Se estiver a montar isto numa plataforma de automação como o n8n, o nó Remove Duplicates trata a parte de execução: descarta itens repetidos dentro do mesmo lote e, no modo "Value Is New", lembra-se de valores já processados em execuções anteriores.

É útil, e tem limites que convém conhecer antes de confiar nele. Por defeito guarda 10.000 itens de histórico — passado esse volume, os mais antigos saem e um registo antigo pode voltar a ser tratado como novo. E esse histórico é, por defeito, do nó, não do fluxo: dois nós diferentes não partilham memória a não ser que se mude o âmbito para "workflow".

A distinção importante é esta. Isto é uma proteção ao nível da execução, não gestão de identidade. Impede que o mesmo evento seja processado duas vezes. Não impede que dois eventos diferentes criem duas fichas para o mesmo cliente. Para isso, a chave tem de estar no sistema de destino, com restrição de unicidade — não na plataforma que orquestra.

Quanto custa não resolver isto

Aritmética simples, com os pressupostos à vista. Não é um estudo; é uma conta que pode refazer com os seus números.

Uma empresa com três sistemas e cerca de 1.500 fichas de cliente:

• Antes de cada campanha, alguém exporta três ficheiros e cruza-os numa folha de cálculo: 3 horas.
• Dez campanhas por ano: 30 horas.
• Faturas emitidas com dados desatualizados e depois corrigidas: duas por mês, 20 minutos cada, incluindo a nota de crédito e o telefonema. Dá 8 horas por ano.
• Total: cerca de 38 horas anuais em trabalho que não produz nada.

Trinta e oito horas não justificam um projeto de gestão de dados com esse nome. Justificam meia dúzia de dias a definir a chave, acrescentar validação e trocar os create por upsert. Para converter estas horas em euros com o custo-hora real da sua equipa, o método está no artigo sobre quanto custam os processos manuais.

E o custo maior nem sequer entra nesta conta: é a decisão tomada a partir de um relatório que conta o mesmo cliente três vezes.

Por onde começar

Não comece pela ferramenta. Comece por uma pergunta que se responde numa reunião de vinte minutos: qual é o campo que, na sua empresa, define que dois registos são o mesmo cliente?

Se a resposta for imediata e igual para toda a gente à volta da mesa, a integração de dados vai ser mais simples do que parece. Se cada pessoa der uma resposta diferente, acabou de encontrar o problema — e ele não é de software.