A Channel Strategy You Can Copy

Slide fourteen is titled "Our Omnichannel Support Vision" and it has eleven channels on it. E-mail, portal, phone, live chat, the chat tool, two social platforms, a mobile app that does not exist yet, walk-up, text message, and something called "proactive outreach". Each channel has an icon. The slide was built in a room with no phone in it. The two people who will answer all eleven are sitting at the back, and one of them has counted the icons twice.

A channel strategy is not a slide. It is one page that says which doors are open and when. It says what each is for, what it is not for, and what the person who uses it gets back. This article is the last in our Channel Strategy series and the one to copy. The five before it explain the channels, the single queue, retiring a channel, live chat and the phone. This one puts the decisions on a page.

It covers what a channel strategy is and is not, then choosing the set, which for most small desks is three doors. Next come the policy table and writing promises you can keep. It covers publishing the page where users will find it, then reviewing it quarterly. Three worked examples for three kinds of desk follow, along with a war story about the ticket the page makes disappear. It ends with what to change when you copy it, with a one-line version for e-mail signatures.

What a Channel Strategy Is

A channel strategy is a one-page statement of which support channels the desk offers, in which hours, for what, and with what response promise. The word "strategy" is doing more work than the page deserves. It is a policy, and a short one. A user should be able to read it in under a minute. They should then know what to do with a broken laptop at 14:00 on a Tuesday and at 02:00 on a Sunday.

The page answers five questions for each channel. Is this door open? When? What is it for? What is it not for? What do I get back, and how fast? A channel that cannot answer all five is not a channel. It is a place requests go to be forgotten, and the desk has enough of those without printing one on a page.

The page is for users first and the desk second. The desk already knows which address to use, more or less. The user with the broken laptop does not, and has a fair chance of guessing wrong. They might try a technician's personal mailbox or a message in the chat tool that begins "quick one". Or they might try the portal, whose login nobody has remembered since onboarding. The page makes the easy door the right door. Everything else in this pillar depends on that.

The page is not a service catalog, an SLA, or an org chart. An SLA, a service level agreement, is the written set of response and resolution promises by priority. The page does not list what IT supports (that is the scope pillar). It does not define priorities and resolution targets (that is SLA design). And it does not say who escalates to whom. It says where the door is and when it is open. Keep it to that and it stays one page.

Three Doors Is Plenty

Most small desks need three channels: a web form, an e-mail address, and a phone number. The form is the door that creates a complete ticket, with the fields the desk needs and an attachment. E-mail is the door for people who will never open a form, and the place where automatic mail and external senders arrive. The phone is the door for people who cannot type, for the network being down, and for urgency the user cannot judge. Together they cover every situation a small desk meets. Nothing on the slide with eleven icons covers a situation these three do not.

Add live chat only when it can be staffed in posted hours. The conditions are in Chat Support for Small Teams. They are enough short questions, a window somebody can watch, and a knowledge base that already answers half of them. If those hold, chat goes on the page with its hours. If they do not, it stays off the page, however good the widget looked in the demo.

Add social direct messages only if the organization already has a public account and people already use it to ask for help. A desk that opens a social channel to look modern has opened a door nobody knocks on, staffed by someone who has to remember to check. A desk whose customers already message the public account has that channel whether it wants it or not. The only decision is to route it into the queue.

Walk-up is a channel whether or not it is on the page, so put it on the page with its rule. The technician logs it on the user's behalf and reads back the number. The chat tool is not a channel. A direct message to a technician gets a reply with a ticket number and nothing else, and the page says so, politely, in the closed-doors row.

Fewer doors is better for the user, not only for the desk. Eleven channels is eleven decisions to make before asking for help, and most people resolve the decision by asking whoever is nearest. Three doors with clear labels is a decision a person can make while annoyed. The slide with eleven icons is a strategy for a desk of forty. For a desk of two, it is a to-do list with no dates.

The Policy Table

The page is a table with five columns: channel, hours, what you get back, use it for, not for. One row per open door, and a final row for the doors that are closed and where they redirect. The version below is for an internal desk of two or three people serving a few hundred staff. Change the hours, the numbers and the promises to yours; keep the columns.

Two things about the table are deliberate. The "not for" column is as full as the "use it for" column, because users learn the edges of a channel from what it refuses. And the closed doors are on the page, with their redirect. Leaving them off does not close them. It leaves them open and unlabeled, which is the worst of both.

Promises You Can Keep

A response promise is a number you can keep on your worst ordinary day, not your best one. Take "first reply within four working hours" from a two-person desk. Even on the day one is out and the other is on the phone rotation, a ticket opened at 09:00 gets a human reply by 13:00. If that is not true, the number is wrong, and users will find out on exactly that day.

Promise a first reply, not a fix. The first reply is in the desk's control: it says the ticket has been read, who has it, and when the next update comes. The fix depends on the problem, the vendor and the parts. The page promises the thing the desk controls, and the ticket promises the rest, one update at a time. Priorities, resolution targets and what happens when a promise is missed belong to SLA Design.

Make the door you want used the one with the best promise. If the form gets four working hours and e-mail gets "when we see it", users learn to phone. If voicemail is "within the hour" and the form is "within four", users learn to leave voicemails. The promises on the page shape behavior more than any announcement does. A shadow channel that is faster than the real one will stay a shadow channel for as long as it is faster.

Measure before you promise, and promise less than you measured. Two weeks of actual first-reply times, by channel, tell you what the desk does now. Promise the time that nine tickets in ten already beat, rounded up to a number a user can remember. Tighten it next quarter if the numbers allow. A promise you tighten is a story about getting better. A promise you loosen is also a story, and nobody tells it at the staff meeting.

Publishing It

The page lives in three places: the intranet, the knowledge base as a published article, and the acknowledgment e-mail as a link. The intranet is where new staff find it. The knowledge base is where search finds it. The acknowledgment is where the user who has just used the wrong door finds it, at the moment they are most receptive. That is the moment the right door has just given them a ticket number.

Every technician's e-mail signature carries the one-line version, which is at the end of this article. It is one sentence, it fits under a name, and it does the redirect without anyone having to say it out loud. A technician replying to a direct message from their mailbox has, by replying, sent the policy.

Announce it once, briefly, and then let the doors do the talking. A three-paragraph e-mail from the desk saying here is how to reach us, here is why, here is the page, gets read by a third of the organization. The signature line, the acknowledgment link and the voicemail greeting get read by everyone who ever asks for help, every time. Announcements fade. Doors do not.

Put it in the new-starter process. Add the link to the onboarding checklist and ask whoever runs induction to spend ninety seconds on it. A page that reaches people in their first week is a page they will use. A page they find in month eight, after the wrong door has worked seven times, is a page they will argue with.

Reviewing It Quarterly

Review the page once a quarter with the channel census. The channel census is a one-week count of requests by channel, how many became tickets, and the hours each was covered. The worksheet is in The Support Channels, Explained. The review asks three questions of every row. Is the door still used? Is it still staffed in the hours written? Is the promise still kept? A row that fails any of the three gets its hours changed, its promise changed, or its door closed.

Use the ticket tool's own counts where it has them. If every channel creates the same kind of ticket, the tool can count them by channel and compare first-reply times across them. QuerySolv's channel comparison report does that over seven, thirty or ninety days. That lines up with a quarterly review. Where the tool cannot see a channel, usually the phone and walk-up, the census tally sheet fills the gap.

Change the page, not the behavior. When the review shows the phone window is too long or chat is empty after 15:00, the fix is to edit the row and republish. The page is allowed to change every quarter. What is not allowed is for the page to say one thing and the desk to do another. Then the page is a slide, and we have discussed slides.

Three Worked Examples

The same five columns produce different pages for different desks. Three examples, each from a house organization, show where the differences land: the hours, the closed doors, and whether there is one page or two.

A two-person desk: Meridian Parts

Meridian Parts has one hundred and eighty staff on one site and two technicians, Dana and Tomas. Their page has three doors plus chat. Form and e-mail: always open, first reply within four working hours. Phone 09:00 to 12:00 and 13:30 to 16:30, one person on rotation per half-day. Chat 10:00 to 12:00 and 14:00 to 16:00 with a bot in front. Walk-up logged on the spot. Closed: the old shared mailbox, with an auto-reply pointing at the form, and direct messages. After a quarter the median first reply was two hours ten minutes by form and two hours forty by e-mail. It was under a minute by phone in the window and four minutes by chat. Dana wrote the page in an afternoon and has edited it twice. Once was to shorten the Friday phone window. Once was to add the closed-doors row after a census week found nine direct messages that had never become tickets.

A warehouse and a night shift: Acme

Acme has two hundred and sixty staff. It has an office of one hundred and forty. It has a warehouse of a hundred that runs 06:00 to 22:00 in two shifts, and a night crew of twenty. The desk is three people. The problem the page had to solve was the night crew. Their only door had been a technician's mobile number on a sticky note by the loading bay. The page says form and e-mail are always open, with a first-reply promise of four working hours. The phone is open 08:00 to 17:00, which overlaps the warehouse day shift. There is a wall-mounted tablet with the form open at the warehouse supervisor's desk, because the crew have no desk machines. A night rule, on the page in plain words, says outages affecting the whole shift go to an on-call number. Under that night rule, everything else becomes a form filled in by the day supervisor at 06:00. The on-call number averaged two calls a month after the page went up, down from the sticky note's eleven. That was because the sticky note had been used for printer jams.

External customers: Kestrel Payroll

Kestrel Payroll runs payroll for about ninety client companies. It supports both its own hundred and ten staff and the clients' payroll administrators, about two hundred and fifty people. The desk is four. They have two pages, not one, because the doors differ. Internal staff get form, e-mail, phone and walk-up. Clients get a client form, a client e-mail address and a client phone line from 08:30 to 17:30. Their first-reply promise is two working hours, tighter than internal, because a client's payroll deadline does not move. The two audiences are separate departments in the ticket tool, each with its own form, mailbox, SLA rules and agent permissions. So a client ticket never sits in the internal queue. A help desk whose departments are really separate, as QuerySolv's are, makes that a configuration rather than a second installation. The client page lives on the client portal, and the internal page lives on the intranet. And the signature line depends on which mailbox the technician is replying from.

A Short War Story: Northgate Retail's One Page

Northgate Retail's desk had three technicians for four hundred staff across a head office and thirty stores. It had been getting a particular kind of ticket for years: "which address do I use for this?" Or its cousin arrived: a request sent to the wrong door and forwarded on by someone helpful. Priya counted them during a census week and found they were one ticket in twelve. The desk published a one-page channel policy and put the link in the acknowledgment e-mail and in every signature. It recorded a new voicemail greeting that gave the form address. In the next quarter's census the "which address" tickets had not fallen; they had stopped. There were two, both from new starters whose induction had been skipped. The page had taken one afternoon to write and about a week of argument over the phone hours. Those turned out to be the only part anyone had opinions about.

I have written that page for three desks. The argument about the phone hours happened all three times. I now schedule it.

Copy It: Five Things to Change

Copy the table above as it stands and change five things. The addresses and the extension. The phone and chat hours, to a window the rotation can hold. The first-reply promise, to the number the two-week measurement supports. The closed-doors row, to name the shadow channels your desk actually has. And the chat row, which is deleted if chat is not staffed. Everything else in the table is true of nearly every small desk and can stay.

Then paste the one-line version into every technician's signature. It is the part of the policy that will be read most, and it should fit on two lines under a name.

IT support: help.example.com/new (form, any time) | support@example.com |
ext. 4100, 09:00-12:00 and 13:30-16:30 Mon-Fri | How to get help: intranet, IT page

The slide with eleven icons can stay in the deck. Nobody reads the deck. They read the signature line, the acknowledgment, and the greeting on the phone. Those three now agree with each other. That is the whole strategy, on one page, written by the people who will answer it.

Frequently Asked Questions