The Support Channels, Explained

At 08:52 on a Tuesday the printer on the second floor stops. By 09:10 the desk has heard about it five times. Lena e-mailed the support address. Marcus opened a ticket on the portal, which he found on the third try. Priya phoned, got voicemail, and phoned again. Sam walked over. Dana sent "quick one" in the chat tool, with a photo of the jam light. One printer, five doors, five people, and a desk that now knows about one problem five times and has logged it once, possibly.

Nobody did anything wrong, including the printer, which was only doing what printers do. Each person used the door nearest to hand, and the desk had left five doors open without ever deciding to. This article is the first in our Channel Strategy series. It is the vocabulary lesson the rest depends on. A support channel is a route by which a request reaches the desk. This article walks through the six you are likely to have, one at a time, in the same shape. It covers what the channel is good at, what it costs the desk, who tends to use it, and how it fails.

It ends with a comparison table, the truth about which channel people actually choose, and the two questions that decide which to offer at all. Then come a week of counting at Northgate Retail and a census worksheet you can fill in by Friday.

What a Channel Is, and Why You Have Six

A channel is a door into the desk, and every desk has more of them than it thinks. The ones this series uses, in the same words every time: e-mail is a mailbox the desk reads. The portal, or web form, is a page where the requester opens a ticket and follows it. The phone is a call the technician logs. Live chat is a widget on a page, answered live by a person. The walk-up is the person standing at the desk. Social direct messages are messages on a social platform that become tickets. And the chat tool is the organization's internal messaging, where a direct message to a technician is a support request whether or not anyone calls it one.

Nobody designs a six-channel desk. It accretes. The mailbox came first because mail exists. The phone was already on the desk. The portal arrived with the ticket tool. Chat was switched on because the tool had a checkbox. The walk-up predates the building. A channel, once open, is very hard to shut, because the people who use it are the people who like it. Its cost is paid in small coins: a check every hour, a retype per request, a promise broken in silence when nobody is there.

E-mail: The Mailbox the Desk Reads

E-mail is good at anything that can wait an hour and needs a written record. Screenshots attach, long explanations fit, and it works at 23:00. Most ticket tools read a mailbox and turn each message into a ticket with the sender as the requester. So e-mail is the cheapest channel to log, provided the mailbox belongs to the tool and not to a person.

Its cost to the desk is the mailbox itself whenever it is not wired to the tool. A shared mailbox read by humans has no owner per message, no state, and no memory of who replied. Two technicians answer the same message; a third assumes one of them did. The unread count climbs past nine hundred and becomes a kind of weather. Nobody is responsible for weather.

Everyone uses e-mail, which is its strength and its problem. It is the default door for anyone at a computer, and the fallback when another door is broken. The failure mode is the thread: seventeen replies with four people copied. In that thread, the actual problem changed on reply six and the desk's answer is on reply nine, unread. E-mail-to-ticket mechanics come later in the library; here the rule is short. The mailbox must land in the queue, or it is a second queue.

The Portal and the Web Form

The portal is good at structure. A web form can ask for the three things the desk always needs (which device, which application, since when) and refuse to proceed without them. That turns a two-day clarification exchange into a ticket that can be worked at once. The requester gets a page where the status is visible without asking; the desk gets a record that was never a thread.

Its cost to the desk is the trip. A form lives somewhere, and the requester has to find it. If it is behind a login they have to remember a password they set once, during onboarding. A form with eleven required fields costs a minute of resentment per request. A form nobody can find costs nothing, because nobody uses it. The desk pays for a portal in promotion, not in tickets.

The people who use the portal are the people who were told to and the people who like forms, which is a smaller group than vendors imply. The failure mode is the portal nobody visits, bought at the greatest expense, sitting next to a mailbox that carries the load. A portal that needs no account, no password and no particular browser removes most of the trip. The form wins only when it is the easiest door, not the most official one.

The Phone

The phone is good at urgency and at people who cannot type. The user whose screen is black cannot open a form. The user whose network is down cannot send mail. The warehouse supervisor wearing gloves will not do either. A call also carries tone, and tone is data. The desk learns in four seconds that this is the third time, which no form field captures.

Its cost is that it interrupts, and it does not log itself. A call takes a technician away from whatever they were doing, at a moment the caller chose. It leaves no record unless the technician makes one while the caller is still talking. The phone that rings while you are on the phone is not a queue. It is a contest, and the loser gets voicemail.

Phone users are the urgent, the senior, the mobile, and the people who have learned that a call gets a person and a form gets a number. The failure mode is the unlogged call: fixed in four minutes and recorded nowhere. So the desk's count of its own work is wrong by exactly the number of favors it did. Logging calls while the caller is on the line, and the voicemail greeting that gives the form address, are covered in Phone Support in a Ticket World.

Live Chat

Live chat is good at short questions with short answers. Is the mail server down? How do I reset my token? Where is the form? A requester who would not write an e-mail for a two-line question will type it into a widget. A technician can hold three such conversations at once, which is impossible on the phone. If the widget creates a ticket from the first message, the chat is logged for free.

Its cost is the promise. A chat widget says, by existing, that someone is there now, and "now" is a strong word at a desk of two people. Every hour the widget is up and unanswered is an hour of users learning that the desk's promises are decorative. Chat also stalls on anything that takes twenty minutes or needs hands on hardware. At that point it becomes a ticket anyway and the requester has typed the story twice.

Chat is used by people at a keyboard with a quick question, and by people who have found that it is the fastest way to a human. The failure mode is the widget that says "we typically reply in a few minutes" above an empty chair. Staffing it honestly, with posted hours and an away state that offers the form, is the subject of Chat Support for Small Teams.

The Walk-Up

The walk-up is good at anything that needs the user and the device in the same place. Examples include a laptop that will not start, a badge that will not scan, and a new starter who needs three things and a chair. It is the only channel where the technician can see the problem rather than hear it described. A two-minute look often beats a forty-minute e-mail exchange.

Its cost is that it is the most interrupting channel there is and the least logged. A person at the desk cannot be put on hold or triaged, and will not be told to open a ticket when they are already standing there. Ninety seconds of help becomes nothing in the record. So the desk's busiest hour, the one with a line at the counter, shows on every report as the quietest.

Walk-up users are the people who sit near the desk, which is a geography and not a priority. The failure mode is fairness: the person who walks over gets helped in two minutes while the person who used the form three floors up waits two days. Both of them notice. The fix is not to send anyone away. It is for the technician to open the ticket on the user's behalf while they are still there, so the queue stays honest.

Social Messages, and the Chat Tool

Social direct messages are good at reaching people who are not your staff. Customers, suppliers and the public will not log in to an internal portal. A message on the platform they already have open is the only door they will use. If the tool turns those messages into tickets and posts replies back through the same conversation, the desk gets a record and the requester gets an answer where they asked.

The cost is that a public platform has its own rules, its own outages and its own idea of what a conversation is, none of which the desk controls. A direct message that nobody turns into a ticket is a request the desk does not know it has, visible to the requester as "seen". This is a worse silence than voicemail.

The chat tool is the internal cousin, and at most organizations it is where half of the real support happens. A direct message to a technician that starts "quick one" is a support request with no number, no owner and no history, answered by whoever happened to be online. It is the fastest channel the organization has and the worst recorded, which is the same sentence. The chat tool is not going away, so the desk's job is to route it. The redirect that does so without offending anyone is in One Queue, Many Doors.

The Channels Side by Side

The table puts the channels side by side in the four columns that matter to a small desk. "Cost to the desk" is the staffing and interruption cost. "Logging effort" is how much typing it takes to get the request into the queue, assuming a tool that reads e-mail and has a form.

The Honest Truth About Preferences

People use the channel that is nearest, not the one that is best, and training does not change that for long. Nearest means the fewest steps from the moment of the problem. That might be the mail client that is already open, the phone that is already in the hand, or the technician who is already in view. A user with a jammed printer is not weighing the merits of structured intake. They are looking for the closest door, and they will take it.

This is not a failing in users; it is a failing in door placement, and the desk placed the doors. If the portal is three clicks and a forgotten password away and the technician's direct message is one click, the desk has designed a system in which the DM wins, and then expressed surprise. I spent a year asking people to use the form before I noticed that I had never once used it myself.

So the desk chooses channels by moving the doors, not by lecturing. Put the form link on every desktop, in every signature, on the voicemail greeting and at the top of the chat tool's support space. Move the doors you do not want used slightly farther away, politely, with a redirect. Preference follows distance, and distance is something the desk controls.

The Two Questions That Decide Which to Offer

Two questions decide whether a channel should be open at all, and both have yes-or-no answers. The first: can a request on this channel land in the queue as a ticket without anyone retyping it? The second: can the desk staff this channel in the hours it promises? A channel that fails the first is a second queue. A channel that fails the second is a broken promise with a logo.

The retyping question is about the tool and the wiring. E-mail passes if the mailbox feeds the tool. The form passes by definition. Chat passes if the widget creates the ticket on the first message. Social messages pass if the tool routes them in. Phone and walk-up pass only if the technician opens the ticket during the conversation. That is a habit and not a feature. The chat tool's direct messages fail, always, unless the reply contains a ticket number. The whole of One Queue, Many Doors is about making every channel pass this question.

The staffing question is about hours and honesty. A phone line answered from 09:00 to 17:00 by a two-person desk is a promise that one of them is always at the desk. That is false for lunch, leave, and the hour both of them are in the server room. Write the hours you can actually cover next to each channel and see which promises survive. Promises in general are the subject of the SLA design series; the channel version is short. Do not open a door you cannot stand behind.

A tool that passes the first question for most channels at once takes most of the retyping cost out of the table above. QuerySolv's phrase for this is five ways in, one queue. Web form, e-mail, live chat, social messages and the REST API each create the same kind of ticket in the same queue. That leaves phone, walk-up and the chat tool as the three doors the technician carries across by hand. Three habits is a shorter list than six.

A Week of Counting at Northgate Retail

Northgate Retail's desk, three technicians serving four hundred staff across a head office and a dozen stores, spent one week counting every request by the door it came through. Dana put a tally sheet next to each technician and asked them to tick a column for every request, logged or not, from Monday 08:00 to Friday 17:00. The count came to three hundred and twelve requests. E-mail carried a hundred and forty, the phone eighty-one, walk-ups forty-six, and the chat tool thirty-two. The portal had taken four months to configure and sat behind a login nobody remembered. It carried thirteen. That is four percent, on the channel that had cost the most. Nobody was blamed and the portal was not switched off. The login was removed the following week, and within a quarter the portal's share had grown to a fifth.

I have run the same count on my own desk and got a similar shape, with a different channel at the bottom. It is finished in a week, and it ends every argument about which door matters that was based on the feelings of the person arguing.

The Channel Census Worksheet

The census is the week of counting, written as a worksheet. One row per channel, five columns, one working week. "Requests last week" is every request seen on that channel, whether or not anyone logged it. "Logged as tickets" is how many made it into the queue. "Hours covered" is the hours a human actually answered that channel, not the hours on the sign. The last column is the decision, and there are only three.

The decision rule is mechanical, which is the point. Keep a channel whose requests are logged and whose hours are covered. Fix a channel that carries real volume but fails one of the two questions. Wire it to the tool, add the habit, or shrink the hours to the ones you can staff. Retire a channel that carries little, logs nothing, and duplicates a door that works. Retire one at a time, with notice, and never because it annoys you.

Worked through for a real desk, the sheet reads like a diagnosis. Tomas at Acme, two technicians and a hundred and ninety staff, filled it in for one week in spring. E-mail: a hundred and four requests, a hundred and one logged, covered 08:00 to 18:00. Phone: fifty-three, nineteen logged, covered 09:00 to 17:00 "when someone is there". Walk-up: thirty-eight, six logged, no hours stated. Chat tool: forty-one, two logged. Live chat: nine, nine logged, two hours a day. Portal: seven, seven logged. His decisions were to keep e-mail and the form, and fix the phone and the walk-up by logging during the conversation. He would fix the chat tool with a ticket-number reply and retire live chat until there were enough short questions to staff it. The desk's real volume was two hundred and fifty-two requests a week, not the hundred and forty-four the tool reported.

On the Tuesday with the printer, a census would have shown five requests, one problem, and one ticket, possibly. That is the ratio to expect until the doors are moved. Move them, and the same Tuesday produces one ticket with five people on it, which is what the printer deserved all along.

Frequently Asked Questions