Omnichannel customer service means a customer can move between channels without starting again. Most platforms sold as omnichannel are multichannel: they support several channels, competently, but each one is its own queue with its own history. The difference is invisible on a feature list and obvious to a customer who has just explained the same problem twice. This is a practical guide to testing which one you are being sold.

What an omnichannel customer service platform is

An omnichannel customer service platform handles conversations from several channels, messaging, email, chat, phone, social, in one operating environment, so the team works from a shared view of the customer rather than channel by channel.

The definition most vendors work to stops at “handles several channels”. That is the part that is easy to build and easy to demonstrate. The harder part, and the part the word omnichannel is actually claiming, is that the customer’s identity, context and completed work travel with them when the channel changes.

The channel-count trap

Channel count is the wrong metric, and it is the one every comparison table leads with.

A platform supporting six channels where each is a separate queue delivers a worse experience than a platform supporting three that genuinely share context. The customer does not care how many channels you support. They care whether the third person they speak to knows what the first two already established.

Here is the test that actually distinguishes the two. If a customer has to repeat themselves when they switch channel, the channels are not connected, regardless of what the platform is called.

That failure has a cost you can measure without buying anything. Look at your own repeat-contact rate: how often does the same customer come back about the same issue through a different route? Then look at how much of your agents’ time goes on re-establishing context that already exists somewhere in your systems. Both numbers are usually worse than teams expect, and both are the actual business case for connecting channels rather than adding them.

Messaging has made this more acute rather than less. When most contact arrived by phone or email, a channel switch was rare and slow. Now a customer can open a web chat, continue on WhatsApp on the way home, and reply to an email the next morning, about one issue. Treating each as a separate contact is not a minor inefficiency any more.

What continuity actually requires

Four things have to survive a channel switch. Test each one separately, because platforms pass some and fail others.

Identity, does the platform know who this is?

The hardest of the four, and the one most likely to be glossed over. A customer on WhatsApp arrives with a phone number. On web chat they may arrive with nothing, or an email address. Are those one person or two?

Ask this in every demo, and ask to see it rather than be told: a customer messages on WhatsApp on Monday and starts a web chat on Wednesday without giving a phone number, one contact record or two, and what specifically makes it one? Then ask what happens when the identifiers do not match at all. Many platforms resolve identity when a shared identifier is present and create a second record when it is not, which is a reasonable engineering decision and a bad surprise in month three.

Context, does the conversation history travel?

Can the agent see what was said on other channels, in the same view, without switching systems or searching? “It’s available in the contact record” is a different answer from “it’s in front of the agent”.

Work, does completed work carry, or restart?

If a customer verified their identity on chat, do they verify again on the phone? If they uploaded a document, is it attached to the customer or to the chat session? This is where the most customer frustration sits and the least attention goes.

Handover, can a person join with everything already done?

Automation makes this sharper. When a chatbot or AI has gathered information, the agent picking up should start from what is known, not from a fresh greeting. A handover that discards the automated conversation makes the automation worse than useless, the customer has done work twice.

Cue covers the first three of these across WhatsApp, email, web chat and Facebook Messenger: one inbox, one ticket, shared assignment and routing, and conversation history that stays with the contact when the channel changes. On the fourth, identity, ask us the same question this article tells you to ask everyone else, and judge the answer.

How to test a platform for continuity

Run this in the demo, on the vendor’s system, with your questions rather than their script. It takes about fifteen minutes.

1. Start a conversation on channel A as a customer. Give some detail, an order number, a problem description.

2. Switch to channel B with a different identifier. Do not supply the first one. Continue the same issue.

3. Ask the agent’s-eye question: what does the person handling channel B see? One conversation or two? One customer or two?

4. Add a completed step on channel A, verification, an uploaded file, a confirmed detail. Check whether channel B knows.

5. Trigger a handover from automation to a human on channel B. Watch what the human receives.

6. Ask for the reporting view. Is this one customer contact or several? Because that determines whether your repeat-contact numbers will mean anything.

Vendors who pass this will show you willingly. Vendors who do not will explain the roadmap. Both answers are useful.

Run the continuity test on Cue

WhatsApp, email, web chat and Messenger in one inbox, with tickets, assignment and conversation history that stays with the customer.

Book a demo · Or see how the shared inbox works

What to evaluate when shortlisting

Beyond continuity, the questions that separate platforms in practice:

That outbound question is worth pressing. Inbound handling is where platforms converge; outbound is where they differ sharply. Cue, for example, brings WhatsApp, email, Facebook Messenger and web chat into one inbox for inbound handling, but outbound at scale is WhatsApp, through approved templates and broadcasts, while email covers service conversations and individual replies rather than bulk sending. Most vendors have an asymmetry like this. Few volunteer it.

Where AI fits, and where it does not

AI is a continuity multiplier in both directions.

Used well, it removes the repetition that makes disconnected channels obvious: answering routine questions immediately, gathering context before a person arrives, and handing over with the history intact. Cue AI Agents answer from approved website and document content, then return the conversation to a Flow with a reason, a request for a human, or a query they could not resolve, so a person picks up from what is known.

Used badly, it adds a layer that has to be explained past. An AI that cannot see what happened on another channel is one more place the customer starts again.

The boundary worth understanding before you scope anything: knowledge-based AI answers questions from content. It does not look up an order, change a record or complete a transaction. Those require the surrounding workflow and an integration. A demo that blurs the two will produce a scoping conversation you do not enjoy.

The test in this article works on any vendor, including us. Ask to see one customer moving between two channels, and watch whether anything has to be repeated. Book a demo and we’ll run it with you, or read more about Cue for customer service teams.