Direct Messages and Chat as a Support Channel

Monday, 08:55, at Stonebridge Insurance. Rosa opens the chat tool before the help desk, because the chat tool is where the noise is. Fourteen unread direct messages, three of them sent on Saturday. One from the claims manager says only "did you see my message?" It refers to a message Rosa did not see. It was sent to her at 19:40 on Friday under a photo of a dog. The team channel the desk set up for "quick questions" has nine new messages since Friday. None are addressed to anyone. Two of them are the same person asking the same thing four hours apart. One just says "anyone?" The help desk queue, when she finally opens it, has six new tickets. It is the quietest thing on her screen, and it is the only one the desk measures.

A direct message, in this series, is a support request sent through the organisation's chat tool to one technician by name. And it is a walk-up with a keyboard. It is faster and friendlier than the form, invisible to the queue, and served in the order people happen to type. A team channel is the shared room in the same tool where anyone can post a question. And it is a queue with no owner. This article is part of our The Walk-Up & Drive-By Culture series, and it is about what to do with both.

It covers why a direct message is a walk-up and what the one difference is. Next comes the direct message that becomes a ticket, in twenty seconds. Then it covers the team channel that becomes a queue nobody owns and deciding whether chat is a support channel at all. It covers the auto-reply and the status line; the technician's personal messages and the boundary around them. It ends with running the shift without losing people; a short war story; and the direct-message redirect to copy, in that order.

A Direct Message Is a Walk-Up With a Keyboard

Everything the first article in this series said about the hallway applies to the direct message, because it is the same channel with the walking removed. It is chosen because it is faster than the form, as far as the requester can tell. It is friendlier because it goes to a person with a face and a name rather than to a system. It is unlogged unless the technician logs it. It creates promises that live in a scrollback rather than a list. And it serves the people who know which technician to message ahead of the people who do not, which is the fairness problem again, wearing a different coat.

The one difference is that a direct message leaves a record, in the wrong place. The hallway request vanishes the moment it is spoken. The direct message sits in the chat tool, searchable by the two people in the conversation and nobody else. It will be found again by the requester ("I messaged you about this on Friday") and not by the desk. It is a record that can be used as evidence against the desk and never for it. The queue, by contrast, is a record both sides can see, with a number on it. The whole design idea of one queue fed by many doors, so that every route ends in the same list, is in One Queue, Many Doors. The direct message is the door that was never on the plan and gets more traffic than most that were.

The direct message also has a habit the hallway does not, which is that it arrives at any hour. A person cannot walk up to Rosa at 19:40 on a Friday. They can message her, and the message will wait under the dog photo with a little red badge on it until Monday. By then the requester has been waiting the whole weekend and Rosa has been, by any reasonable reading, ignoring them. Neither of those things is true, and the chat tool has made both of them feel true. It is a very good tool for that.

The Direct Message That Becomes a Ticket

The direct message is handled like the hallway request: the technician converts it into a ticket, on the spot, and replies with the number. The twenty-second reply in chat is almost the same as in the corridor: "On it. I've opened a ticket so it doesn't get lost; you'll get the number by e-mail in a minute." The conversion is a copy and paste. Select the requester's message, paste it into a new ticket with their name on it and "chat DM" as the source. Send the acknowledgement, and reply in the chat with the number. The requester has lost nothing and gained a record. The desk has gained a ticket. Rosa has gained the right to close the chat window.

The ticket, not the chat, is then where the work happens. Replies, questions, the fix and the confirmation all go through the ticket. That way, the history is in one place and visible to whoever covers for Rosa. The chat thread gets one more message at most, which is "replied on the ticket" if the requester is still typing there. A desk that converts the message and then carries on working in the direct message has made a ticket for show. The conversation that matters is still happening somewhere only two people can see it. Convert, reply with the number, and move. Running the work in two places is how both places end up wrong.

Where the chat tool can forward a message to an e-mail address, the conversion is faster still. In that case, forward it to the desk's intake address, and the ticket makes itself with the requester's words in it. Many tools have the forwarding; some do not. Some add the technician as the requester instead of the person who asked, which has to be corrected at triage. Test yours once. The twenty seconds are the budget, and the method that fits inside it is the right one for your desk.

The Team Channel That Becomes a Queue Nobody Owns

A team channel for support questions is a group queue. And a group queue is where a request belongs to everyone, which is a way of belonging to nobody. Nine messages arrive in the channel over a weekend, none with a name on them. Each is read by all four technicians and acted on by none. That is because each technician assumed one of the others had it. This is the same failure as a group-assigned ticket queue, with one extra problem: the channel scrolls. A ticket in a group queue at least sits there turning a colour. A message in a channel moves up and out of view the moment the next one arrives, and "anyone?" is what it sounds like on the way past.

The channel also encourages the worst kind of answer, which is the half-answer from a bystander. Somebody from marketing replies "mine does that too, try restarting". The requester tries restarting. The problem persists. The channel has now produced a false resolution, a second message, and still no ticket. The technicians, reading it later, cannot tell whether the matter is open, resolved, or in the hands of marketing. The channel is a queue that other people can edit. No desk would build that on purpose.

There are two honest things to do with a support channel, and keeping it as it is, is not one of them. The first is to close it to requests. Pin a message saying where requests go. Answer the next few in the channel with a ticket number and a gentle pointer. And let it become what it is good at, which is announcements from the desk and the occasional "is it just me?" that gets a one-line answer. The second is to make it a real door. This means a forwarding rule, a bot or a technician on duty that turns every post into a ticket within minutes, with the number posted back as a reply. That way, the channel is just another route into the one queue. Either works. The first is cheaper. The second is kinder. Both are better than a room where requests go to be witnessed.

Deciding Whether Chat Is a Channel at All

Chat is a support channel when the desk decides to staff it, log it and promise something about it, and not before. Compare a live chat window on the portal that opens a ticket, with a technician on duty behind it during set hours. Then consider the chat tool's direct messages to whoever is online. The difference is between a door the desk built and a window somebody left open. The first is a channel with hours, a service level and a record. The second is the hallway. Deciding which one you are running, and whether a small team can run the first at all, belongs to the article on chat support for small teams. This article only insists that the decision is made. That is because a desk that has not decided is running chat as a channel anyway, in the worst possible form, through four personal inboxes.

The decision turns on three questions. Can the desk staff it, meaning is there a named person watching the chat during stated hours, and nobody watching it outside them? Is it logged automatically, meaning does a chat conversation become a ticket without a technician pasting it? And does the requester get a number, so that the conversation can be found, chased and counted later? A chat door that answers yes to all three is a channel, and a good one for the two-minute questions the hallway does best. A chat door that answers no to any of them is a direct message with a nicer name. A help desk's live chat may itself be one of the routes into the same queue as e-mail and the form, as QuerySolv's is. In that case, it answers the second and third questions for you. The first is a rota, and no tool answers a rota.

The table's last row deserves a plain sentence. A direct message sent to a person outside the hours anyone is watching is not a request the desk has received. It is a note left under a door. The desk can be kind about that, and should be, but it cannot be responsible for it. And the status line in the next section is how it says so in advance rather than in apology.

The Auto-Reply and the Status Line

The status line is the short message the chat tool shows beside a technician's name, and it is the cheapest redirect in support. "Support requests: the form at the intranet or the desk mailbox, and you'll get a number straight away. I don't see direct messages while I'm on queue duty." That sentence does three things. It tells the requester where to go before they have typed. It tells them why the direct message will not be seen quickly. And it tells them that there is a better route with a number at the end of it. It does all three without anyone being refused anything.

Where the chat tool allows an automatic reply to direct messages, the same text goes there. In that case, the tool sends it so the technician does not have to. Some tools allow this always, some only when a status is set, some not at all. Check yours and use whatever it has. The auto-reply is not a wall. It ends with a route that works. And a requester who reads it and uses the form has had a better experience than one who waited under a dog photo for three days. (The dog is not the problem. The dog is the only part of that thread that was where it belonged.)

The wording matters more than the mechanism. The status line is read by people who were about to ask a favour. And it has to read like a colleague saying "here's the fast way" rather than a system saying "access denied". Keep it under two sentences, name the route, mention the number, and say the hours if the desk has a chat door with hours. Writing like a person rather than a policy is a skill with its own article, Writing Like a Person, Not a Policy. The status line is a one-sentence exam in it.

The Technician's Personal Messages

The direct message inbox belongs to the technician, not to the desk. And the desk should say so as a rule rather than leaving each technician to defend it alone. A technician who personally decides to ignore direct messages is being difficult. A desk whose rule is that support work does not happen in personal messages is being organised. The difference is who gets the complaint. Make it a team rule, write it in the same place the desk's hours are written, and let every technician point at it. Boundaries that hold are the ones the desk holds together. The way a team protects its people from a queue that never ends is set out in Sustainable Pacing. Personal messages are where that protection is tested first and most often.

The rule has three parts. During queue duty, direct messages are muted or minimised, and the status line says so. Outside working hours, direct messages are not read, and nothing that arrives in them is the desk's responsibility until it is a ticket. And a direct message that does arrive, in hours, from a colleague who did not read the status line, is converted to a ticket. It is answered with the number, kindly, once, with the pointer to the form. None of this is the technician refusing to help. It is the technician helping in the one place that help can be seen and counted.

The hardest messages are the ones from friends and from managers, and they are hard for opposite reasons. The friend is messaging as a friend, and being handed a ticket number feels like a rebuff. The fifth article in this series, on redirecting without alienating people, spends a section on how to do it without the rebuff. The manager is messaging as a manager, and the technician may feel that the rule does not apply upward. It does. A manager's request, converted to a ticket with its number sent back in the message, is a manager's request being treated seriously. Most managers, told "I've logged it so it doesn't get lost in my messages", recognise the sentence as a professional one. The one who does not is a separate problem, and not one the chat tool will solve.

Running the Shift Without Losing People

The move from direct messages to tickets takes about a quarter and goes in three steps. And the order matters because the first step has to earn the second. In the first month, every direct message is converted and answered with a number, with no redirect at all. The point is that requesters see a ticket treat them well before they are asked to use one. In the second month, the conversion reply gains its last sentence: "next time, the form gets to us faster than my messages, and you'll have the number straight away." In the third month, the status line and the auto-reply go up. That month, the team channel is either closed to requests or made a door. The desk then starts counting how many direct messages still arrive.

The count is what tells you it is working. Each converted direct message has a source on the ticket. So the monthly number of tickets with that source is the size of the channel. And it should fall month on month as the form and the portal take the traffic. It will not fall to zero, and it should not. A desk with no direct messages at all has probably frightened people off rather than redirected them. The way to read the count, and to tell a channel that is shrinking from one that is going underground, is in the last article in this series. Triage treats the converted message the same as any other ticket, with one adjustment for its origin, which is covered in Triage by Channel.

Expect one awkward fortnight, around the time the status line goes up, when a few people feel the door has been closed on them. It has not; it has been labelled. The conversion reply, used consistently, is what gets the desk through the fortnight. That is because every person who messages still gets help and a number, and the number is the argument. A desk that puts the status line up before it has spent a month proving the queue works has put up a sign saying "go away" with a form attached. The order is the whole method.

A Short War Story: The Weekend Message at Larkspur Media

Larkspur Media, a publisher with about a hundred and twenty staff, ran a two-person desk. Its senior technician, Tomas, was so reliable on the chat tool that the editorial floor had stopped using the form entirely. The form was for "proper" problems, and Tomas was for everything. On a Friday evening in a production week, a sub-editor called Hana messaged him that the shared drive holding Monday's print files had gone read-only for her. She got no reply because Tomas had closed his laptop at six. She assumed, reasonably, that he would see it in the morning, forgetting that the morning was Saturday. By Monday the drive had been read-only for the whole floor for two days. The print deadline had been moved by six hours at a cost the finance team later put at the price of a fair-sized laptop refresh. The publisher asked the desk why a fault reported on Friday had waited until Monday. The desk's honest answer was that the fault had been reported to a person and not to the desk. The person had, correctly, gone home. Larkspur put up status lines on both technicians the following week. It converted every direct message to a ticket for a month. It also routed the drive's monitoring into the queue so that the next read-only event would open a ticket by itself. A message to a person who has gone home is not a report. It is a hope, and the desk cannot be measured on hopes.

The Direct-Message Redirect

The template below has four pieces. These include the conversion reply sent in the direct message once the ticket exists and the status line. There is also the auto-reply, where the tool has one, and the pinned message for a team channel that is being closed to requests. Each is two sentences at most, names the route, and ends with the number or the promise of one. Fill in the form address and the mailbox once and let every technician use the same words. A redirect that sounds different from each technician reads as personal preference. The same words from four people read as the desk's rule, which is what it is.

THE DIRECT-MESSAGE REDIRECT — FOUR MESSAGES, SAME WORDS FROM EVERY TECHNICIAN
Form address: ______________________   Desk mailbox: ____________@example.com
Chat door hours (if the desk has one): ________ to ________, ________ to ________

1. THE CONVERSION REPLY (in the direct message, after the ticket exists)
   "On it. I've opened ticket ______ so this doesn't get lost in my messages;
    you'll get the number by e-mail in a minute and all the updates there.
    Next time, the form at ______________ reaches us faster than my messages,
    and you get the number straight away."

2. THE STATUS LINE (beside the technician's name, during queue duty)
   "Support requests: ______________ or ____________@example.com, and you get
    a number straight away. I don't see direct messages while I'm on queue duty."

3. THE AUTO-REPLY (where the chat tool sends one to direct messages)
   "Thanks. I'm on queue duty and don't see direct messages quickly. For support,
    use ______________ or e-mail ____________@example.com; you'll get a ticket
    number by return. If this is an outage affecting several people, call ________."

4. THE PINNED MESSAGE (in a team channel being closed to requests)
   "This channel is for announcements from the desk and quick 'is it just me?'
    questions. Support requests go to ______________ or ____________@example.com,
    where they get a number, an owner and updates. Anything posted here that
    needs work will be turned into a ticket and answered with its number."

Rules
  [ ] Convert first, redirect second; never the redirect alone
  [ ] Work happens in the ticket, not in the chat thread
  [ ] Status line and auto-reply go up only after a month of conversions
  [ ] Direct messages are not read outside working hours; the desk's hours are published

Rosa's Monday ended with fourteen direct messages converted into eleven tickets (three were duplicates of each other, which the queue noticed and the chat tool had not). The claims manager's Friday message was converted with an apology that it had been sent somewhere nobody was looking. There was also a status line on her name. She wrote it in the words above and has not changed it since. The team channel became a place where the desk posts "the shared drive is back" and people reply with a thumbs up. It is a good channel for that. It was never a queue, and it is a relief to everyone that it has stopped trying to be one.

Frequently Asked Questions