---
id: imobiliario/base-unica-clientes
industria: Imobiliário
uso: comum
esforco: alto
grao: Pessoa (id mestre) com arrays de ids de origem, telefones e e-mails; pessoa x papel x fonte para os vínculos
---

# 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.

## Resumo executivo

**Para quem:** Imobiliárias e grupos imobiliários com o mesmo cliente espalhado em vários CRMs, no sistema de locação e no ERP.

**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.

**Por que importa:** Imobiliária full service atende a mesma família como compradora, proprietária, locatária e fiadora, cada papel num sistema. Sem uma base única, o cross-sell é chute, a reativação dispara em duplicidade e o agente de IA não sabe com quem está falando. É o pré-requisito de segmentação, recorrência e devolução de cadastro ao CRM.

**Perguntas de negócio que responde**

- 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

## 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.

### Regras de negócio

1. **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. (Evite: Casar pelo documento como veio do sistema, com pontos e zeros perdidos.)
2. **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. (Evite: Comparar telefones como vieram, com e sem 55, com e sem o nove.)
3. **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. (Evite: Juntar por e-mail sem filtro e fundir todos os clientes de um corretor.)
4. **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. (Evite: Juntar por qualquer chave que bater, na ordem em que as consultas rodaram.)
5. **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. (Evite: Fundir mãe e filho que dividem o celular da família.)
6. **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. (Evite: Uma tabela de proprietários, outra de locatários, a mesma pessoa em cada uma.)
7. **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. (Evite: Fundir por CPF igual sem olhar mais nada.)
8. **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. (Evite: Ficar com o último cadastro alterado.)
9. **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. (Evite: Aprovar pelo telefone do item e fundir todo mundo com aquele telefone.)
10. **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. (Evite: Fundir as pessoas e deixar a linha do tempo no id antigo.)

### 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 outro** → 1. Id cruzado (`regra_match = 1`)
- **CPF ou CNPJ válido, só dígitos** → 2. Documento (`regra_match = 2`)
- **Mesmo e-mail e mesmo telefone** → 3. E-mail e telefone (`regra_match = 3`)
- **E-mail único, fora da lista de bloqueio** → 4. E-mail (`regra_match = 4`)
- **Telefone canônico, não compartilhado** → 5. Telefone (`regra_match = 5`)
- **Nome com similaridade baixa ou improvável** → Fila de revisão
- **Nenhuma regra bateu** → Pessoa nova

### Definições

| Métrica | Definição |
|---|---|
| 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

- **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. Como evitar: 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. Como evitar: 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. Como evitar: 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. Como evitar: 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. Como evitar: 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. Como evitar: Complete com o DDD da praça, declarado, e marque o telefone como inferido.

### Teste de aceitação

- [ ] 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.

### Context document

```text
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).