What "Omnichannel" Means When a Customer Replies
"Omnichannel" is usually deployed as a count. We are on email, web chat, WhatsApp, Instagram, and the phone — therefore omnichannel. Presence on channels is real work and worth something, but it is not what the word ought to mean, and it is not what a customer notices.
What a customer notices is what happens when they reply somewhere different from where the conversation started.
The moment that reveals everything
Someone emails a question. Two days later, having not heard back or having thought of something else, they send a message to your Instagram account.
At that instant, one of three things is true.
The Instagram message arrives somewhere nobody is watching. This is the most common outcome and the least visible, because the failure produces no artefact — just a customer who eventually gives up.
It arrives with somebody who can see it but cannot see the email. They answer helpfully and slightly wrongly, because they are missing the context. The customer now has two partial answers and has to reconcile them.
Or it arrives attached to the same relationship as the email, and whoever picks it up can see the whole thread. This is the only version that deserves the word, and it is a property of your data rather than of your channel coverage.
Why being on more channels can make things worse
Adding a channel adds a place a customer can be ignored.
Before you had a chat widget, someone with a question emailed, and email was watched. After you add chat, some proportion of those people use chat instead — and if chat is watched less reliably, you have converted reliably-answered questions into unreliably-answered ones. Response time gets worse for the same underlying effort.
This is why channel expansion should follow, not precede, the ability to handle what arrives. A channel you cannot answer within your normal response time is worse than a channel you do not offer, because the absence of an option is honest and an ignored message is not.
The connections are the fragile part
Every channel beyond your own website reaches you through someone else's platform, on a delegated grant — the mechanism by which an application "obtains limited access to an HTTP service, either on behalf of a resource owner... or by allowing the third-party application to obtain access on its own behalf" [1].
Three practical consequences follow, and they explain most of the mysterious failures.
Grants expire, and expiry is silent. A channel stops delivering, the interface still lists it as connected, and nobody finds out until a customer mentions it.
Grants belong to individuals. The person who connected the company Facebook page did so with their own account. When they leave, the connection's future is a question nobody asked at the time.
Platforms change scopes. A permission that existed when you connected may be narrowed or removed in a policy update, and the integration that depended on it degrades rather than failing.
The defence is the same in each case: trust a message that actually arrived in the last day over any status indicator claiming the channel is healthy.
The duplicate-reply problem
There is a specific technical failure that shows up as rudeness.
When messages arrive through a connection, they are usually delivered by a callback from the platform. Networks being what they are, those callbacks get retried when a response is not received — even if the message was, in fact, received. Without protection, one customer message becomes two records, and two records become two people answering.
The property that prevents it is idempotency: the intended effect of multiple identical requests being "the same as the effect for a single such request" [3]. Whether a vendor has implemented it is a fair question, and the symptom of its absence is distinctive — duplicate conversations, double notifications, and occasionally two colleagues replying to the same question in slightly different ways.
What it actually takes
Unified inbound. Every channel deposits into one place, so "have we replied?" has one answer rather than five.
Identity across channels. An Instagram handle and an email address must be able to point at the same customer record — which requires the record to be an entity in its own right, not just an address.
Enough context, not all context. There is a temptation to attach every scrap of history to every conversation. In practice, what helps the person replying is the last few interactions and the current state, not an archive. The rule against collecting speculatively "in case it is useful later" [2] applies to display as much as to storage: a screen showing everything shows nothing.
Channels carry expectations you did not set
There is a further complication that catches businesses which have solved the technical side entirely: each channel arrives with a response time already attached to it, decided by the customer rather than by you.
An email carries an implicit tolerance of a day or so. A web chat widget implies minutes — that is what a chat window means everywhere else it appears. A WhatsApp message sits somewhere in between but much closer to chat, because it is a channel people otherwise use with friends. A social comment is public, which changes the calculation again: the audience is not only the person who wrote it.
None of these expectations were negotiated with you. They came from every other company the customer deals with, and they apply the moment you make the channel available.
This is a strong argument for choosing channels deliberately rather than adding whatever is straightforward to connect. A chat widget on a site staffed by two people who are often away is not a service improvement; it is a promise of minutes that will be kept in hours. Removing it and leaving a form that promises a reply by tomorrow is, counter-intuitively, the better customer experience — because it is the one you can actually honour.
The honest version of the promise
Most businesses cannot do full omnichannel, and most do not need to.
The better goal is smaller and achievable: be on fewer channels than you could be, and make every one of them arrive in the same place, attached to the same customer, watched by the same people.
A business reachable on two channels that always answers beats one reachable on six that answers on three of them. Customers do not award points for coverage. They notice whether the reply came.
Sources
- [1] RFC 6749 — The OAuth 2.0 Authorization Framework — IETF
- [2] 360REV Use of Data Policy — what we collect — 360REV, Inc.
- [3] RFC 9110 — HTTP Semantics, §9.2.2 Idempotent Methods — IETF