A customer emails on Monday about a delivery. Tuesday they follow up on WhatsApp because it is faster. Wednesday they phone, and the person who answers asks them to explain the problem from the beginning.
That third interaction is where the relationship gets damaged, and it is not the agent's fault. They genuinely cannot see the first two.
Multichannel is not omnichannel
Most companies that describe themselves as omnichannel are multichannel, and the difference is not marketing pedantry — it is architectural.
Multichannel means you are reachable in several places. Email goes to a shared inbox, WhatsApp lives in a business app on someone's phone, calls hit a phone system, chat sits in a widget with its own dashboard. Four channels, four systems, four separate histories.
Omnichannel means the conversation is one object and the channel is just a delivery mechanism. The same thread contains Monday's email, Tuesday's WhatsApp, and Wednesday's call transcript, in order, visible to whoever picks it up next.
The first is a support strategy. The second is a data model, and you cannot buy your way to it by adding channels.
Why this got harder, not easier
Channel count exploded while the underlying integration problem stayed unsolved.
Messaging is the specific complication. Email has a thread ID and reply headers — stitching a conversation together is mechanical. WhatsApp, Instagram, and SMS have no equivalent. Someone messaging you today about an order from last month is a new conversation as far as the platform is concerned, and identity resolution is on you.
That identity problem is the real work. The same person is an email address, a phone number, a WhatsApp ID, a chat session cookie, and a customer record — and nothing automatically links them. Get it wrong in one direction and the thread fragments. Get it wrong in the other and you show one customer another customer's history, which is a data breach rather than a bug.
Fig. — Channels are delivery mechanisms. The thread is the object that matters.
What agents change
Unifying channels is an old idea that mostly failed for a boring reason: someone had to read all that context, and reading is slow.
An agent reading the full history before every reply removes that constraint. It can summarise eleven previous messages across three channels in the time it takes a human to open the record, and hand the person answering a two-line brief instead of a scroll.
The second change is normalisation. Channels have wildly different conventions — a WhatsApp message is three words, an email is six paragraphs, a call transcript is fifteen minutes of speech with filler. Extracting the same structured facts from all three is exactly the kind of work models are good at, and it is what makes a single thread readable rather than merely complete.
Third, agents can answer directly on the channels where expectations are fastest. Nobody expects an instant email reply. Everyone expects one on WhatsApp, and that expectation is the reason messaging support is expensive to staff.
The routing question underneath it
Unifying the thread creates a problem you did not have when the channels were separate: who owns the conversation.
When email lived in a shared inbox and WhatsApp lived on a phone, ownership was implicit — whoever had the app. One thread across four channels needs an explicit answer, and the obvious one is wrong. Assigning by channel puts three people in one conversation. Assigning by availability means the customer gets a different person each time, which is the problem you were solving.
The model that works is ownership by conversation, with the channel following the owner. If someone handled Monday's email, Wednesday's call routes to them where possible, and the thread carries a clear handover note when it cannot.
That requires deciding what counts as one conversation versus a new one. A follow-up three hours later is obviously the same. Three months later about a different order is obviously not. The middle is genuinely ambiguous, and most teams settle on a time window plus a topic check rather than trying to be clever. Getting this roughly right matters more than getting it exactly right — the failure mode of over-merging is a confusing thread, and the failure mode of under-merging is the customer repeating themselves, which is the thing you set out to fix.
The parts that go wrong
Identity resolution errors are not small bugs. Merging two customers because they share a phone number at a company exposes one person's history to another. Any automatic merge needs a confidence threshold and a human review path, and the failure should be to leave records separate rather than to combine them optimistically.
Channel etiquette does not transfer. A reply that reads well as an email is absurd as a WhatsApp message. Teams that unify the backend and then send identical text everywhere produce something that feels automated in the worst way. The content adapts; only the context is shared.
Consent is per-channel and legally distinct. Someone who gave you an email address has not agreed to be messaged on WhatsApp. Messaging platforms enforce their own rules on top of the law — template approvals, time windows after a customer's last message, restrictions on promotional content. Treating all channels as interchangeable is where compliance problems start.
History gets long. A three-year customer relationship across four channels is a lot of text. Everything the agent reads is context it is paying for, and naive implementations re-read the entire history on every message. Summarise older history and keep recent turns verbatim.
Where to start
Pick the two channels your customers actually use most, and check the data rather than assume — the answer is frequently WhatsApp and voice in markets where teams have built for email and chat.
Solve identity resolution for those two before adding a third. It is the foundation, it is the part that is genuinely hard, and every channel added before it is right multiplies the problem.
Be realistic about the legacy problem while you are at it. Every company doing this has years of history sitting in systems that predate the decision — old ticket archives, an inbox nobody migrated, call recordings in a vendor portal. Backfilling all of it is usually not worth the effort, and the useful compromise is to import the last twelve months and leave the rest searchable but separate. Customers rarely reference a conversation from three years ago; agents rarely need it; and the migration cost of completeness is enormous relative to what it buys.
Then let an agent read and summarise before it writes anything. Context assembly is where the value is, and it is far lower risk than automated replies. A support agent who opens a ticket already knowing the customer emailed twice and called once is faster and better regardless of whether anything else is automated. It is also the change your team will thank you for, which matters more than it sounds — internal adoption decides whether any of this survives its first busy week.
The measure worth tracking is not response time, which will improve for uninteresting reasons. It is how often a customer has to repeat themselves. Nobody has ever left a company because a reply took four hours. They leave because they explained the same problem three times to three different people who all seemed like the first.
It is worth measuring that directly rather than inferring it. A model reading closed conversations can flag the ones where a customer restated context they had already given, and that number — repeat-explanation rate — is the single clearest indicator of whether your channels are genuinely unified or merely numerous.
