--- 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 — and that depends on how you recognise one person across many addresses." canonical: https://cpaas.co/en/learn/omnichannel-is-an-identity-problem kind: explainer depth: foundation origin: original published: 2026-09-30T16:26:18.899Z updated: 2026-10-14T16:26:19.420Z topics: ["Omnichannel", "Customer Experience", "Fundamentals"] language: en --- # 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 versus omnichannel - **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. ```diagram:compare | Multichannel | Omnichannel What it means | You can reach customers on several channels | Those channels share one memory of the customer Email on Monday, WhatsApp on Wednesday | The second conversation starts over | The second conversation knows about the first What the number of channels tells you | Nothing | Nothing > The test is one question about the second conversation, not a count of logos. ``` ## Why it is hard 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. ## The model that works **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.** ```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 history attached. ``` "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](https://www.fcc.gov/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](/en/learn/consent-is-a-data-model). ## 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 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. ## When you genuinely cannot tell 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. ```diagram:decision # Two records that look like the same person Do they share an exact match on a verified identifier? | Merge — and log it | Is there evidence: a logged-in click, a quoted order number, a verified code? | Link them with the evidence, keeping both records | Ask, or keep them separate and marked "possibly related" > A link can be removed and both records are intact. A destructive merge cannot be undone. ``` ## The organisational half 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. ## The number that reveals the truth 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. ## Where to go next - [Conversational marketing, minus the hype](/en/learn/conversational-marketing-defined) — the next step in this track. - [Designing a journey that branches](/en/learn/designing-a-journey-that-branches) — putting one customer record to work. - [Consent is a data model](/en/learn/consent-is-a-data-model) — why permission belongs to each identifier. ## Sources [^1]: [Reassigned Numbers Database](https://www.fcc.gov/reassigned-numbers-database) — Federal Communications Commission --- 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.