Phone, email and chat should each do a different job, and the case should follow the customer between them without anyone having to explain themselves twice. Getting there takes three things: a clear rule for which channel suits which kind of request, routing by skill and not by whoever is free, and one shared record of the conversation.
Channel strategy was the third pillar of the plan I described in building a three-to-five-year support plan. When I arrived at Q4, requests reached us in several ways and were handled in several ways, and one of the first things I wanted to improve was how they got from the customer to the right person. This is how I think about it, and what we built: skill-based routing, omnichannel case distribution and automatic prioritisation and categorisation.
What is each channel actually good for?
Phone is for urgency and for complexity that needs a conversation. When an IR manager is minutes from a release and something looks wrong, they don’t want a ticket number. They want a person. Phone is expensive per contact and hard to scale, so you want it reserved for the moments where speed or nuance really pays. It’s also where emotion shows up. A good agent on a phone call can calm a stressed customer in a way no template can.
Email, or the ticket form that stands in for it, is for requests that need detail and a record. A customer attaching a document, describing a change or asking for something specific wants it written down, and so do you. Email is asynchronous, which suits technical work that takes time, but its weakness is the silence. A customer who sends a request and hears nothing for hours will assume nobody saw it. That was the 17-hour problem in a nutshell, and I’ll come back to it.
Chat sits in between. It’s quick enough for a short question and quiet enough to run alongside other work, which is why people like it. I wrote about the pull of it years ago in why everyone is chatting, and my view hasn’t changed. Chat is excellent for simple, quick questions and poor for anything that takes a long investigation, because a long chat tends to become a long wait for someone who’s keeping a window open.
The mistake is treating the three as equals, or as separate teams with separate queues. A customer doesn’t think “I’m using the email channel.” They think “I need this fixed.” The best you can do is make it easy to start in any channel and make sure the answer doesn’t depend on which one they picked.
What does omnichannel mean in practice?
One case, many ways in. If a customer emails, then phones, then chats about the same issue, there should be a single case that shows the whole history, and whoever picks it up should know what’s happened so far. I touched on the idea in the impact of customer experience and omnichannel, and the principle is simple even if the implementation isn’t: the customer’s problem is the unit of work, not the contact.
That has a practical effect on the team. Case distribution has to treat the channels as inputs to one queue, with the same priority rules applied across them. A high-priority email shouldn’t wait behind a routine chat because the chat channel was staffed first. Our distribution rules looked at what a request was and how urgent it was, and not at where it came from.
It also changes what you measure. Response time by channel is useful, but the number that matters is how long it takes the customer to get an answer to the problem, across all the contacts it took. I’d argue the best measure of an omnichannel operation is how rarely a customer has to repeat themselves.
How does skill-based routing work?
Each request is matched to the person, or group of people, best able to handle it, instead of whoever is next in line. For that you need two things: a description of what each request needs, and a description of what each person can do. The first comes from categorising the request. The second comes from a skills matrix, which is the same tool I used to define levels in my earlier posts and in the AudienceView support transformation.
Before routing by skill, the work at a team like ours tends to land in a general queue, where a person picks a ticket, reads it, works out what it needs, and either handles it or passes it on. That sorting step is slow, and it hides a lot of waste. A request that goes to the wrong person loses hours before anyone realises. Matching on skill removes that step. The request lands with someone who can handle it, or with a group that can, and the first response comes faster because the person responding already knows the answer area.
Prioritisation works the same way. An incoming request gets a priority from what it is and, in our world, from the calendar around it. A document upload due before an earnings release isn’t ordinary. Automatic prioritisation assigns urgency from those signals, so the most time-sensitive work rises without anyone having to spot it by hand.
The combination of skill-based routing, omnichannel distribution and automatic prioritisation and categorisation is what I expect to move our response and resolution times most, and I’ll report the results honestly at the end of this series. I want to be careful about how I describe it. It isn’t one tool. It’s a chain of decisions: define the skills, clean up the categories, route on them, apply the same priority rules across channels and stop sorting by hand. The technology is the last link, not the first.
What do you have to get right before you automate routing?
The categories. If the same kind of request is tagged three different ways, or if a category is a catch-all for anything the team couldn’t classify, routing on it will send work to the wrong places faster. Cleaning up the taxonomy is boring work that takes weeks. It’s also what everything else depends on, including the AI triage I’ll describe in a later post. I’d start with a short list of categories that match how the team actually thinks about the work, agree definitions and test them on real tickets.
Next, keep a human fallback. Some requests won’t fit any category, and routing rules will sometimes be wrong. A person who reviews unmatched cases and fixes the rules keeps the system honest. Without that, the exceptions pile up and trust in the routing disappears.
And review the skills regularly. People learn, leave and join. A routing table that was accurate in January is out of date by June. Treat the skills matrix as a living document, tied to training and certification, so a person’s routing changes when their capability does.
What about the customer’s side?
Tell them what to expect. When customers know which channel is fastest for which kind of request, they pick the right one, and your volume distributes itself better. Put a short, clear guide on your support page: phone for urgent, time-critical issues, email or tickets for detailed requests, chat for quick questions. And tell them when they’ll hear back.
Acknowledge every request quickly, even if the substance takes longer. A short, automatic confirmation that a request has arrived, with its priority and an expected response time, takes away much of the anxiety that comes from silence. It doesn’t resolve anything. It tells the customer someone has it, and for a person working to a deadline that’s worth a lot.
Don’t push everyone toward the cheapest channel. Moving routine questions to chat or self-service is sensible. Making it hard to reach a person when it matters isn’t. I’d rather have a slightly higher phone volume from customers who are glad to get through than a lower one from customers who’ve given up.
Finally, test the whole path as a customer. Send a request by each channel, with different priorities, and follow it through. Where does it wait? Who picks it up? How long before you’d hear anything? The exercise takes an afternoon and shows you problems no dashboard reports, such as a chat that routes to a team that’s offline, or a priority rule that doesn’t apply to email. Do it again after every change to routing.
The channel is how a customer reaches you. The routing is whether the right person is waiting.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
