A client of mine had a Contact Us page. Everybody does.
On it were about seven channels. Phone, email, webchat, a couple of social handles, an app, a form. All laid out as icons, evenly spaced, no hierarchy. The customer picked whichever one they liked the look of.
There was no guidance for the customer. Nothing on the page suggested that some channels were better than others for a particular job, because as far as the design was concerned, they were interchangeable. Seven access points, all the same size, and a customer standing in front of them with no idea which one led to the shortest route.
The page was designed with great intent - offering customer choice. What it did instead was hand the customer a decision the organisation needed to have made itself.
Adding channels adds contact. At best it shifts it.
This is the part that tends to start an argument, so let me make the case properly.
The business case for a new channel almost always assumes deflection. Add webchat, take pressure off the phones. Add an app, reduce email. The logic is that demand is fixed and you are simply routing it more cheaply.
Demand isn’t fixed. It responds to effort.
People are busy, and they take the route of least effort. If searching your help centre takes four minutes and firing off a question takes twenty seconds, most people will fire off the question and let you do the work. That’s not laziness, it’s a rational response to the options in front of them. Every channel you add lowers the cost of asking, and when the cost of asking falls, more people ask.
So you don’t get the same volume, cheaper. You get more contacts, spread across more places, each needing its own process and system management, its own resourcing, its own knowledge, its own quality framework.
The measurement hides it
Here’s why this is hard to spot from the inside: almost nobody measures it in a way that would show up.
Deflection gets measured within a channel. Chat reports its own deflection rate. The bot reports its own containment. Voice reports its own volumes. All of them can improve at once while the total number of contacts across the estate goes up, because a contact that moved from voice to chat reads as a win in two places simultaneously. And a contact that only exists because asking got easier doesn’t read as anything at all. It has no comparator.
First contact resolution has exactly the same problem. It’s calculated within a channel rather than across an experience. A customer who starts in the app, gets stuck, moves to chat, gets a partial answer, then phones - that customer has had one issue and three contacts. To them it’s one long unresolved experience. To your reporting it’s three separate interactions, and two of them may well have been marked as resolved.
If your measurement can’t see the journey, it can’t see the cost of fragmenting it.
Not all channels are created equal
The second problem with the seven icons is that it treats every channel as equivalent. They aren’t. Channels have genuinely different strengths, and some jobs can be badly served by many of them.
Complaints are the clearest example. A complaint needs identity, history, a documented trail, and often a conversation for a customer to properly get their perspective across - emotions and all. Some channels support that well. Others really don’t - and if a complaint arrives through one of the ones that doesn’t, you now have a regulated clock running on a contact that has landed somewhere with no proper handling path behind it.
That isn’t a customer error. Nobody made it clear where complaints should go.
The same is true in the other direction. Simple, high-frequency, low-emotion transactions are often better served by the channels that would be hopeless for a complaint. The point isn’t that some channels are good and others bad. It’s that the fit between channel and job is a design decision, and leaving it to the customer means it isn’t being made at all.
Curating the route is your job, not theirs
The obvious objection to all this is that steering customers narrows their choice, and narrowing choice is bad service.
I’d put it the other way round.
Customers don’t have your internal process knowledge. They don’t know which team owns what, which channel has access to which system, or where a particular request will get resolved fastest. They shouldn’t need to. Expecting them to choose the optimal route is outsourcing your operating model to someone who can’t see it.
And if you do have customers who know exactly which channel to use to get a particular thing done, that’s not a success. That’s a group of people who have learnt to navigate around your process because your process didn’t work for them. It’s evidence of a design problem, not proof that the choice architecture is fine.
Curating journeys, meaning actively steering people toward the channel that will resolve their issue with the least effort, is the company doing its own job.
What we did with the seven icons
We redesigned the page around what customers were trying to do rather than around the list of channels available. Instead of seven equally weighted doors, the page led with the job - what do you need? - and pointed to the channel best set up to handle it.
We also stopped promoting some channels altogether.
Not because they were bad channels. Because of what sat behind them. Some of them existed to push information out, for example company announcements, campaigns, updates, and the processes underneath had been built for broadcasting, not for receiving. They had no reliable route into the service operation, no identity checking worth the name, and no way of tracking whether anything raised there had actually been resolved.
That is worth separating out, because it’s the distinction most channel reviews miss. The question isn’t whether a channel is popular, or modern, or where your customers already are. It’s whether the operation behind it was ever designed to take service contact. If it wasn’t, putting it on the contact page is an invitation to a place you can’t serve people properly.
Removing it wasn’t a reduction in service. It was the end of a promise the organisation couldn’t keep.
Where bots fit
None of this is an argument against automation on the front of a journey. A well-designed bot with proper knowledge management behind it genuinely resolves things, and resolves them fast.
But that sentence has three conditions in it, and they carry all the weight. Designed well. Performing well. Real knowledge management underneath. A bot deployed without those isn’t deflection, it’s a delay on the way to a human and now the customer arrives irritated, having already explained themselves once.
The bot isn’t the strategy. What sits behind it is.
A conscious decision, not an accumulation
Most channel estates weren’t designed. They accumulated. One got added because a competitor had it, one because it arrived bundled with a platform somebody bought, one because a campaign needed it three years ago and nobody switched it off.
Each addition was defensible. The result is something nobody would design on purpose.
So the question isn’t whether you can support another channel. It’s this: for every channel you currently offer, what job is it there to do, is it good at that job, and does anything in the customer’s experience actually point them toward it?
And behind all three: does your platform and process structure genuinely support delivering that experience consistently, for agents as well as customers?
If you can’t answer that for all of them, you don’t have a channel strategy. You have a contact page.