Records from the CRM, old CRM, rental system and ERP
Normalization and cascade matching, with the name validating
Single person with roles and source ids
Campaigns, contact data back to the CRM and AI agent
What it solves
- The brokerage knows that today's tenant is yesterday's purchase lead and the owner of another property.
- Campaigns go out without sending the same message three times to the same person.
- Nobody merges two people because they share the front desk phone or the broker's email.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- Every system with person records connected to Nekt
- The list of internal emails and phones (brokers, front desk, finance) that cannot be used as keys
- Someone on the team to review doubtful matches
What you get
- A people table with the best contact details and every source id
- A links table with each role, source and status
- A review queue for doubtful matches
- An AI agent that answers who the person is and their history with the company
Where to activate
Lists by role and segment from one person per row, with the best contact and no duplicates across systems.
Answers who the person is, which roles they have had and their last interaction, flagging when the match is still under review.
Writes into the CRM the client's code in the other systems and the corrected contact details, feeding rule 1 on the next runs.
Normalizing phone and document is fast. The work is in reviewing the doubtful cases and keeping merges stable on every run. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The same person exists in the sales CRM, the old CRM, the rental system and the ERP, with different ids, phones in four formats and the broker's email in place of theirs. Joining by phone or email without cleaning merges entire families into one person. Not joining counts three clients where there is one and sends the same campaign three times.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
CPF (individual tax ID) and CNPJ (company tax ID) keep only digits, left-padded with zeros to 11 or 14 (a document read as a number loses the leading zero). Validate the check digit. 11 digits is an individual, 14 is a company; markers in the name (ltda, me, s/a, eireli) confirm a company when the document is missing. An invalid document becomes null, never a key.
Keep only digits and bring everything to 55 + area code + number, with 13 digits for mobiles. With 12 digits and a number starting with 6 to 9, the ninth digit is missing: insert it. With 10 or 11 digits, the 55 is missing. With no area code, use the area code of the brokerage's market, declared. 14 digits or more becomes null. Each person keeps all valid phones in an array and one main phone, mobile ahead of landline.
Email lowercased, trimmed, validated by regular expression. Keep a block list with the brokerage's own emails (brokers, finance, support) and filler emails (naotem@, sememail@). An email used by more than one person in the same system is flagged as shared and cannot be used to merge. As the main email, prefer personal over corporate.
Collect the pairs from every rule at once and keep, for each record, the rule with the lowest number: 1) the id of one system stored in the other (a CRM field holding the client code in Vista or the rental system); 2) valid CPF or CNPJ; 3) email and phone matching together; 4) email only; 5) phone only. Store the rule used and the number of candidates on each row.
For matches by email or phone, compare the normalized name (no accents, no titles and no 'de', 'da', 'dos') using the higher of sorted-token and token-set similarity. A threshold used in practice: 95 or more is exact, 80 high, 60 medium, 40 low, below that unlikely. Low and unlikely go to review, not to a merge.
The person is one; buyer, seller, owner, tenant, landlord, guarantor, investor and lead are their links, one per role, source and occurrence. Each role's status summarizes the links by fixed priority: active > open lead > ended > lost lead > unknown. Someone with an active contract and a lost lead in the same role shows as active.
The same valid CNPJ is the same company, even with different names (a record may carry the partner's name). The same CPF merges only if the name or email also matches, because mistyped CPFs and relatives' CPFs are common. A partner's CPF never merges with the company's CNPJ.
Pick the main contact by completeness (document, email, phone, name and date of birth filled in), breaking ties by the oldest record and then by id, so the result does not change between runs. In practice, the sales CRM usually has better phone and email than the rental system, so it goes first in the field-by-field choice. Dates of birth before 1930 become null.
Doubtful cases go to a queue with the id pair, the reason and the evidence. Approval merges exactly that pair. A pair marked as do-not-merge is never merged again, not even by the automatic rule. Only mark an item as merged after the merge is in the id map.
When two people become one, every event, link and deal stored under the absorbed id is remapped to the surviving id, resolving chains (A became B, B became C). Run the remap right after the merge and check that the row count did not change.
Matching order
The lowest-numbered rule wins; matches 3 to 5 go through name validation.
Definitions
Pitfalls that already happened
Almost the whole review queue was shared phones: front desk, family, a broker who registers their own mobile.
Apply a frequency cap to phones and send to review only cases with a conflicting document or name.
11-digit phones were treated as documents in a merge approval, and one of them matched another person's CPF.
An approved merge runs by id pair, never by the key value.
Records with the broker's email in place of the client's became a single person.
Block list with internal emails and a shared-email flag.
The person was unified, but the events stayed under the absorbed id and their history showed up empty.
Remap the timeline on every merge.
Approved items were marked as executed even when the merge did not happen, and the queue looked clean.
Only mark as executed what entered the id map.
Old phones from the rental system came with 8 or 9 digits and matched nothing.
Complete with the market's area code, declared, and flag the phone as inferred.
Acceptance test
The case is done when every item passes.
- Every source id points to exactly one person in the id map.
- No email or phone on the block list appears as a matching key.
- For a sample of 50 people merged by email or phone, manual review confirms at least 48 as the same person.
- Running the process twice with no change in the sources produces the same master ids and the same main contact.
- The count of events and links before and after a merge is the same.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Single customer base - One person = one master id. The links table has one row per person, role, source and occurrence. - Roles: lead, buyer, seller, owner, landlord, tenant, guarantor, investor. A role is a link, not an identity. - Status per role by priority: active > open lead > ended > lost lead > unknown. - To count clients in a role, filter status = active. Never count link rows without filtering status. - Cascade matching: 1 cross id, 2 CPF/CNPJ, 3 email and phone, 4 email, 5 phone. The regra_match column says which rule linked the record. - CPF with 11 digits, CNPJ with 14, digits only and validated. Individuals and companies never merge. - Phone in the format 55 + area code + number. Internal and shared emails are not keys. - People in the review queue are not merged yet. When answering, say the match is probable, not confirmed. - Campaign-ready contact: name and a valid email or phone, not blocked and no opt-out. Client exceptions: - <client>: default market area code <area code> for phones with no area code. - <client>: CRM field <field> holds the client code in the rental system and is rule 1.
Build the "Single customer base" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/imobiliario/base-unica-clientes.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Builder and car dealership, or developer and property manager: one person per document with quantity, value and date of last purchase in each business.
With no document in common, a record linkage model using first name, last name, email, phone and date of birth suggests pairs, which go through the same review queue.
Guest, owner and investor for the same person, with a guest-specific status (completed booking, cancelled, never booked).