The same person entered five times, each system holding one piece. The customer who is a family, not a company. The agent who replies without knowing whether he is talking to the account holder. bFocus keeps who signs apart from who uses — and holds one record per person, even when she shows up in several customers and several of your systems.
Merging the wrong records is worse than keeping two. That is why one single field merges people without asking: the CPF, the Brazilian individual tax number.
The same CPF is the same person, in any customer and in any of your systems. An identifier nobody has seen before arrives carrying a CPF that already exists? It lands on that person, and the new identifier starts leading to her.
Typing an email into a browser does not hand you somebody else account. Unsigned data coming from outside never merges records: it becomes a hint in the clean-up screen, for the team to decide.
If the record already has a CPF and another one arrives, the write stops and returns the conflict. Changing somebody CPF is a decision for a person, not for an integration.
One person is found by several identifiers. The ERP uses its own, the store uses its own, and the old code keeps working after a merge.
One primary and whatever extras arrive. Search matches all of them: the work address and the personal one lead to the same person.
If the email that arrived already belongs to someone on your team, the sync neither adopts nor changes that account. The person is created without that contact, and a hint is left for somebody to look at calmly.
The house rule is simple: nothing merges on a hunch. With no CPF, two similar records go into the possible-duplicates queue and a human decides.
Some customers are companies with thirty employees, and some are a family. The database takes both without contortions — and without turning a person into a company of herself.
kind, legal_name, state_registration, municipal_registration and id_document come through the public API and the spreadsheet with the same meaning they have on screen.
See the public APIThe accountant serves four companies. The consultant shows up in three. When two of your systems send that person, she cannot bounce from company to company.
With four products writing into the same company, automatic transfer moved the person to a different customer on every load — and the source system never noticed, because from its side nothing had changed.
Not every person arrives with a company attached. The list shows those who belong to some customer and those who belong to none yet.
Name, email, phone or identifier — the primary one and the extras. Paste the code from your ERP and the person shows up.
With access, Without access, In more than one customer, Without customer. And you can pin the list to one customer.
Her customers, her access at each one, identifiers, tickets and history, without leaving the list.
Link to one more customer, remove access at a single one, unlink from a customer. Before you confirm, the screen says what will happen and what stays.
Linked to one more customer, unlinked, transferred, records merged, identifier added, removed or promoted to primary.
The open person lives in the page address: you can send the link to a colleague, and the browser back button closes the panel.
When a hunch is not enough, the pair waits for a human. Four steps, no side spreadsheet.
At the top of the customer list: how many have a document, an email and people with access, how many possible duplicates exist and how many people arrived with no company attached. Every number filters the list.
Each pair comes with the why — same tax number, same email, same phone, very similar name, same CNPJ root for a branch office — and a Very likely or Likely mark.
For customers the merge goes field by field: you choose which side each one comes from, anything empty on the survivor is filled in from the one leaving, both sets of emails and phones stay, and to confirm you type the name of the record that goes. For people you choose who stays and the rest follows.
One click takes the pair out of the queue for good. Keeping two records costs far less than merging the records of two different people.
Outside the queue: people who arrived with no company attached get a customer suggestion — from the customer contact list, from their tickets or from their corporate email domain, never from gmail and the like — and the consistency check lists what is out of place, with a one-click fix whenever the fix is safe.
Nobody starts from zero. The records you already have come in by spreadsheet, and your systems keep sending through the API.
Seven official SDKs, extra identifiers that come back readable, and deleting a contact is explicit: null and absent still mean “do not touch”.
See the API and the SDKsA good database is also one you can account for. What exists today, with no dressing up.
Isolation per company, passwordless login, identity verified by signature and scoped keys are on the security page.
See security and privacyNo. This is records plus support: who signs, who her people are, and the history of tickets, conversations and projects. Prospecting and leads live in the Commercial module, which is another page.
No. What sits on a person record was sent by you, by your spreadsheet or by one of your systems. bFocus does have enrichment, but it belongs to the Commercial module, it works on the lead company (tax number and domain, from public sources) and not on the person.
Each one sends its own code. One becomes the primary identifier and the other stays as an extra identifier: both lead to the same record, and the list shows which is which and where it came from.
The write stops and returns a conflict. Nothing is swapped quietly: someone on your team looks at it and decides on screen.
No. Without it the database works just the same — it simply will not merge anyone on a hunch. Two similar records wait in the clean-up queue.
Yes. Access belongs to the link: removing it at one company does not touch the other. She is only switched off for good when no customer grants her access.
Everything from the one leaving moves to the one that stays: tickets, conversations, projects, tasks, notes and files. The identifier of the one leaving keeps working as an extra identifier, so the widget and the API still using that code do not break. It cannot be undone, which is why merging customers asks you to type the name of the one that goes.
Import the spreadsheet, look at the preview and open the duplicate queue. No card and no onboarding project.