Chat Support for Small Teams

"We typically reply in a few minutes." The widget in the corner of the intranet page says so, in a friendly green bubble, to everyone who opens it. The desk behind the widget is two people. One of them is at lunch. The other is under a desk in accounts, holding a network cable and a flashlight. That technician has not seen the chat window since 11:40. The widget does not know any of this. It says "a few minutes" to the fourth person in a row, and it means it.

Live chat is the channel small desks add first and regret first, for the same reason both times. It is easy to switch on and hard to staff. This article is part of our Channel Strategy series. The series covers what each support channel is good at, what it costs the desk, and which doors to leave open. The subject here is live chat: a widget on a page, answered live by a person or, within strict limits, by a bot.

It covers what chat is good at and bad at, and the three conditions under which it earns its keep. Then come staffing it honestly, the rule that every chat is a ticket, and what a bot may safely say. Next are the promise the widget makes, a worked example and a war story, and a chat policy card to copy. Your real chat support may happen in the internal chat tool, in direct messages that begin "quick one". That is a different problem, and it belongs to One Queue, Many Doors.

What Live Chat Is Good At

Live chat is a widget on a page, usually the intranet or the support portal. A user types a message there, and a person on the desk answers it while they wait. It is a conversation, not a document. That is its whole strength and its whole weakness.

Chat is good at quick questions and status checks. "Is the VPN down or is it me?" "Which printer is the one by the kitchen?" "Any news on my laptop?" Each takes the user ninety seconds to ask and the technician thirty seconds to answer from the queue. Neither of them wants a six-line acknowledgment for it. By phone the same question costs the same minute plus an interruption. By e-mail it costs a ticket, a reply, and a close. Chat is the channel built for a question that fits on one line.

Chat is good at a first answer while the ticket is created. A user who types "my screen is flickering" can be told, within the minute, "I've opened ticket 6218 for that. I'll be with you by two. Try a different cable in the meantime." The ticket exists, the user has a number, and the desk has its first piece of diagnosis before anyone picks up a screwdriver. That is as good as intake gets.

What Live Chat Is Bad At

Chat is bad at anything that takes twenty minutes. A conversation that lasts twenty minutes holds both people for twenty minutes. The technician cannot walk away without the user watching the little dots stop. The user cannot go to their meeting. By ticket, the same problem takes the same twenty minutes of work and no minutes of waiting.

Chat is bad at anything that needs hands on hardware. The technician under the desk with the flashlight is not typing. A chat about a dead docking station ends, every time, with "I'll come and look". Everything before that line was a slow way to open a ticket. Open the ticket first and skip the slow part.

Chat is bad at anything that needs a record. A transcript is a record only if it lands in the ticket system. Left in the widget's own history it ages into a wall of green bubbles nobody can search. Three months later what was agreed about the finance export is in a conversation between two people, one of whom has left. Chat forgets things on purpose.

Chat is bad at being the only door. The web form is always open, needs nobody on rotation, and takes an attachment. The form is the door; chat is the window beside it.

When Chat Earns Its Keep

Chat earns its keep on a small team when three conditions hold at once, and not before. The first is volume: enough short questions that answering them live saves more time than the tickets they would have been. The second is hours: a window every day in which somebody is at a keyboard, watching the widget, and not under a desk. The third is a knowledge base that already answers about half of the short questions, so that the person on chat is mostly pasting links. Two of the three and chat is a cost. All three and it is the cheapest channel you have.

Count the short questions before switching anything on. Take one week of tickets, the shared mailbox and the chat tool, and mark every request answered in under five minutes with no follow-up. The channel census in The Support Channels, Explained counts by channel. Here the only number that matters is how many requests were short. Fewer than ten a day and chat is a widget with nobody in it. More than thirty and it pays for itself in a week.

Be honest about the hours, because the widget will not be. "Business hours" means forty-five hours a week of someone watching a window. On a two-person desk, that is one person's whole week and a slice of the other's. Two hours a day, posted, is a chat channel. Nine hours a day, hoped for, is a chat channel that is mostly an apology.

Check the knowledge base before the volume. Chat on top of an empty knowledge base turns every short question into a short composition exercise. A technician typing the guest wireless answer for the eleventh time is not providing live support. They are providing live typing. Write the ten commonest answers as published articles first, and chat becomes a channel for pointing at them.

Staffing It Honestly

Staff chat with a rotation, not a volunteer. A rotation is a written schedule that says who watches the widget in which window, posted where the desk can see it. Without a rotation the widget belongs to whoever feels guilty, and guilt is not a staffing model.

Post the hours, in the widget and on the page around it. "Chat is staffed 10:00 to 12:00 and 14:00 to 16:00, Monday to Friday" is a promise a two-person desk can keep. The user who arrives at 12:30 sees the hours and the form, and nobody has been misled. The user who arrives at 12:30 at a widget that says "a few minutes" waits, then waits, then opens a ticket. And the ticket is now about two things.

Give the widget an away state that offers the form. Most desks leave it on the default, which says "leave a message" and creates a second mailbox. The away text should say when chat is next staffed, where the form is, and that the form gets the same response promise. The one on the card at the end of this article does all three in four lines.

Decide what the person on rotation does when the widget is quiet, because it will be, for stretches. The rule I use is that the chat window is a tab, not a job. The person on rotation works tickets as usual with the widget open and audible, and switches when it chimes. The alternative, a person watching a window for two hours, is how desks come to believe that chat costs a full-time technician. It costs a tab and a chime.

Every Chat Is a Ticket

The rule that keeps chat from becoming a shadow channel is one sentence: every chat is a ticket. Every chat, from the first message, so that the history lives in the queue with everything else. A chat that answered "which printer is by the kitchen" is a ticket that resolved in forty seconds. The desk learns from counting those just as it learns from counting the hard ones.

Create the ticket on the first message, not at the end. Suppose the ticket exists only when the conversation finishes. Then the conversations that end badly, with the user walking away or the technician pulled under a desk, never become tickets. In that case, the desk's record of chat is a record of the chats that went well. A ticket at the first message captures the abandoned ones, and the abandoned ones are the channel's honest report card.

When a chat needs more than five minutes, move it into the ticket and say so. "I've got everything I need. This is ticket 6218, I'll update you by three, you can close the chat." The user is released, the technician is released, and the work continues where work is supposed to continue. Nobody has to watch the dots.

Bots That Know Only What the Knowledge Base Knows

A chat bot is a program that answers the first messages in a chat before, or instead of, a person. On a small desk there is exactly one safe design for it. That bot can say only what the published knowledge base says and can collect the details a ticket needs. It hands off to a human the moment it is asked. Everything else a bot can be configured to do is a way of being confidently wrong at scale. How to build that one safe design on your own knowledge base, without sending it to a vendor cloud, is in A Knowledge Base Chatbot Without a Vendor Cloud.

A bot may safely answer from published articles. Suppose the user asks for the guest wireless password and a published article gives it. The bot may then quote that article, with a link, and ask whether that answered the question. It is not generating an answer; it is finding one a human already wrote and approved. If no article matches, the only correct bot answer is "I don't have an article for that. Let me take the details and a person will pick this up."

A bot may safely collect the ticket details: name, which machine, what you were doing, what you saw, and how urgent it is in the user's own words. A bot that asks those five questions and files the answers into the ticket does the part of intake technicians like least. It does it at 06:30 when nobody is on rotation. The person who picks up the ticket at 09:00 starts from a filled-in form rather than from "it's broken".

A bot must hand off on request, every time, with no argument. "Talk to a person" ends the bot's turn. A bot that answers "talk to a person" with "I can help with that, what seems to be the problem?" is the reason people distrust bots. It is a configuration choice, not a law of nature. A hard limit on turns does the same job for the user who did not know the magic words. After two or three exchanges, a human takes the ticket.

A bot must not guess, promise, or act. It must not compose an answer when no article matches, because it will compose one that sounds right. It must not promise a time that no rotation backs. And it must not reset a password or unlock an account. A bot with the authority to act is an unauthenticated web form with the authority to act. The bot's job is to point at approved words and take a message. It should not be promoted.

The Widget Text and the Promise

The widget's text is a service-level promise whether or not you meant it as one. "We typically reply in a few minutes" is a promise of a few minutes. A user who waits twelve has been told something untrue by a green bubble. Write the widget text the way you would write a service level agreement, a written promise about response times. Give a number you can keep in the hours you have posted, and keep silent about the hours you have not. The SLA Design pillar covers choosing the number.

Say three things in the staffed state: that a person is here, the response time they can expect, and that a ticket has been created. "You're chatting with the IT desk. We answer within five minutes during chat hours. A ticket has been opened for this conversation and you'll get its number in a moment." The third sentence tells the user that the conversation has a record and a future, so that leaving it is not losing it. And keep the number smaller than the capacity. If the rotation answers in three minutes on an ordinary day, promise five. The promise is read on the bad day.

A Worked Example: Two Hours on Chat at Meridian Parts

Meridian Parts runs a two-person desk, Dana and Tomas, for about one hundred and eighty staff. Chat is staffed 10:00 to 12:00 and 14:00 to 16:00, with Dana on the morning window and Tomas on the afternoon. A bot answers first, from forty-one published articles, and hands off after two exchanges or on request. The widget promises five minutes during chat hours, and the away text points at the form.

On a Wednesday morning window, Dana's log reads like this. At 10:04 a chat asks whether the label printer in dispatch is down. The bot finds no article, collects the details and hands off. Dana answers at 10:05 and restarts the spooler at 10:08. Ticket 6281 is resolved by 10:09 with the transcript inside it. At 10:17 a chat asks for the guest wireless password. The bot quotes the published article, the user types "thanks", and ticket 6282 closes at the bot's answer with no human involved. At 10:40 a chat begins "any news on my laptop". Dana reads ticket 6250 from the queue and replies "parts due Friday, I'll update you then" at 10:41. At 11:12 a chat describes the finance export failing. Dana spends four minutes collecting details, then says "this is ticket 6284. I'll be with you by two. You can close the chat". Dana goes back to the queue.

Four chats in two hours: one resolved by the bot, one status check, one resolved live in five minutes, one converted into work on a ticket. Total time on chat, about eleven minutes. Four tickets exist that would otherwise have been three e-mails and a walk-up, and each e-mail alone would have cost more than eleven minutes. This is what chat looks like when the three conditions hold. It is not dramatic. It is cheap.

Measuring Whether Chat Is Working

Measure chat with five numbers a month, all of which exist if every chat is a ticket. Each tests one of the three conditions or the promise in the widget.

Read the numbers against the conditions, not against a target. They do not say whether chat is good or bad. They say which condition has slipped, and the fix is in the last column. If every chat is a ticket, the numbers come out of the ticket tool's reports rather than the widget's. QuerySolv's channel comparison report, for example, counts chat tickets beside e-mail and form tickets because they are the same kind of ticket.

A Short War Story: Two Hours a Day at Bluewater Bank

Bluewater Bank's branch support desk, three technicians for forty branches, opened live chat for two hours a day. A bot in front of it could only quote the published knowledge base and handed off after two exchanges or on request. Priya ran the numbers at the end of the first month. A third of chats had ended at the bot's answer, nearly all of them the same six questions about card readers and the branch wireless. The rest had arrived in the queue as tickets with the branch number, the device and the symptom already collected. That cut the first call-back from eight minutes to under three. The one thing that had gone wrong was the away text. For the first week it said "leave a message" and collected forty messages nobody saw until Monday. Pointed at the form instead, it collected two the following week.

I have made that away-text mistake myself, on a desk of one. The messages were very polite. There were a great many of them.

The Chat Policy Card

The card below is the chat channel on one page. Fill in the blanks, post it where the desk can see it, and paste the two quoted blocks into the widget. Review it whenever the rotation changes, because the rotation is the only part that will.

The shape this card describes is a widget that creates a ticket on the visitor's first message, with an optional bot. That bot can say only what published knowledge-base articles say, stops after a fixed number of turns, and hands off on request. QuerySolv's live chat works that way. The card does not depend on the tool, only on the rules being written down.

CHAT POLICY CARD              Desk: ____________   Reviewed: ________

HOURS
  Chat is staffed ______ to ______ and ______ to ______, Mon-Fri.
  Rotation: morning window ____________  afternoon window ____________
  Cover when the named person is out: ____________

PROMISE (paste into the widget, staffed state)
  "You're chatting with the IT desk. We answer within ___ minutes
   during chat hours. A ticket has been opened for this conversation
   and you'll get its number in a moment."

BOT SCOPE
  May:      quote a published knowledge-base article, with a link
            ask name, machine, what you were doing, what you saw,
                and how urgent in your own words
            hand off to a person
  Must not: answer when no article matches
            promise a response time
            reset, unlock or change anything
  Turn limit: ___ exchanges without a resolved answer, then hand off.

HANDOFF RULE
  "Talk to a person" ends the bot's turn. Every time.
  A chat that needs more than five minutes becomes work on the ticket:
  "This is ticket ____, I'll update you by ____, you can close the chat."

TICKET RULE
  Every chat is a ticket from the first message. The transcript lives
  in the ticket, not in the widget's own history.

AWAY TEXT (paste into the widget, away state)
  "Chat is staffed ______ to ______ and ______ to ______, Mon-Fri.
   Nobody is on chat right now. Use the form at help.example.com/new,
   which gets the same response promise, or e-mail support@example.com.
   You'll receive a ticket number either way."

When the card is filled in, go back and read the green bubble one more time. If it still says "a few minutes" and the card says two hours a day, change the bubble. It has been making promises on your behalf for long enough.

Frequently Asked Questions