Cadastros do CRM, CRM antigo, sistema de locação e ERP
Normalização e casamento em cascata, com o nome validando
Pessoa única com papéis e ids de origem
Campanhas, cadastro de volta ao CRM e agente de IA
O que resolve
- A imobiliária sabe que o locatário de hoje é o lead de compra de ontem e o proprietário de outro imóvel.
- Campanhas saem sem mandar a mesma mensagem três vezes para a mesma pessoa.
- Ninguém funde duas pessoas porque dividem o telefone da recepção ou o e-mail do corretor.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Todos os sistemas com cadastro de pessoa conectados na Nekt
- A lista de e-mails e telefones internos (corretores, recepção, financeiro) que não podem servir de chave
- Uma pessoa do time para revisar os casamentos duvidosos
O que você recebe
- Uma tabela de pessoas com o melhor contato e todos os ids de origem
- Uma tabela de vínculos com cada papel, fonte e status
- Uma fila de revisão para os casamentos duvidosos
- Um agente de IA que responde quem é a pessoa e qual a história dela com a empresa
Onde ativar
Listas por papel e segmento a partir de uma pessoa por linha, com o melhor contato e sem duplicidade entre sistemas.
Responde quem é a pessoa, quais papéis ela teve e qual foi a última interação, avisando quando o casamento ainda está em revisão.
Grava no CRM o código do cliente nos outros sistemas e o contato corrigido, alimentando a regra 1 nas próximas execuções.
Normalizar telefone e documento é rápido. O trabalho está na revisão dos casos duvidosos e em manter as fusões estáveis a cada execução. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
A mesma pessoa existe no CRM de vendas, no CRM antigo, no sistema de locação e no ERP, com ids diferentes, telefone em quatro formatos e o e-mail do corretor no lugar do dela. Quem junta por telefone ou e-mail sem limpar funde famílias inteiras numa pessoa só. Quem não junta conta três clientes onde há um e manda a mesma campanha três vezes.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
CPF e CNPJ ficam só com dígitos, completados com zeros à esquerda até 11 ou 14 (documento lido como número perde o zero). Valide o dígito verificador. 11 dígitos é pessoa física, 14 é jurídica; marcadores no nome (ltda, me, s/a, eireli) confirmam PJ quando o documento falta. Documento inválido vira nulo, nunca chave.
Deixe só dígitos e leve tudo para 55 + DDD + número, com 13 dígitos para celular. Com 12 dígitos e número começando em 6 a 9, falta o nono dígito: insira. Com 10 ou 11 dígitos, falta o 55. Sem DDD, use o DDD da praça da imobiliária, declarado. 14 dígitos ou mais vira nulo. Cada pessoa guarda todos os telefones válidos num array e um telefone principal, com celular na frente de fixo.
E-mail em minúsculas, sem espaços, validado por expressão regular. Mantenha uma lista de bloqueio com e-mails da própria imobiliária (corretores, financeiro, atendimento) e de preenchimento (naotem@, sememail@). E-mail usado por mais de uma pessoa no mesmo sistema fica marcado como compartilhado e não serve para fundir. Como principal, prefira o e-mail pessoal ao corporativo.
Colete os pares de todas as regras de uma vez e fique, para cada cadastro, com a regra de menor número: 1) id de um sistema gravado no outro (campo do CRM com o código do cliente no Vista ou no sistema de locação); 2) CPF ou CNPJ válido; 3) e-mail e telefone batendo juntos; 4) só e-mail; 5) só telefone. Grave a regra usada e a quantidade de candidatos em cada linha.
Nos casamentos por e-mail ou telefone, compare o nome normalizado (sem acento, sem títulos e sem 'de', 'da', 'dos') pela maior similaridade entre ordenar e conjunto de palavras. Uma régua usada na prática: 95 ou mais é exato, 80 alto, 60 médio, 40 baixo, abaixo disso improvável. Baixo e improvável vão para revisão, não para fusão.
A pessoa é uma só; comprador, vendedor, proprietário, locatário, locador, fiador, investidor e lead são vínculos dela, um por papel, fonte e ocorrência. O status de cada papel resume os vínculos por prioridade fixa: ativo > lead aberto > encerrado > lead perdido > desconhecido. Quem tem um contrato ativo e um lead perdido no mesmo papel aparece como ativo.
Mesmo CNPJ válido é a mesma empresa, mesmo com nomes diferentes (um cadastro pode estar com o nome do sócio). Mesmo CPF só funde se o nome ou o e-mail também bater, porque CPF digitado errado ou de familiar é comum. O CPF do sócio nunca se funde com o CNPJ da empresa.
Escolha o contato principal pela completude (documento, e-mail, telefone, nome e data de nascimento preenchidos), desempatando pelo registro mais antigo e depois pelo id, para o resultado não mudar entre execuções. Na prática, o CRM de vendas costuma ter telefone e e-mail melhores que o sistema de locação, então ele entra primeiro na escolha campo a campo. Datas de nascimento antes de 1930 viram nulo.
Casos duvidosos vão para uma fila com o par de ids, o motivo e a evidência. A aprovação funde exatamente aquele par. Um par marcado como não fundir nunca mais é fundido, nem pela regra automática. Só marque um item como fundido depois que a fusão entrou no mapa de ids.
Quando duas pessoas viram uma, todo evento, vínculo e negócio gravado no id absorvido é remapeado para o id sobrevivente, resolvendo cadeias (A virou B, B virou C). Rode o remapeamento logo depois da fusão e confira que o número de linhas não mudou.
Ordem do casamento
A regra de menor número vence; casamentos 3 a 5 passam pela validação do nome.
Definições
Armadilhas que já aconteceram
Quase toda a fila de revisão era de telefone compartilhado: recepção, família, corretor que cadastra o próprio celular.
Aplique um teto de frequência ao telefone e mande à revisão só os casos com documento ou nome em conflito.
Telefones de 11 dígitos foram tratados como documento numa aprovação de fusão, e um deles bateu com o CPF de outra pessoa.
A fusão aprovada executa pelo par de ids, nunca pelo valor da chave.
Cadastros com o e-mail do corretor no lugar do e-mail do cliente viraram uma única pessoa.
Lista de bloqueio com os e-mails internos e marca de e-mail compartilhado.
A pessoa foi unificada, mas os eventos ficaram no id absorvido e o histórico dela apareceu vazio.
Remapeie a linha do tempo a cada fusão.
Itens aprovados eram marcados como executados mesmo quando a fusão não acontecia, e a fila parecia limpa.
Só marque executado o que entrou no mapa de ids.
Telefones antigos do sistema de locação vinham com 8 ou 9 dígitos e não casavam com nada.
Complete com o DDD da praça, declarado, e marque o telefone como inferido.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Cada id de origem aponta para exatamente uma pessoa no mapa de ids.
- Nenhum e-mail ou telefone da lista de bloqueio aparece como chave de casamento.
- Para uma amostra de 50 pessoas fundidas por e-mail ou telefone, a revisão manual confirma pelo menos 48 como a mesma pessoa.
- Rodar o processo duas vezes sem mudança nas fontes gera os mesmos ids mestres e o mesmo contato principal.
- A contagem de eventos e vínculos antes e depois de uma fusão é a mesma.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Base única de clientes - Uma pessoa = um id mestre. A tabela de vínculos tem uma linha por pessoa, papel, fonte e ocorrência. - Papéis: lead, comprador, vendedor, proprietário, locador, locatário, fiador, investidor. Papel é vínculo, não identidade. - Status por papel com prioridade: ativo > lead aberto > encerrado > lead perdido > desconhecido. - Para contar clientes de um papel, filtre status = ativo. Nunca conte linhas de vínculo sem filtrar status. - Casamento em cascata: 1 id cruzado, 2 CPF/CNPJ, 3 e-mail e telefone, 4 e-mail, 5 telefone. A coluna regra_match diz qual regra ligou o cadastro. - CPF com 11 dígitos, CNPJ com 14, só dígitos e validados. PF e PJ nunca se fundem. - Telefone no formato 55 + DDD + número. E-mails internos e compartilhados não são chave. - Pessoas na fila de revisão ainda não estão fundidas. Ao responder, diga que o casamento é provável, não confirmado. - Contato apto para campanha: nome e e-mail ou telefone válido, sem bloqueio e sem opt-out. Exceções por cliente: - <cliente>: DDD padrão da praça <DDD> para telefones sem DDD. - <cliente>: o campo <campo> do CRM guarda o código do cliente no sistema de locação e é a regra 1.
Construa no meu workspace Nekt o caso "Base única de clientes" seguindo as regras em https://academy.nekt.com/industrias/imobiliario/base-unica-clientes.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Construtora e concessionária, ou incorporadora e administradora: uma pessoa por documento com quantidade, valor e data da última compra em cada negócio.
Sem documento em comum, um modelo de pareamento com nome, sobrenome, e-mail, telefone e data de nascimento sugere pares, que passam pela mesma fila de revisão.
Hóspede, proprietário e investidor da mesma pessoa, com status próprio de hóspede (reserva concluída, cancelada, nunca reservou).