Announcing the Helpdesk to the Organization

The launch e-mail went out at 16:50 on a Friday. It was four hundred words long, had a screenshot, and explained the new categories. It ended with "please let us know if you have any questions". At 08:45 on Monday, Marcus from accounts is standing at the desk with a laptop under his arm. "Morning. Did something change? My e-mail is doing a thing." He has not read the e-mail. Nobody has read the e-mail. It arrived at the moment the organization stopped reading e-mail for two days. By Monday it was under forty newer ones.

A help desk nobody uses is a shared mailbox with better reporting. This article is part of our Helpdesk From Scratch series. It is about the part of building a desk that is not configuration: getting the organization to put things in it. Adoption is the share of requests that reach the desk through the desk, rather than through a hallway, a direct message or the old address. Most of it is decided in the two weeks around launch.

It covers what the announcement has to do and the message, with a template. Next comes timing, which is not Friday afternoon, followed by the walk-up redirect and winning the first fifty tickets. Then we cover the managers' briefing, the two-week follow-up, and how to tell whether the launch took. We finish with the launch kit on one page.

What the Announcement Has to Do

The announcement has to leave three things in people's heads: one address, one reason, and one promise. The address is where requests go, one of them, written the same way everywhere. The reason is what the reader gets out of it, in one sentence, from their side of the desk. The promise is what happens after they send something, and when. Everything else in the e-mail is weight.

Three things, because people retain about one thing from an e-mail, and you want it to be the address. If they remember the address and nothing else, the desk works. If they remember categories and a portal and a priority field, but not where to send things, the desk has been described without being adopted.

The announcement must not be a feature tour. The temptation is strong, because you have spent two weeks setting the thing up and the categories are rather good. Nobody outside the desk cares about the categories. They care about whether their e-mail will do a thing on Monday and who will fix it. The four-hundred-word e-mail with the screenshot is a tour of a building the reader has not agreed to enter.

The promise is the only part to be careful with, because it is the only part anyone will hold you to. Promise what the intake process can keep on its worst day. That means a reply from a person within the hour during working hours, or by the next working morning. Do not promise a fix time. A fix time is a promise about problems you have not seen yet.

The Message

The message has five parts, in this order: what changed, how to reach us, what you get back, when, and what has not changed. It is under two hundred words, written for someone reading on a phone in a corridor. That is where it will be read. Here is one to copy.

Subject: One address for IT help from Tuesday: help@example.com

What changed
From Tuesday, every request for IT help goes to one place:
help@example.com, or the form at help.example.com. That includes
the things you would have asked us in the corridor.

How to reach us
E-mail help@example.com, or use the form at help.example.com. No
account, no password. Tell us what is wrong and which computer.

What you get back
A ticket number by e-mail within a minute, and a reply from a
person within the hour during working hours. Replying to that
e-mail reaches the same person.

When
Tuesday 09:00. The old address keeps forwarding for a month.

What has not changed
The phone still works for anything that cannot wait, and we will
still come to your desk. We will open the ticket for you.

Thank you for using it. The first week will teach us more than the
month of setting it up did.
-- Lena, IT

Each part answers a question the reader is already asking. "What changed" settles whether this applies to them. "How to reach us" is the address, twice, because the address is the point. "What you get back" is the receipt and the promise. "When" is a day and a time, so Tuesday's walk-up has no excuse and no grievance. "What has not changed" is the part people cut. It is also the part that kills the rumor that IT has stopped answering the phone.

Sign it with a name. An announcement from "IT Support" was written by a department. One from Lena was written by someone who will be at the desk on Tuesday. People send tickets to people and complaints to departments.

Timing: Not Friday Afternoon

The launch is three touches, not one: a briefing for managers two weeks before, the announcement on the day, and a follow-up two weeks after. One e-mail is a notice. Three touches over a month are a change, and people treat them differently.

Send the announcement on a Tuesday or Wednesday, mid-morning, after the first pass through the inbox and before lunch. Not Monday, because Monday's inbox is a backlog and your e-mail is in it. Not Friday, because the e-mail ages two days before anyone acts on it, and the first thing they do on Monday is walk up. I sent a launch e-mail on a Friday once. Monday was educational.

Switch on the autoreply on the old address at the same moment, and keep the old address forwarding into the desk for a month. The autoreply says one thing: this address is closing, use help@example.com, your message has been forwarded this time. Forwarding stops month-one requests being lost. The autoreply teaches the address to the people who skipped the announcement, which is most of them. Retiring the old mailbox properly belongs to the channel strategy pillar; the launch only needs it to stop being the front door.

The Walk-Up Redirect

The walk-up redirect is one sentence, said the same way by everyone on the desk. It moves a corridor request into the queue without sending the person away: "I can look at that now. Let me open a ticket so it's tracked, and you'll get the number by e-mail." The person asked for help and gets help. The desk gets a ticket. Nobody has been scolded.

The sentence works because it changes who does the typing. "Put it in a ticket" is an instruction. An instruction to someone with a broken laptop under their arm lands as a refusal. "Let me open a ticket" is a service. For the first month, the desk opens every walk-up ticket on the user's behalf, with the user's address as the requester. That way, the receipt and the replies go to them. The habit forms on the receipt e-mail, not on the lecture.

WALK-UP CARD (keep one at the desk, one at reception)

Say:   "I can look at that now. Let me open a ticket so it's
        tracked, and you'll get the number by e-mail."

Then:  open the ticket with THEIR e-mail address as requester,
       source = walk-up, one line describing the problem.

If busy:  "I'm mid-way through something. Let me open a ticket
           for you now and I'll be with you in [time]."

Never:  "You need to put that in a ticket."

From month two, the sentence shifts to asking the user to send it themselves. The promise is that it will be picked up straight away, and that promise has to be true that day. By then most people have a receipt e-mail from month one and know what sending one gets them. The handful who keep walking up usually have the problems that are hardest to type, and the desk can keep opening those.

Without the redirect you get one of two things. One possibility is that the walk-ups are fixed off the books. Then the desk's count and staffing case are wrong by a third. Or a sign goes up saying NO WALK-UPS, and the organization learns that the new desk is a wall. The sign is laminated, which makes it permanent and unloved.

Winning the First Fifty Tickets

The first fifty tickets are the launch, and the e-mail was the invitation. Each of those tickets teaches one person whether the desk is worth using, and that person tells three others. Three things win them: a fast acknowledgment, a visible fix, and a thank-you.

The fast acknowledgment is a reply from a human within the promised hour, naming the next update time. The automatic receipt does not count; people know what a robot sounds like. "Looking at this now, I'll update you by 11:30 either way" is the sentence. It is the announcement's promise being kept in public for the first time. Keep it on fifty tickets and the desk has a reputation. Miss it on five and it has a different one.

The visible fix is one problem that annoys many people, fixed in launch week, from a ticket. It is named in the follow-up as having come from a ticket. Every organization has one: the printer that jams, the shared drive that asks for a password twice, the application that is slow after lunch. Pick it before launch and fix it in week one. The follow-up then says "the depot printer was fixed because someone sent a ticket". And that sentence does more for adoption than the announcement did.

The thank-you is one line, on the first ticket from each person, thanking them for using the desk. Not a template paragraph; one line, from a human, inside the first real reply. People repeat what was rewarded. Nobody has ever been thanked for writing to a shared mailbox, and the shared mailbox had the adoption to show for it.

The Managers' Briefing

Two weeks before launch, brief the managers: five minutes, one slide, at the end of a meeting they already attend. Their job on launch is one sentence, said whenever someone on their team asks them to ask IT: "Put it in a ticket, that's what it's for." Managers route requests whether they mean to or not. A manager who has not heard of the desk forwards to the old address, with a note. That creates a ticket with two requesters and no owner.

The slide has four lines: the address, the promise, what they get back, and the one sentence. What they get back is a monthly line with their department's ticket count and oldest open item. This is the first time most managers will have seen what their team asks for. Few will refuse that. Several will ask for it weekly, which you can decline until month three.

Ask for one thing in the briefing: each manager's own next request should go through the desk, in launch week. Their team should be able to see them do it. A manager who uses the address is worth more than a manager who endorses it. Endorsements are cheap, and everyone in the room knows the going rate.

The failure the briefing prevents is the side channel: a manager who keeps a direct line to "their" technician for the things that matter. The desk becomes two desks, one of which has no record. It is hard to close a side channel once it has a year of history. It is easy to not open one, which is what the five minutes are for.

The Two-Week Follow-Up

Two weeks after launch, send a second message, shorter than the first: the numbers, a thank-you, and the one thing you changed because of feedback. Keep it under a hundred words, to the same list as the announcement, at the same time of day. Put "two weeks in" in the subject line.

The numbers are three: tickets received, tickets closed, and the median time to the first human reply. They prove the desk reads what it receives and answers it. The thank-you is one sentence. The one thing changed is the sentence that matters: "Because a third of you did not know which computer you had, that question on the form is now optional." It tells the organization that sending a ticket changes something, which is the only reason anyone sends a second one.

The follow-up also reaches the people who skipped the announcement. A message with numbers in it gets opened by people who ignore one with a screenshot. Some of your month-two adoption comes from people who first heard of the desk from the follow-up. That is fine. The address has not moved.

Measuring Whether the Launch Took

Three signals tell you whether the launch took. All three come free from a desk that logs walk-ups and keeps the old address forwarding. Tickets per week should rise for three or four weeks and then level off. Walk-ups should fall as a share of the total. Messages at the old address should fall to nearly none by week four. Read them in the weekly review next to the three numbers the desk already keeps.

A department that sends no tickets is the signal to take most seriously, because it is never the department with no problems. It is the department with a side channel, a helpful colleague, or a manager who missed the briefing. Go and ask. The answer is usually one conversation long.

A Worked Example: Launch Week at Meridian Parts

Lena launched the Meridian Parts help desk for one hundred and eighty staff at a head office and a depot. She used one address and the three-touch plan. On the Wednesday two weeks before, she took five minutes at the end of the managers' meeting with one slide. There were eight managers, two of whom sent a test request that afternoon to see what came back.

On launch Tuesday, the autoreply went on at 09:00 and the announcement went out at 09:20, one hundred and eighty-four words long. Cards went on the desk and at reception. By 17:00 there were fourteen tickets, six of them opened by Lena from walk-ups. There were two messages at the old address, both forwarded and answered from the queue. The depot printer that had been "known about" for a year came in as ticket 1012 at 10:40 and was fixed by 15:00.

Week one closed with forty-one tickets, eleven of them logged walk-ups, and seven messages at the old address. Week two: thirty-seven tickets, five walk-ups, two old-address messages. Median time to a human reply was twenty-three minutes. One pattern showed in the ticket text: about a third of requesters had left the "which computer" field blank or guessed.

On day fifteen, Lena sent the follow-up at 09:30, ninety-one words. It reported seventy-eight tickets, seventy-one closed, and first reply in twenty-three minutes. It said thank you and that the depot printer is fixed because someone sent a ticket. It also said the "which computer" question is now optional because a third of you did not know. Week three closed with forty-four tickets, three walk-ups, and nothing at the old address. The depot, which had sent four tickets in week one, sent twelve in week three. The printer had done the briefing for her.

A Short War Story: Two Launches at Kestrel Payroll

Kestrel Payroll's first help desk launch was an e-mail on a Thursday afternoon, with no managers' briefing and no walk-up sentence. It got eleven tickets in a month while the shared mailbox carried on at its usual pace. Priya decided to treat it as a rehearsal rather than a verdict. Six weeks later she launched again with the same tool and the same address. This time she used the managers' briefing on one slide and the walk-up card with tickets opened on the user's behalf. She also used the autoreply on the old mailbox and a follow-up on day fourteen. The second launch got sixty tickets in its first two weeks. The old mailbox received four messages in week three, two of them from a vendor. Nothing about the software had changed between the two launches. The difference was that the second time the organization had been told, by someone it reported to, in a week when it was listening.

I have seen the rehearsal happen more often than the clean first launch, and I no longer think it is a failure. The first launch tells you which departments are not reading e-mail. The second launch goes and finds them.

The Launch Kit

The kit is everything above on one page, written before launch day, so the day itself is only sending things. The part that takes longest is choosing the visible fix, and that is time well spent.

LAUNCH KIT
[ ] The address, written one way, on everything below
[ ] The announcement: five parts, under 200 words, signed by a person
[ ] The managers' slide: address, promise, what they get, the sentence
[ ] Managers' briefing booked: five minutes, two weeks before
[ ] The autoreply on the old address, written and ready to switch on
[ ] Old address forwarding into the desk for one month
[ ] The walk-up card: at the desk and at reception
[ ] The visible fix chosen, and its ticket planned for week one
[ ] The follow-up drafted with blanks for the numbers, dated day 14
[ ] The three launch signals added to the weekly review sheet
[ ] Send day: Tuesday or Wednesday, mid-morning, not Friday

One thing makes every item on the kit easier: a way in that nobody can fail at. If the form needs an account, a password, a modern browser or a plug-in, the first walk-up of launch week is someone who could not get in. That story travels faster than the announcement. QuerySolv's requester portal is built on that principle: no account, no password, no scripting, requesters identified by e-mail address. So the only thing the announcement has to teach is the address. Whatever your tool, test the way in on the oldest machine in the building before you send anything.

Then send it on a Tuesday, at 09:30, signed with your name. Marcus will still walk up on Wednesday with a laptop under his arm, and that is fine. You have a sentence for that now, and a card. By month two he will have a receipt e-mail with his name on it and a reason to send the next one himself.

Frequently Asked Questions