Retraining Users and Technicians Without a Course

Two weeks before the cutover at Bluewater Bank, Omar from learning and development stops by the desk with good news. He has booked six sittings of a ninety-minute classroom session on the new ticketing system, enough for all six hundred staff. He would like Helen's slides by Friday. Helen, who runs the desk of five, does the arithmetic on a notepad while he talks. Six hundred people, an hour and a half each, nine hundred hours of the bank's time. All that to teach people to send an e-mail to a slightly different address. Then she writes down what a requester actually has to learn, and gets three lines. Then she thinks about her five technicians, who have to learn a great deal more than three lines and none of it from a slide. Omar is still talking about the room booking. Helen says she will have something by Friday. It will be one page.

Retraining for a ticketing migration is getting two different audiences to do the new thing by default. Requesters need to write to the right place and trust what comes back. Technicians need to work a queue in a tool they have never used, with requesters watching. The two needs are so different that one course cannot serve both; it is too much for the first and far too little for the second. This article is part of our Migrating Ticketing Systems series, and it is about doing both without a classroom.

It covers why nobody needs a course to send an e-mail, then the three facts a requester needs and the one-page what-changed. Next come the new acknowledgment, which is the first thing most people see, and the portal link in every signature. Then it covers the desk-side first week for technicians, the old-word, new-word sheet, and catching the people who did not read any of it. A short war story and the what-changed page to copy finish the article.

Nobody Needs a Course to Send an E-mail

A requester's relationship with the ticketing system is three moments long: they write in, they get an acknowledgment, and they get a reply. Nothing about the new system changes the shape of that, and almost nothing about it needs teaching. What needs telling is where to write, what the acknowledgment will look like, and what happened to the request they already had open. Three facts fit on a page. They do not fill ninety minutes. A session that tries to fill ninety minutes with them ends up teaching the portal's menus to people who will use the portal twice a year and remember none of it. The principle, that users learn from the moment of need and not from a lecture, is the whole of Training Users Without Lecturing, and a migration is the largest single test of it a desk will face.

Technicians are the opposite case, and the course fails them too. A technician has to find the queue, claim a ticket, and tell a public reply from an internal note. They have to change a status, link two tickets, and find a requester's history. They must do all of it fast, with the requester waiting and the old system no longer there to fall back on. None of that is learned from slides. It is learned by doing it, badly at first, with someone beside you who has done it before, over about a week. A classroom session gives a technician a tour. The first week gives them a habit.

So the retraining plan has two halves that look nothing alike. For requesters: one page, one acknowledgment designed to be recognised, one link everywhere, and a plan for the people who read none of it. For technicians: a rehearsal on the test copy before cutover, pairs for the first days, a daily ten minutes, and a sheet of the old words and the new ones. Neither half has a room booking. Omar, who had only wanted to help, took this well.

The Three Facts a Requester Needs

The first fact is where to write, and it is one line per channel. The e-mail address, which may be unchanged, in which case say so, because "nothing changed" is the most reassuring sentence in the page. The portal link, which has almost certainly changed. The phone number, which has not. If the new system takes requests by web form, e-mail, live chat and the rest into one queue, as QuerySolv does, the page can say "write to us however you did before" and mean it. That is the shortest retraining there is. Where a channel has genuinely closed, say so in one line and give the replacement; do not explain why.

The second fact is what the acknowledgment looks like. The first thing most people will see of the new system is an automatic e-mail they did not expect. It comes from a sender they may not recognise, with a ticket number in a new format. Half of them will wonder if it is spam. Some will delete it. A picture of the new acknowledgment on the page, with the sender address and the subject line visible, turns an unfamiliar message into an expected one. Nobody has ever been trained to recognise an e-mail by being told about it. They recognise it by having seen it.

The third fact is what happened to the ticket they already had open, and it must be answered before anyone asks, because everyone with an open ticket will ask. The honest version is short: your open requests have moved to the new system with their full history. They have new numbers. You will get a message from the new system about each one, and replying to that message continues the conversation. If old numbers can still be found, say so. If a requester replies to an old acknowledgment, the desk will find the ticket; say that too, because it is the one thing that stops people re-sending everything from scratch.

The One-Page What-Changed

The what-changed page is one page, and the limit is the whole design. It is read by someone who has forty seconds and a problem, usually on the morning they first need the desk after the switch. A second page is a page they will not reach. The top five lines carry the three facts in their shortest form. The rest of the page expands each one, shows the acknowledgment, lists what did not change, and gives one person to ask. Anything about the project, the vendor, the reasons for the move or the benefits is cut, however proud of it the desk is. The requester did not ask for a new system. They asked for a new mouse.

The page goes everywhere the requester already looks, which is not the training portal. It is attached to the cutover announcement and pinned to the top of the intranet page where the old portal link was. It is printed and taped beside every printer for a month. It is sent again a week later to the people who wrote to the old address, as the next sections cover. Writing it is an hour. The hour is spent cutting, not adding, and the test is to hand it to someone outside IT and ask them to find the e-mail address in five seconds. If they cannot, the page is still too long.

Write it for the reader who is slightly annoyed. They have a broken thing, they know how they used to get help, and somebody has changed it. The page's tone is therefore plain and brief, with "nothing else has changed" said early and the one new thing they must do said in the first line. It is not the place for enthusiasm about the new portal's features. There will be time for that, after the portal has helped them once.

The New Acknowledgment

The acknowledgment is the automatic reply the system sends when a request becomes a ticket. On the day of the switch it is the new system's whole public face. It must name the desk the way requesters know it, not the way the vendor's default names it. It must carry the ticket number prominently, say in one sentence what happens next and when, and tell the requester to reply to this message to add to the request. It should look different enough from the old acknowledgment that people notice the change and similar enough that they trust it. That is a narrow target, and it is hit by iteration, not by the default.

Test the acknowledgment on five people outside IT before the cutover. Send each a real one, from the test system, to their work address, with no warning beyond "you may get something from the desk today". Ask them afterwards what they did with it. If two of the five thought it was spam, the sender name or the subject line is wrong. If anyone could not find the ticket number, move it. If anyone asked "so what do I do now", the one sentence about what happens next is missing. Five people and twenty minutes will catch what six hundred people would otherwise catch on the Tuesday, loudly.

Send the test acknowledgments to a couple of personal addresses too, and to any department whose mail is filtered more strictly than the rest; finance usually is. A new sender address that lands in six hundred junk folders is not a training problem, but it will look exactly like one, and nobody will know which it is until Thursday. The acknowledgment is also where the old-number question gets answered for the people who never read the page. A line saying "if you are writing about a request raised before the move, quote the old number and we will find it" costs nothing. It is read by exactly the people who need it.

The Portal Link in Every Signature

The new portal link goes into the desk's own e-mail signatures on cutover day and into the organisation's standard signature if there is one. It goes onto the intranet home page and onto the printed notice by the printers. The old link is pointed at a page that says where the new one is. People find the portal by following links from places they already are, not by remembering an address. So the retraining for the portal is almost entirely a question of where the link lives. A link in every signature means every reply from the desk teaches the portal's location, once per ticket, forever, to exactly the person who just needed the desk. The wider method of getting people to the portal without irritating them is in Promoting the Portal Without Nagging; the migration is the moment to start it, because everyone is already looking.

The old address and the old link keep working for months, in the sense that people keep using them, and both should answer. The old link redirects or lands on a one-line page. The old address, if it cannot simply be redirected into the new system, carries an automatic reply with the new address in the first line and nothing else of substance. These two measures teach more people where the desk went than any announcement, because they teach at the moment of need, which is the only moment anyone is listening. The principle that every door should lead to the same queue is in One Queue, Many Doors; after a migration the old doors are still doors, and they should open onto the new room.

The Desk-Side First Week for Technicians

Technician retraining starts before the cutover, with a rehearsal on the test copy, and the rehearsal is work, not a demonstration. Each technician spends an afternoon on the test system doing the week's ordinary tasks against the fifty sample tickets. Claim one, reply to it, add an internal note. Put one on hold with a reason, close one with a resolution note. Link two that are the same problem, find a requester's history. They do it from the old-word, new-word sheet, not from a manual, and every question they ask goes on a list. The list is the first week's agenda. The test copy is also where the mistakes happen, which is what it is for.

On cutover day and the two days after, nobody works alone in the new system. Technicians pair up, one handling tickets and one watching the mechanics, and swap at lunch. The pairing catches the quiet mistakes, a reply sent as a note, a note sent as a reply, a ticket claimed and forgotten, before they reach a requester. The one distinction to drill from the first hour is public reply versus internal note, in QuerySolv as in any tool that has both. Sending the internal note about a difficult requester to the difficult requester is the mistake that cannot be taken back. Everything else in the first week is recoverable. That one is a conversation with a manager.

Every morning of the first week, the desk spends ten minutes together on two lists. The first is the "how do I" questions from yesterday, answered once in front of everyone. The second is the oddities list from the cutover runbook, triaged into fix, live with, or ask the vendor. The ten minutes is the course. It is attended by everyone who needs it, it covers exactly what came up, and it is over before the queue builds. By Friday the "how do I" list is usually empty and the oddities list has become a short note to the vendor. A desk that skips the ten minutes learns the same things, one technician at a time, over a quarter, by making each mistake separately. The first week in a new tool has a lot in common with the first week running a desk at all. The habits in Your First Week Running a Helpdesk are worth re-reading with the new system open.

The Old-Word, New-Word Sheet

Every system has its own vocabulary, and a technician's first week is spent translating. The old system called it a queue; the new one calls it a department. The old one had "Parked"; the new one has a waiting status and a reason. The old one assigned tickets; the new one lets a technician claim them. The sheet puts the old word, the new word and what actually changed in practice on one page, pinned beside every screen for the first fortnight. It is also the fastest way to spot where the new system's model differs from the old one's. The rows where the third column is long are the rows where habits will break.

Build the sheet from your own two systems, not from this one; the rows above are the shape, and half of them will not apply. The exercise of filling in the third column is itself most of the technician training. It forces the person writing it to find out how each thing actually works in the new system before telling five colleagues. Write it, test it on the rehearsal afternoon, and expect to correct three rows by Wednesday.

Catching the People Who Did Not Read It

Most people will not read the page, and the plan assumes it. The signals arrive on the Tuesday afternoon and through the week. They are messages to the old address, walk-ups asking "where do I send this now", replies to old acknowledgments, and a steady trickle of "is this e-mail from you genuine". None of these is a failure of the requester. Each is a person meeting the change at their moment of need, which is the only moment the retraining could ever have worked. Each is handled the same way: help them, tell them the one new thing in one sentence, and move on.

The technician's sentence is the retraining that works. "I've put that in the new system for you; the number is 1042, and you'll get a confirmation from the desk's new address in a moment. Next time, the same request can go straight to that address, or through the link in my signature." It is said once, warmly, with the fix already underway, and it is not followed by a reminder about the announcement. A requester who writes to the old address three times in a month is not ignoring the desk. They are busy. The automatic reply on the old address does the reminding, politely, as many times as it takes, and never sounds tired.

Send the page a second time, a week after the cutover, to the people who used the old address or walked up. Put one line at the top saying the desk has moved and leave the rest unchanged. It is short and targeted at exactly the people who need it. It arrives after they have met the new acknowledgment at least once, which is when it finally makes sense. Count the messages to the old address daily; the number should fall through the first fortnight and reach a trickle by the end of the month. If it does not, the old address is still in a signature or a handbook somewhere, and the fix is to find the page, not to retrain the people.

A Short War Story: The Course Nobody Attended at Acme

Acme's desk lead, Dev, agreed to six classroom sessions on the new ticketing system in the fortnight before the cutover. Forty-one of five hundred staff attended, most of them from the departments that already used the portal correctly. On the Monday after the switch, which had been a weekend, the old address received just over three hundred messages. The desk's phone did not stop until eleven. Sixty-odd people forwarded the new acknowledgment to the desk asking whether it was a phishing attempt. Its sender name was the vendor's default and nobody had seen it before. Dev's five technicians spent the week forwarding mail from the old address into the new system by hand and answering "is this genuine" instead of working tickets. The week's resolution times were the worst in the desk's records. On the Thursday, Dev wrote a one-page what-changed with a picture of the acknowledgment on it and renamed the sender. Dev put an automatic reply on the old address and sent the page to everyone who had written to the old address that week. By the following Tuesday the old address was down to a dozen messages a day. The lesson Dev kept was that the course had reached the people who did not need it and the page reached the people who did. The page had taken an hour.

The What-Changed Page

The template below is the whole page; nothing is added below it. The top block is the three facts in one line each, because it is the only block most readers will finish. Replace the bracketed items, insert a real picture of the acknowledgment where the template says so, and cut any line your desk does not need. Keep it to one printed side. If a line about the project or the benefits is tempting, the place for it is the intranet news page, not here.

THE IT DESK HAS MOVED TO A NEW SYSTEM — WHAT CHANGED FOR YOU
From [day, date]

The short version
  Write to us at:        [new address]  (the old address still reaches us for now)
  Or use the portal at:  [new link]      (the old link redirects to this one)
  Phone, as before:      [number]
  Open requests you had: moved across with their history; you will get a new number for each
  Everything else:       the same people, the same hours, the same promises

What you will see
  When you write in, you will get an automatic confirmation from [sender name]
  <[sender address]> with a subject line like "[subject pattern] #[number]".
  It is genuine. Keep it; replying to it adds to your request.
  [PICTURE OF THE NEW CONFIRMATION E-MAIL, WITH SENDER AND SUBJECT VISIBLE]

Requests you already had open
  Every open request has moved to the new system with its full conversation.
  You will receive one message per request from the new system with its new number.
  Reply to that message to continue; if you reply to an old message instead, we will
  still find it. If you are writing about an old request, quote the old number.

Using the portal
  The portal at [new link] lets you raise a request, see all your open requests,
  and read the answers to common questions. Sign in with [what you sign in with].

What did not change
  Who helps you, when we are open, how quickly we aim to respond, the phone number.

If something looks wrong
  Ask [name], [address], or any member of the IT desk. A confirmation you did not
  expect, a request you cannot find, or a link that does not work are all worth
  telling us about in the first week.

Helen's page at Bluewater Bank ran to one side with the picture, went out with the cutover announcement on the Tuesday afternoon, and was pinned beside eleven printers by Wednesday. Omar released the room bookings. The desk ran pairs for three days and the ten-minute huddle for a fortnight. The old address was down to a handful of messages a day by the end of the second week, most of them from one branch whose handbook was eventually found and corrected. Nine hundred hours of the bank's time stayed where they were. Nobody, as far as Helen could tell, missed the course.

Frequently Asked Questions