In most organisations omnichannel means there is a bot on the website, a bot on WhatsApp and a bot in the contact centre. The channels multiplied; each one still runs on its own memory.
The test from the customer's side is simple. When they pick up an unfinished WhatsApp conversation on the phone, do they have to explain it again? If they do, this is not an omnichannel system. It is several separate systems standing next to each other.
Closing that gap is not a matter of another channel integration. It comes down to design decisions in four areas.
Identity first: how do you know it is the same person
Every channel has its own identifier. A cookie or session id on the web, an app user id on mobile, a phone number on WhatsApp, a calling number in the contact centre. Carrying context requires knowing these belong to the same person.
Two methods are in use. Deterministic matching relies on something verified: the user is signed in, the number is registered to the account, a verification code was entered. Probabilistic matching infers from signals: same device, same IP, close in time.
Probabilistic matching should not be used in customer service flows, and for a different reason than in marketing. In ad targeting a wrong match costs you an irrelevant ad. In a support flow a wrong match means showing one customer another customer's order. Under data protection law that is a breach.
Our recommendation is unambiguous: carry context only across verified identity. Without verification the assistant gives general information, never anything personal.
Channel trust levels
A related mistake is carrying verification status across channels. A user signed into the mobile app is not thereby verified on a phone call. Caller ID can be spoofed and the device may be in someone else's hands.
Working deployments assign a trust level to each channel and define in advance which operations are available at each level. Checking order status may be fine at a low level; changing an address or viewing a balance requires additional verification.
Producing that table is half a day of work and settles a long list of later arguments.
What gets carried is a decision
"Let's carry the conversation history" does not work well in practice. Long histories mislead the model, carry noise, and from a privacy standpoint move more data than necessary.
What genuinely needs to travel is a short list:
- Verified identity and permission level
- Last intent and any open transaction attached to it, such as a ticket or order number
- A short summary of the conversation, a few sentences
- Steps already tried that did not work
What should not travel matters just as much: the full raw transcript, channel-specific technical detail, and verification status obtained on another channel.
Context needs an expiry
Attaching a conversation from three days ago to today's message creates more confusion than help. The customer may be writing about something entirely different while the assistant tries to resume the old topic.
The structure that works is two layers. Active conversation context is short-lived and expires within hours. Open transaction context persists until the transaction closes; a shipment or an open support case stays relevant for weeks.
Without that split you get the two familiar complaints: "it does not remember me", or "it keeps bringing up the old issue".
Channels have their own rules, so flows cannot be copied
Porting the same script to every channel does not work, because channels differ technically and in what they permit.
On the WhatsApp Business Platform, a message from the user opens a 24-hour customer service window. Free-form messages can be sent inside that window; once it closes, only pre-approved template messages are allowed (Meta developer documentation). That means a support flow's "I will update you tomorrow" step has to be designed against the channel's rules from the start.
The voice channel has no visuals: no option list to display, no link to send. The web accepts file uploads, WhatsApp receives photos, the phone receives neither. These change the content of the flow, not just its presentation.
The one thing that must not change is where answers come from. Organisations that maintain a separate knowledge base per channel inevitably drift apart and end up answering the same question differently by channel. One knowledge base, different presentation per channel, is the model that works.
The handoff is where the gains disappear
In most deployments what gets passed to an agent is the raw chat history. The agent does not read it, asks "how can I help you", and the customer explains from the beginning.
In that single step the gain from automation is wiped out, and the experience ends up worse than it would have been without automation, because the customer explained twice.
The handoff package should contain: verified identity, a one-sentence summary of the request, relevant record numbers, sources the assistant consulted, steps already tried, and why it was escalated. On the agent's screen, that package belongs above the transcript.
Whether it works is easy to test: measure how often the agent's first message after transfer asks for information already provided. Above ten per cent means the handoff design is not working.
The biggest trap in comparing channels
Dashboards put resolution rate by channel side by side, and the phone usually looks worst. Concluding "let's shut down the voice channel" would be a mistake.
The cause is selection bias. Complex, urgent and emotionally charged issues push customers to the phone. Simple order tracking gets handled on the web. Channels do not see the same distribution of questions, so their performance is not directly comparable.
For a meaningful comparison, normalise by topic. Compared within the same topic type, the picture usually reverses.
Metrics worth tracking:
- Share of sessions that involve a channel switch
- Rate at which customers repeat themselves after switching channels
- Rate at which agents request additional information after handoff
- Topic-normalised resolution rate by channel
- Verification failure rate by channel
Transparency applies on every channel
For organisations operating in the EU, Article 50 of the AI Act requires AI systems interacting directly with people to disclose that fact, no later than the first interaction. The article became applicable on 2 August 2026 (artificialintelligenceact.eu).
In a multi-channel deployment the practical implication is that the disclosure has to be designed per channel. A line of text may suffice in a web widget; on the voice channel it belongs in the opening sentence.
Pre-deployment checklist
- Does identity matching rely only on verified information
- Is a trust level defined per channel, with permitted operations at each level
- Is the list of context fields to carry written down
- Do active conversation context and open transaction context have separate lifetimes
- Are channel constraints such as template messages and media reflected in the flows
- Is there one knowledge base or one per channel
- Is the handoff package defined and visible on the agent screen
- Are channel comparisons normalised by topic
To see how channels are unified under a single intelligence layer, look at Omnichannel Assistants and, for the support side, Helpdesk Solutions.
References
- Meta for Developers, WhatsApp Cloud API, sending messages and the customer service window. developers.facebook.com
- EU AI Act, Article 50: Transparency Obligations. artificialintelligenceact.eu
- Turkish Data Protection Authority. kvkk.gov.tr