Know your customer, then pick your channels

In short. Adding a channel is easy, staffing it is not. Take your top ten contact reasons, give each one a channel and a reason, and write down what you will never automate. One page, one afternoon, no journey mapping programme required.

You can avoid that without a research project. And you should resist the urge to solve it all at once, because that is where these projects usually come apart. Do not try to fix ten years in one go. Move what you have, let people get used to it, then start optimising.

For a lot of teams the first real win is smaller than they expect. Getting voice, email and chat into one place is already the big change, and that is enough for month one.

Where this article sits in the series

This is the second of four connected articles about moving from queue management to customer journey ownership.

Part one ended with a week of logged contact causes and a named owner who can change something outside the contact centre. This part turns that log into a channel design: every contact reason gets a channel and a reason for being there, and everything that should never be automated goes on a separate list before anyone builds a flow.

What comes out of this part is a one-page channel map. Part three tests whether your data can actually support the automated parts of that map, and part four measures whether the design works once real customers are using it. If you have not run the cause log from part one yet, do that first, because a channel decision without it is guesswork with a project plan attached.

Ten reasons, one page, one afternoon

Pull last month's contact reasons from your phone system and your inbox. Take the top ten. If your reporting is too coarse, ask three agents for an hour. They will name eight of the ten from memory.

For each reason write four things: how much volume it represents, which channel it arrives on today, who resolves it, and which channel it should arrive on. That is the whole exercise. It fits on one page and it survives contact with reality, which more elaborate frameworks often do not.

Then match reasons to channels. Complex or emotional goes to voice. Status questions and simple requests go to self-service or messaging. Anything that needs a paper trail goes to email. Three channels that work well beat seven that are half-monitored.

Segment your customers on behaviour rather than demographics. A procurement buyer, a consumer with a one-off question and a key account have different tolerance for effort, and that difference decides your channel mix. Age and postcode do not.

One constraint applies across all of them. Zendesk research puts the share of consumers who expect a representative to have immediate access to previous interactions, regardless of channel, at 87%. Whatever mix you land on, context has to travel with the customer, or you have built a set of separate queues and called it omnichannel.

Ask your agents, but do not stop there

Involve the people who use the system. Just know what you will get back. Their frame of reference is today's tool, so requirements come out as a copy of it.

That is why demo and inspiration sessions with vendors are worth the time. Nobody can ask for something they have never seen. Use those sessions to widen the frame, then let the cause log from part one decide what actually gets built.

"Ask people what they need and they will describe the system they already have, with one button in a different place."

This is why requirement lists gathered internally tend to produce a slightly nicer version of the past. Use the agents to find out what breaks. Use outside exposure to find out what is possible. Do not ask one group to do both jobs.

Test what happens to the calls nobody planned for

One example from a project we were called into. The organisation had run the same setup for twelve years: an IVR with six options and a chain of fallbacks behind it. Any call the menu could not place eventually landed with the receptionist.

In the new design the receptionist was gone. So every call that used to end up there fell through to a department instead. That organisation had three separate businesses underneath it, and the department now receiving those calls served only one of them. Cue a stream of calls that had nothing to do with them, and a verdict that the new platform could not handle the business.

It was never the platform. Nobody had stress tested what happens to calls the menu cannot place once the human safety net is gone. So take your flows, remove the fallback in your head, and follow the call. Where does it land, and does that team want it?

The list of things you never automate

Write it down before anyone builds anything. Bereavement. Complaints with emotional weight. Vulnerable customers. Safety issues. Anything where being handled efficiently by software would feel like being handled carelessly.

A funeral does not belong in a phone menu. For a consumer business, a death in the family is the clearest example. Someone calls to close an account for a relative who has died. Every second of navigating options is a second of being told the company has better things to do. There is no automation win available here, only damage to avoid.

Then make sure every automated flow has a way out. A route to a human the customer can find without knowing the trick, without repeating themselves, and without going back to the start of the menu.

Transparency is now law, not manners

In Europe this stopped being a design preference on 2 August 2026. From that date the transparency obligations in Article 50 of the AI Act apply, and they cover any system that interacts directly with people, chatbots and voice assistants included. People have to be told they are dealing with AI unless it is obvious from the circumstances. The European Commission published its final guidelines on 20 July 2026, and penalties for non-compliance reach 15 million euro or 3% of worldwide annual turnover, whichever is higher.

Two practical consequences for an organisation operating in more than one country. The obligation follows your users, so a contact centre outside the EU serving EU customers is in scope. And the obligation lands on the deployer as well as the vendor, so buying the platform does not transfer the duty. Cheaper to design in now than to retrofit later.

There is a wider point here. DMG Consulting's 2026 research shows employee experience dropping to 9.1% of strategic priorities, while DMG itself describes a hybrid model of human and AI agents as the realistic operating model for the coming years. Those two things do not fit together. Plan for the humans you will still need.

Do this week

• Pull last month's top ten contact reasons, or book an hour with three agents
• Fill in the four columns for each reason
• Write your never-automate list and get the sponsor to sign it
• Check every live automated flow for an AI disclosure and a route to a human

Checklist, part 2

• Top ten contact reasons with volume, on one page
• Customer segments based on behaviour, not demographics
• A channel choice per contact reason, with a reason attached
• Only channels you can actually staff
• Every fallback path tested, including the ones with no human at the end
• Written list of reasons that will never be automated
• A findable route to a human in every automated flow
• Customers are told when they are dealing with AI, in line with AI Act Article 50

Next in this series

Your channel map now says which contact reasons should be handled without a person. Part three, Start with your data, not your bot, checks whether your data can actually support that, and gives you five criteria for choosing a first automated use case that cannot embarrass you.

Read the full series

These four articles are written to be read in order. Each one produces something the next one uses.

• Part 1. Fix the mandate before you fix the queue. Who owns the problem, and how far does their mandate reach.
• Part 2. Know your customer, then pick your channels (you are reading this one). Which contact reason belongs on which channel, and what you will never automate.
• Part 3. Start with your data, not your bot. Whether your data can support what you want to automate, and where to start.
• Part 4. Turn it on, measure it, and be willing to turn it off. The loop that keeps the first three parts alive after go-live.

Source: DMG Consulting LLC, 2026 CX AI Playbook: Strategic Outlook and Investment Priorities, February 2026, sponsored by Five9. Additional market data from Gartner, Zendesk and public analyst commentary, retrieved August 2026.