--- title: "Omnichannel is an identity problem, not a channel count" summary: "The difference between multichannel and omnichannel is not how many channels you support. It is whether the customer has to repeat themselves." canonical: https://cpaas.co/en/insights/omnichannel-is-an-identity-problem kind: explainer depth: foundation origin: original published: 2026-08-25T11:34:07.986Z updated: 2026-09-08T11:34:08.070Z topics: ["Omnichannel", "Customer Experience", "Fundamentals"] language: en --- # Omnichannel is an identity problem, not a channel count Every vendor in this category will tell you they are omnichannel, and most of them mean "we support several channels". Those are different claims. ## The test A customer emails on Monday. They message on WhatsApp on Wednesday about the same problem. Does the second conversation know about the first? If yes, you are omnichannel. If no, you have several single-channel products sharing a login. The number of channels is irrelevant to the answer. ## Why it is hard Because identity across channels is genuinely difficult, and no amount of buying solves it. The same person is an email address on one channel, a phone number on another, and an opaque platform-scoped identifier on a third — one that is deliberately not their phone number, and that may differ per business. There is often no reliable key linking them. Systems that "solve" this with fuzzy matching create a worse problem: confidently merging two different people. In a support context that means showing one customer another customer's history. It is a data-protection incident, not a bug. ## What actually works **A contact record that owns identifiers, rather than being one.** The customer is an entity; email addresses, phone numbers and platform IDs are attributes attached to it, each with its own verification state and its own consent state. **Explicit linking events.** Record *how* two identifiers came to be associated — the customer clicked a link while authenticated, quoted an order number, verified a code. Store the evidence, not just the conclusion. When you are wrong, and you will be, you can unwind it. **Per-channel consent on the record.** Permission to email is not permission to message on WhatsApp. Modelling consent as one global flag is the most common way a merged contact record becomes a compliance problem. ## The organisational half The technical problem is the easier half. The harder half is that channels usually map to teams, teams map to budgets, and budgets do not want to merge. A unified customer view built by a platform team, over data three departments each consider theirs, is an organisational negotiation with a database attached. Sequence the work accordingly: the systems that fail are rarely the ones that got the schema wrong. ## The four states of an identifier A model that avoids most of the trouble treats every identifier as having a state, not just a value: **Claimed.** Somebody typed it. It might be a typo, someone else's number, or deliberate. **Verified.** They proved control of it — clicked a link, entered a code, replied. **Observed.** You saw it in an interaction you can attribute, such as an inbound message from it. **Retired.** It was theirs and is not now. That last state is the one nearly every system omits, and it causes the worst failures. ```diagram:flow # The four states of an identifier Claimed | Somebody typed it. It might be a typo, someone else's number, or deliberate. Verified | They proved control of it — clicked a link, entered a code, replied from it. Observed | You saw it in an interaction you can attribute, such as an inbound message. Retired | It was theirs and is not now. Numbers are recycled; work addresses change hands. > Systems that cannot express the fourth state keep reaching a stranger, with the previous customer's context attached. ``` Phone numbers are recycled. An email address at a former employer belongs to someone else within months. A contact record that has no way to express "this used to reach them" will keep reaching a stranger, with the previous customer's context attached. ## Merging safely When two records look like the same person, the safe operation is not a merge. It is a **link with evidence and a reversal path**: keep both records, record the link, record why, and treat the union as a view rather than a new object. If the link proves wrong you remove it and both records are intact. A destructive merge cannot be undone, and you generally discover it was wrong from a customer who has seen something they should not have. Merge destructively only for exact matches on a verified identifier, and log even those. ## What to do when you genuinely cannot tell Sometimes there is no reliable key. The honest options are all better than guessing: - **Ask.** "Is this the same account?" is a normal question and customers answer it. - **Use an authenticated moment.** If they are logged in and click through from a message, that is proof, and it costs nothing to capture. - **Keep them separate and say so internally.** Two records with a "possibly related" note is a worse experience than one correct record and a much better one than one wrong record. ## The measurement that reveals the truth If you want to know how bad your identity problem actually is, count **repeat contacts about the same issue arriving on a different channel from the original**. It is a small query and it is unambiguous: every one of those is a customer who had to start again. Most organisations are surprised by the number, and it is the number that justifies the work. ## What to take away - Model the customer as an entity that owns identifiers, not as one identifier. - Give every identifier a state, including retired. - Link with evidence rather than merging destructively. - Consent lives per identifier and per channel, never as one flag on the person. --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.