Skip to content

How to recognize the same customer across channels

Phone, email, tax ID and app login carry different weights. Here is how to unify customer identity across channels for AI agents without exposing data.

Niadra team

Identity7 min read

To recognize the same customer on WhatsApp, voice, email and your app, you match the identifiers each channel provides (phone number, email, tax ID, app login) and give each one a weight, because none of them proves on its own who is on the other end. Every link between two identifiers is recorded with its source and a confidence level, and it can be undone without losing history. The AI agent receives a context that changes with how much the conversation has already proven about who the person is: before verification, what it needs to help; after verification, the sensitive data.

Why does each channel identify the customer differently?

Each channel hands over its own identifier, and none was designed to talk to the others.

  • WhatsApp usually gives you the number of whoever is writing. The platform's official documentation warns that the sender ID may not match the customer's phone number, and usernames bring a business-scoped user ID, different for every business.
  • Voice gives you the calling number, which can be spoofed, arrive hidden or belong to a PBX (which identifies the company, not the caller). The call authentication the FCC requires from carriers (STIR/SHAKEN) vouches for the line, not for whoever is speaking.
  • Email confirmed through a link is worth more than an address typed into a form.
  • The app gives you a login with a password, the strongest identifier, but only for people who installed the app and signed in.
  • A tax ID spoken on a call shows that the person knows the number, not that it belongs to them.

Without a user ID valid on every channel, identity has to be assembled from the clues each conversation leaves behind.

The first contact creates the customer, anchored to whatever identifier the channel provided. If the company already has a CRM or app ID, it comes in as one more identifier, with a high weight. Each identifier then gets a weight based on what it proves:

  • A phone number is a hint: the number may have a new owner.
  • A tax ID given on a call is stated: the person said it, and nothing confirmed it.
  • An email confirmed through a link is verified.
  • An app login with a password is authenticated.

Two identifiers become the same customer when there is evidence. The company's system reports that app login 88213 has that phone number, or the person confirms a code sent to the number. A similar name never links profiles.

Every link is recorded as an assertion, with its method, date and source. Every fact in memory stays tied to the identifier and the conversation it came from, not to the profile. That is why a wrong merge can be undone: once the assertion is retracted, the facts go back to their rightful owner.

Three rules guard against the wrong merge:

  • Two already authenticated profiles never merge on their own. That merge requires a person, with their name and reason on record.
  • Test values, such as 0000000000 or the tax ID 000-00-0000, never become a merge key.
  • An identifier shared by many customers (a store's phone line, a company PBX) is flagged as ambiguous and never links profiles.

What happens when a phone number gets a new owner?

Carriers reassign disconnected numbers to new subscribers as standard practice. Princeton University researchers held 200 recycled numbers for a week, and 19 of them were still receiving sensitive calls and messages meant for the previous owner, such as authentication passcodes. In customer service, if the phone number is the key, the AI agent greets the new owner by the old owner's name and reads out someone else's bills.

Four practices handle this risk without deleting anything:

  1. Trust in a phone number fades with disuse. NIST asks each organization to decide when to reverify an identity after extended inactivity.
  2. Signs of a break raise suspicion at any time, such as a "who is this?" in the first message or a login with a tax ID that differs from the owner on file.
  3. The link between the number and the customer is suspended, not deleted. The conversation opens an empty provisional profile, and the previous owner's history stays stored, out of the context.
  4. The confirmation reveals nothing. The agent asks for something the real owner would type without effort (tax ID, email, order number) and checks it silently. It never asks "is this Marina?", because the question gives the name away.

If the confirmation matches, the full context comes back. If it does not, the number gets a new customer, and Marina's history stays intact.

How do you verify identity during the conversation?

Recognizing tells you which customer is probably in the conversation. Authenticating proves it is them, and the NIST guidelines cover the two in separate volumes. With progressive verification, the conversation moves up a level with each new proof:

Level What the conversation has proven
0. Stated The person said who they are
1. Plausible by channel The source is already linked to the customer
2. Attested by channel The network or platform attests that the source was not spoofed
3. Challenged The person confirmed a code sent to the channel, or signed in with a password
4. Documented The data matches the company's records, or a human agent confirmed it

The level only rises through an explicit event, such as a confirmed code, never through an AI model's inference. In code, the agent requests the context again when the level goes up:

# While the phone rings: only the calling number identifies the customer (level 1)
ctx = niadra.context(phone=caller_id, channel="voice")

# SMS code confirmed: the conversation moves up to level 3
ctx = niadra.context(phone=caller_id, channel="voice", verification="otp")

# During the conversation: the agent searches the customer's history
hits = niadra.search("credit for missed technician visit", customer=ctx.customer)

What does the AI agent receive before and after verification?

At 2:02 pm, Marina tells the WhatsApp agent from vendor A that the technician visit promised for this morning never happened. At 2:05 pm, she disputes her August bill in the app. At 2:07 pm, she calls, and the voice agent from vendor B picks up.

Her number was already linked to her profile, so the call starts at level 1. The context that arrives before the hello carries her name, the missed visit (WhatsApp, 2:02 pm), the open dispute (App, 2:05 pm) and a note that an earlier visit had also been missed (Phone, Mar 12). The company's policy requires level 3 for billing and credit data, so those details are held back.

Marina confirms the code sent by SMS, and the agent requests the context again, now with the held-back items. When she mentions that she got a credit last time, the agent searches the history and finds the record from Mar 12, by phone: the technician did not show up, and a $40 credit was applied to the April bill.

Privacy is built into the design: a caller using a spoofed number gets at most what the company released for the lowest level, and no sensitive data. That is the data minimization the GDPR and the LGPD call for, applied to every moment of the conversation.

How Niadra handles it

Niadra matches phone, email, tax ID and app login into one customer, with a confidence level. Every piece of information stays linked to the identifier it came from, which is why Niadra splits two people merged by mistake without losing the history of either. The context changes according to how much the conversation has already proven about who the person is, across five verification levels, and reaches the agent in under 100 ms, with the source of every fact. Sensitive data only shows up after confirmation and is masked before it reaches any model. Every read goes into an audit trail chained by SHA-256. See the identity engine in Products and the protection layers in Security.

Frequently asked questions

Do I need a single user ID before running AI agents on several channels?

No. The first contact on any channel creates the customer, from the identifier that channel provided. A CRM or app ID, if you have one, comes in as one more identifier, with a high weight.

Is a phone number enough to identify the customer?

No. The calling number can be spoofed, arrive hidden, belong to a PBX or have a new owner. It is good for recognizing the likely customer, and sensitive data requires stronger proof, such as a confirmed code or a login.

What happens if two people are merged by mistake?

Niadra splits them without losing the history of either. That works because every piece of information stays linked to the identifier and the conversation it came from, not to the profile.

How does progressive verification protect customer privacy?

The AI agent receives only what the current level of the conversation allows. A caller using a spoofed or recycled number never hears another person's amounts or bills.

The next agent can already show up knowing.

Tell us what you are building. The people who reply are the people who write the code.