Imobiliário · Base de clientes

Base única de clientes

Uma linha por pessoa juntando o CRM de vendas, o CRM antigo, o sistema de locação e o ERP, com cada papel dela (comprador, proprietário, locatário, fiador) e o motivo de cada fusão.

UsoComum
EsforçoAlto
Para quemImobiliárias e grupos imobiliários com o mesmo cliente espalhado em vários CRMs, no sistema de locação e no ERP.
Fonte

Cadastros do CRM, CRM antigo, sistema de locação e ERP

Regra

Normalização e casamento em cascata, com o nome validando

Resultado

Pessoa única com papéis e ids de origem

Ativação

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.

Quantos clientes únicos temos somando todos os sistemas?
Quais locatários atuais já foram leads de compra?
Essa pessoa já foi proprietária ou investidora com a gente?
Quantos contatos estão duplicados no CRM, e entre quais sistemas?
Quantos clientes têm telefone e e-mail válidos para campanha?

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

Campanhas e reativação

Listas por papel e segmento a partir de uma pessoa por linha, com o melhor contato e sem duplicidade entre sistemas.

Agente de IA via MCP

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.

Cadastro de volta ao CRM

Grava no CRM o código do cliente nos outros sistemas e o contato corrigido, alimentando a regra 1 nas próximas execuções.

Quer construir?

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.

Ver detalhado
O problema

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.

O jeito comumA regra
01
Casar pelo documento como veio do sistema, com pontos e zeros perdidos.
Documento só com dígitos e validado

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.

02
Comparar telefones como vieram, com e sem 55, com e sem o nove.
Telefone no formato canônico

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.

03
Juntar por e-mail sem filtro e fundir todos os clientes de um corretor.
E-mail interno e compartilhado não é chave

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.

04
Juntar por qualquer chave que bater, na ordem em que as consultas rodaram.
Casamento em cascata, da chave mais forte

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.

05
Fundir mãe e filho que dividem o celular da família.
O nome valida o casamento fraco

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.

06
Uma tabela de proprietários, outra de locatários, a mesma pessoa em cada uma.
Papel é vínculo, não identidade

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.

07
Fundir por CPF igual sem olhar mais nada.
PF e PJ não se fundem sozinhas

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.

08
Ficar com o último cadastro alterado.
O registro mais completo dá o contato

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.

09
Aprovar pelo telefone do item e fundir todo mundo com aquele telefone.
Revisão decide por par, e o veto vale para sempre

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.

10
Fundir as pessoas e deixar a linha do tempo no id antigo.
A fusão arrasta o histórico

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.

Código de um sistema gravado no outro1. Id cruzadoregra_match = 1
CPF ou CNPJ válido, só dígitos2. Documentoregra_match = 2
Mesmo e-mail e mesmo telefone3. E-mail e telefoneregra_match = 3
E-mail único, fora da lista de bloqueio4. E-mailregra_match = 4
Telefone canônico, não compartilhado5. Telefoneregra_match = 5
Nome com similaridade baixa ou improvávelFila de revisão
Nenhuma regra bateuPessoa nova

Definições

Pessoa
id mestre com todos os ids de origem ligados a ele; PF por CPF e PJ por CNPJ quando houver documento
Vínculo
uma linha por pessoa x papel x fonte x ocorrência (cada contrato, negócio ou imóvel), com status e datas
Clientes únicos
contagem distinta de pessoas com pelo menos um vínculo ativo, depois da fusão
Taxa de casamento por regra
cadastros de uma fonte casados por cada regra / cadastros da fonte, por execução
Completude
quantos de documento, e-mail, telefone, nome e data de nascimento estão preenchidos e válidos no registro, de 0 a 5
Contato apto para campanha
pessoa com nome e com e-mail ou telefone válido, não bloqueado e não compartilhado
Fila de revisão aberta
pares de cadastros com casamento duvidoso ainda sem decisão de fundir ou manter separados

Armadilhas que já aconteceram

Fila dominada por telefone

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.

Telefone com cara de CPF

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.

Clientes do corretor fundidos

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.

Jornada vazia depois da fusão

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.

Item fechado sem 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.

Base de segundo sistema sem DDD

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.

Pacote para o agente

Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.

Markdown completo
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.

Variações

Grupo com outra linha de negócio

Construtora e concessionária, ou incorporadora e administradora: uma pessoa por documento com quantidade, valor e data da última compra em cada negócio.

Casamento probabilístico

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.

Temporada e multipropriedade

Hóspede, proprietário e investidor da mesma pessoa, com status próprio de hóspede (reserva concluída, cancelada, nunca reservou).