Omnichannel is an identity problem, not a channel count

Almost every vendor in this category says it is "omnichannel". Most mean "we support several channels". Those are different claims.

• Multichannel: you can reach customers on several channels — email, SMS, WhatsApp, chat, phone.
• Omnichannel: those channels share one memory of the customer, so a conversation can move between them without starting over.

The test is simple. A customer emails on Monday. On Wednesday they message on WhatsApp about the same problem. Does the second conversation know about the first?

If yes, you are omnichannel. If no, you have several single-channel tools sharing a login. The number of channels has nothing to do with the answer.

Because recognising the same person across channels is genuinely difficult, and buying software does not solve it on its own.

The same person is an email address on one channel, a phone number on another, and on some social messaging platforms an ID that is deliberately not their phone number and differs for each business. Often nothing reliable links them.

Systems that "solve" this with fuzzy matching — guessing that two records are the same person because the names and cities look alike — create a worse problem: confidently merging two different people. In support, that means showing one customer another customer's history. That is a data-protection incident, not a bug.

A customer record that owns identifiers, rather than being one. The customer is the entity. Email addresses, phone numbers and platform IDs are attached to it, each with its own verification state and its own consent state.

Each identifier has a state, not just a value.

"Retired" is the state most systems leave out, and it causes the worst failures. Phone numbers are reassigned to new people — common enough that the United States runs an official Reassigned Numbers Database so businesses can check before contacting a number. A work email address belongs to someone else months after a person changes job.

Explicit linking events. Record how two identifiers came to be connected: the customer clicked a link while logged in, quoted an order number, or verified a code. Store the evidence, not just the conclusion, so you can undo it when you are wrong.

Consent per identifier and per channel. Permission to email is not permission to message on WhatsApp. One global "opted in" flag is the most common way a merged record becomes a compliance problem. See consent is a data model.

When two records look like the same person, the safe operation is not a merge. It is a link with evidence and a way back: keep both records, record the link and why, and show the combined view. If the link proves wrong, remove it and both records are intact.

A destructive merge cannot be undone, and you usually discover it was wrong from a customer who saw something they should not have. Merge destructively only on an exact match of a verified identifier, and log even those.

The honest options are all better than guessing:

• Ask. "Is this the same account as your email?" is a normal question, and customers answer it.
• Use a logged-in moment. If they click through from a message while signed in to your app, that is proof, and it costs nothing to capture.
• Keep them separate, with a note. Two records marked "possibly related" is worse than one correct record, and far better than one wrong record.

The technical problem is the easier half. Channels usually map to teams, teams to budgets, and budgets resist merging. A single customer view built over data that three departments each consider theirs is an organisational negotiation with a database attached. Agree who owns the customer record before choosing the tool.

To see how big your identity problem is, count repeat contacts about the same issue that arrive on a different channel from the first. It is a small query and it is unambiguous: each one is a customer who had to start again. Most organisations are surprised by the number, and it is the number that justifies the work.

• Conversational marketing, minus the hype — the next step in this track.
• Designing a journey that branches — putting one customer record to work.
• Consent is a data model — why permission belongs to each identifier.