
A consumer electronics company weworked with had spent two years and several million dollars building what theirmarketing called a “true omnichannel experience.” Customers could start inchat, switch to phone, follow up on email, check status in the mobile app, andreturn to chat — all backed by what was supposed to be a unified customerrecord.
We ran a single analysis question againstthe data: when a customer issue touches more than one channel beforeresolution, how much does it cost compared to a single-channel resolution?
The answer was uncomfortable.Cross-channel issues took 2.7x longer to resolve, generated 3.4x more handletime across the involved channels combined, and produced CSAT scores 1.8 pointslower on average than single-channel resolutions. The omnichannel investmenthad succeeded in giving customers more ways to reach the company. It hadlargely failed at giving the company a way to handle them efficiently when theyused multiple ways.
This is the structural reality of mostomnichannel deployments and it’s the part nobody puts in the marketingbrochure. Multi-channel availability is easy. True omnichannel resolution ishard. Most companies have deployed the first while telling themselves and theircustomers they’ve deployed the second.
The original promise of omnichannel was straightforward. A customershould be able to start an interaction in one channel and continue it inanother without losing context, without re-explaining the issue, and withoutpaying for that flexibility in service quality.
The reality in most deployments diverges from this in three specificways.
Context loss at handoff. When a customermoves from chat to phone, the agent receiving the call typically getsfragmentary or no information from the chat session. The customer has tore-explain. The agent has to re-diagnose. The work done in the previous channelis essentially discarded.
Channel-specific blind spots. The phoneteam can’t see what the customer did in the mobile app. The chat team can’t seewhat the customer wrote in email. Each channel has its own visibility window,and the unified customer view that was promised exists only on slides.
Resolution authority fragmentation. Differentchannels have different resolution authorities for different issues. A customerwho can get a fee waived in a phone call cannot necessarily get the same waiverin chat. The customer doesn’t know this. They experience the channel choice asarbitrary friction.
The cumulative effect is that customers who use multiple channelsfor a single issue have systematically worse outcomes than customers who stickto one. This is the opposite of what omnichannel was supposed to deliver, andmost contact centers are not measuring it.
We’ve started calling this pattern the channel-switching tax becausethe costs are real and they fall mostly on the company, with some spilloveronto the customer.
The handle time tax. Cross-channel issues consume more total agenttime than single-channel issues — usually 50-100% more, with significantvariance by industry. This is pure operational cost that doesn’t appear insingle-channel metrics because the time is distributed across teams.
The repeat contact tax. Customers who switch channels are morelikely to make additional contacts before resolution. Each channel switchtypically adds 0.5-1.5 additional contacts to the resolution pathway. Thesecontacts are invisible to channel-specific FCR metrics because each channelmeasures its own first contact resolution rate independently.
The CSAT tax. Cross-channel issues produce systematically lowersatisfaction scores even when they’re eventually resolved successfully. Thecustomer experiences the channel switching as friction, regardless of whetherthe eventual outcome was correct.
The agent friction tax. Agents handling cross-channel issues reporthigher cognitive load and higher emotional labor than agents handlingsingle-channel issues. Over time this contributes to attrition in ways thatchannel-specific staffing models don’t anticipate.
The compliance tax. In regulated industries, cross-channelinteractions create documentation complexity. A disclosure made in chat may notbe repeated in the subsequent phone call. The compliance record is fragmentedacross systems with different retention policies and different auditvisibility.
There’s a useful gap between what omnichannel implementations werebuilt for and what customers actually need from them.
Customers don’t particularly want to switch channels mid-issue. Whenasked, the majority report a preference for completing an interaction in thechannel they started in. They switch channels because the original channelfailed them — usually because of long waits, perceived agent incompetence, orthe company’s policies about which channels can resolve which issues.
What customers want is for the channel they’re currently using towork. The omnichannel investment that would deliver the most customer value isusually not “stitch channels together more seamlessly.” It’s “make the channelthey chose actually resolve their issue.”
This reframes the omnichannel question. Instead of “how do we makehandoffs invisible,” the better question is “why are handoffs happening in thefirst place, and which ones could be prevented.” Most could.
True omnichannel resolution requires the company to understand thata single customer issue can span multiple touchpoints, even when thosetouchpoints come through different channels at different times.
This is harder than it sounds. The technical infrastructure forcross-channel data integration exists. The CRM platforms have unified customerprofiles. The contact center platforms can route based on prior interactionhistory. The chat platforms can hand off transcripts. None of this is thebottleneck.
The bottleneck is conversation-level understanding. When a customercalls and says “I’m following up on the issue I had with my order,” the agentneeds to know:
• What issue
• When it occurred
• What was promised
• What’s been done since
• What the customer is currentlyexpecting
If the previous interactions are stored as text logs that the agenthas to read while the customer waits, the omnichannel infrastructure has failedto deliver the experience it was designed for. The agent is going to skim, misssomething, and the customer is going to have to fill in the gaps. The handoffcost gets paid.
Conversation analytics that can summarize and surface the relevantprior context in real time change this dynamic substantially. We’ve coveredthis in our work on real-time agent assist. The same architectural questionsapply to omnichannel context.
Enterprise omnichannel deployments have been running for years, withmixed but improving results. Mid-market deployments lag substantially. Thereasons are economic: full omnichannel platforms have historically requiredenterprise budgets and enterprise IT capacity.
The result is a tier of contact centers (200-1,500 seats) that arerunning what we’d call partial omnichannel: multiple channels available tocustomers, but with weak integration on the back end. These centers are payingmost of the channel-switching tax with little of the offsetting customerexperience benefit.
The gap is closing as cloud-native contact center platforms bring omnichannelcapabilities into mid-market price points. But there’s an interim period —happening right now — where the tooling exists and many centers haven’tdeployed it, while the customer expectations have already shifted to assumeseamless cross-channel resolution.
Programs that deliver on the omnichannel promise tend to share fourcharacteristics.
Channel-switching is measured as a primary metric. Not just channel availability, but the rate at which customers movebetween channels for a single issue, and the cost differential of thoseinteractions versus single-channel resolutions.
Conversation context is surfaced, not stored. Prior interactions don’t appear as transcripts the agent has toread. They appear as summaries the agent can act on, with the specificcommitments and unresolved issues highlighted.
Channel-specific friction is mapped. Thereasons customers switch channels are systematically analyzed and reduced. Eachprevented channel switch is a small operational win.
Resolution authority is consistent across channels. A customer issue resolvable in one channel should be resolvable inevery channel. Where this isn’t possible, the limitations are explicit and thecustomer is told.
1. Calculate your channel-switchingrate. Pull a month of customer interactions. Forhow many customers did a single issue touch more than one channel? The numberwill be higher than your operational team estimates.
2. Compare cost-per-resolution acrosssingle-channel and multi-channel customers. This isthe most important number you don’t currently track. The ratio between themtells you the size of the omnichannel tax you’re paying.
3. Listen to 10 calls that came from achat handoff. How much time does the agent spendre-establishing context the chat agent already had? That time is theoperational cost of your context loss.
4. Map your channel-specificresolution authority gaps. For each of your topfive call types, list which channels can fully resolve them and which requireescalation. The gaps are your highest-priority fix list.
5. Survey channel-switching customersseparately. Customers who used multiple channelsfor a single issue have different CSAT drivers than single-channel customers.If your current survey treats them as a single population, you’re averaging twodifferent patterns into one number that obscures both.
The omnichannel infrastructure mostcompanies built was designed to give customers options. The omnichannelexperience customers actually wanted was for one channel to work the firsttime. The gap between those two goals is where the channel-switching tax lives,and most contact centers are paying it without ever measuring how much itcosts.