Company and person matching, and the identity review queue

Signed in? Ask Lovelio this question inside the app - it answers from this same page.

Company names arrive spelled every way people spell them: "Fonterra", "Fonterra Co-operative Group Ltd" and "Fonterra Brands Takanini" are one dairy company recorded three ways. Lovelio keeps one organisation record per real company and treats every spelling as a pointer to it, so client records, candidate career history and BD targets all join up even when the names on them differ.

How a match is decided

A website domain is treated as fact: two records sharing a domain are the same organisation, no questions asked. This only counts a company's own domain. A LinkedIn or Facebook page, a company directory listing, a job board, a site builder or a personal email address is a page about a company, not the company, so it is ignored here - otherwise every client whose website was pasted as a LinkedIn link would become one organisation.
Known spellings are remembered. Once a spelling is linked to an organisation, every later lookup of that spelling answers instantly with no AI involved.
An unknown spelling goes to AI in two independent steps: one model picks the most likely organisation from a shortlist, then a second check verifies that single claim with nothing to choose from. Only a claim that passes both becomes a link. A refused claim never links anything.
Divisions, country arms, plants, sites and internal account labels of one company are merged into that company. Franchises, licensees and separately owned branch offices that share a brand stay separate businesses - "Ray White Remuera" is not "Ray White". Records carrying two different website domains are never merged, whatever the AI thinks.
A merge never deletes anything. The absorbed record is kept and every join is repointed, so a wrong merge can be unpicked.

Person matching

The same idea applies to people. A candidate and a client contact are often one human - somebody the agency placed is now the hiring manager sending them jobs. Lovelio finds those pairs from facts on the two records, with no AI involved: the same email address, the same LinkedIn profile, the same name and phone number, or the same name at the same organisation.

A strong, unshared signal links the pair automatically: same LinkedIn profile, same email address held by nobody else where the names match exactly, or same phone number where the names match exactly. These are the only three signals that link on their own, and each was measured 100% right on a real migrated book before being trusted.
Anything weaker goes to the review queue instead: names that only agree to an initial ("R Smith" and "Robert Smith"), an email where the names disagree, or a name-only match at a shared employer.
A shared signal never links on its own. An email address or phone number that appears on several records could be a shared inbox or an office switchboard, so those pairs go to the review queue too.
A link never changes either record. Both records stay exactly as they are; the link sits alongside them and can be removed.

Once a pair is linked (automatically or by a human), the link starts working: the Opportunities Inbox shows people you placed who are now contacts and warm contacts who moved, each client record's Opportunities tab lists the same facts under Private movement, and the person's record shows their roles. A pair still in the review queue surfaces nothing anywhere - a question is not a fact.

The People record

Every client contact IS a People record now, not just the linked pairs. The contact row on the client holds the relationship - the role title and the work email and phone at that client - while the person record holds the name and profile. Renaming a contact renames the person everywhere they appear, on every role. A person who exists only as a contact IS searchable: candidate search covers your candidates and your client contacts, because a hiring manager is a future candidate. The search panel's "Who it searches" control (or typing "candidates only" / "contacts only") narrows by role. They formally join the candidate pool - and start counting as a candidate in analytics, alerts and talent pool machinery - when they enter a process: added to a job, added to a talent pool, placed, or captured again deliberately as a candidate. Emailing rules do not change with searchability: approach email to a client contact still holds at the outbound gate exactly as before, whatever the search filter says.

A linked person has ONE record, seen from both sides. The header carries role chips instead of a plain "Candidate" label: Candidate, "Contact - {client}" for each live contact role, and "Placed {month}" if you placed them. The email cell shows one preferred address with a "+2" style count - click it to see every address, typed Personal, Work (owned by a contact role, client conversation only) or Stale (the role ended, retired automatically). A Roles tab tells the whole history on one rail: contact roles with the jobs they briefed and the fees billed, placements, and when they registered as a candidate.

Where you open the record from changes exactly four things and nothing else: which role chip leads, which address shows, which actions are primary (from a client, "Log a call" and "Email" the work address; elsewhere "Add to job" and "Email" as an approach), and whether the candidate-only detail folds (star rating, salary expectation and applications tuck behind "Show candidate detail" when you arrive from a client). The tabs, the Profile default and their career history are identical through every door. On a client's Contacts tab, clicking a linked contact opens this person record; the thin contact card stays in the row menu.

Off limits, and typed addresses

A person holding a live contact role at a client is off limits to approach mail - the header shows an amber "Off limits - {client}" chip. This means a contact somebody put on the client. Someone listed under "Works here" - derived because their own record says they work at a client - is NOT off limits: their record says "{name} works at a client" and mail still sends. Making them a contact is what turns the block on. An approach email to them is blocked, not just warned about, even at their personal address; a named person can click "Send anyway" (the override is logged on their record with the name), and automation never can. The block lifts on its own when the person's own record says they have left the client.

The link also types the person's email addresses by who owns them. The address on the candidate record is personal; an address that belongs to their contact role at a client is a work address, owned by that role, and it goes stale on its own when their record says the role ended. Outreach email (an approach) only ever goes to a personal address - if a person's only address belongs to their contact role, the send is held with that reason, a named person can override it, and automation never can. The full rules are on the email help card.

The review queue

Settings > Workspace > Review queue holds the questions Lovelio refused to decide on its own: company pairs where the first AI step proposed a match and the independent check refused it, and person pairs where the evidence was not strong enough to link automatically. Each row shows the two names, the evidence, and why it was flagged.

Two answers, and both stick:

Same company merges the company records everywhere, through the same door the automatic pass uses. Same person links the candidate and the contact as one human, and repoints the contact to the confirmed person - the contact row now carries that person's name and profile.
Keep separate is final - the question is never asked again, even by a full re-run of the matching pass.

Admins and team leaders can decide reviews. The same decision can be made from the AI assistant with "accept" or "reject" and the review in question.