First-Week Support for New Starters, From Welcome Note to Day Three

Wednesday, 11:10, at Bluewater Bank, where Imogen runs a desk of five. Kwame started in the mortgage team on Monday. His onboarding was textbook: request ten days out, kit built, ready test passed, handover done at nine. He has raised no tickets. Imogen would have called that a success until the mortgage team's manager stopped by the desk on his way to a meeting. He said, "Could someone have a look at Kwame's laptop? He hasn't been able to print since Monday, but he didn't want to bother you." Two days. Two days of a new person walking to a colleague's desk with a memory stick, because the desk looked busy and he did not know he was allowed to ask.

First-week support is the deliberate attention the desk gives a new starter between the morning handover and the end of their first week. It includes a welcome note that says how to ask for help, and a five-minute briefing that shows them. It includes a check-in on day three that asks the questions they will not. It also includes a short list of the tickets every starter raises, headed off before they are raised. It is the part of onboarding that happens after everything is "ready". It is where the desk earns the reputation the starter will carry for years. This article is part of our Employee Onboarding series. It follows on from The Day-One Checklist, which ends at the handover.

It covers why new starters do not raise tickets, and the welcome note from IT. Then come the five-minute briefing on how to ask for help, and the day-three check-in. Next come the common first-week tickets and how to head them off, as a table. It ends with the manager's part, closing the onboarding at the end of the week, a short war story, and the welcome message to copy, in that order.

Why New Starters Do Not Raise Tickets

A new starter's silence is not a sign that everything works. It is a sign that they have not yet learned they are allowed to say otherwise. Three things keep them quiet. They do not know how: nobody has told them the portal exists, the desk's address, or that walking up is fine. The one person they could ask is the manager they are trying to impress. They do not want to be the new person who complains in week one. "The printer doesn't work for me" sounds, to someone three days in, like an admission rather than a report. And they assume the problem is them, because everything else is new too. A shared folder that will not open is indistinguishable, to a newcomer, from a shared folder they have not been shown how to open.

The result is a week in which the starter's problems go to the colleague at the next desk, the manager, or nowhere. The colleague fixes what they can and the desk never hears about the rest. The manager, who has a job of their own, relays what they notice, on Wednesday, in passing. Nowhere is the commonest destination, and the problem waits there until it becomes a habit. A year later, the person prints from a colleague's machine, or keeps a file on a memory stick because the shared drive "never worked". A starter who raises no tickets in week one is the desk's quietest customer and quite often its most stranded.

The fix is to invite the tickets, in writing, in person and then again on day three. Make raising one feel like the normal thing a competent person does rather than a confession. The desk cannot make a starter confident. It can make asking easy, expected and quick, and most people take the easy route when it is shown to them.

The Welcome Note From IT

The welcome note is a short message, from a named person on the desk, that arrives in the starter's new mailbox. It is among the first things they read. It says five things: who the desk is, how to reach it, what to put in a ticket, the three things to do today, and what is still coming. It is sent on the morning of day one, or queued the day before as the last line of the ready test. For a home-based starter whose first sign-in happens on a call, it goes to the manager the day before to forward, and again to the new mailbox once it works.

Keep it under a screen. The starter has a manager, a team, an induction and a handbook all competing for the same morning. A message from IT that runs to three screens is a message that is skimmed. Who we are is a sentence. How to reach us is the portal link, the address and the phone number, with walk-up mentioned if the desk is on site. What to put in a ticket is three lines: what you were trying to do, what happened instead, and what you expected, with one problem per ticket. The three things to do today start with the password change. Next is the second-factor enrolment if it was not done at the handover. Last is opening the one system the role uses most, so that any problem with it is found on day one. What is still coming is the list of dated tasks from the parent ticket, so that a missing badge reads as "Tuesday" rather than "forgotten".

Write it like a person. A welcome note that reads like a policy document teaches the starter that the desk talks like a policy document. They will write to it the same way, or not at all. The desk's voice in general is the subject of Writing Like a Person, Not a Policy. The welcome note is the message where it matters most, because it is the first one. Sign it with a name. "The IT team" has never once replied to anybody.

The how-to-ask-for-help part is worth keeping in one place rather than in every note. If you run QuerySolv, a knowledge base article visible to everyone can hold the where, the what and the what-happens-next. In that case, the welcome note links it in a line. In any tool, a single page the note points to is easier to keep current than a paragraph copied into every message. The note itself is a template with four blanks, kept in the desk's library. The craft of writing one that does not sound canned is in Writing a Template That Does Not Sound Canned.

The Five-Minute Briefing

The briefing is the welcome note said aloud, at the handover, by the technician who hands over the device. It takes five minutes because that is all the starter has and all the subject needs. It covers five points in order. Here is where you ask: the portal on the screen, the address, the phone, and the desk's location if there is one. Here is what to put in it: what you were doing, what happened, what you expected, and one problem per ticket. That is the whole of ticket-writing and takes thirty seconds to say. Here is what happens next: you get an acknowledgement with a number, and a named person replies. You reply to that message to add anything or to say it is fixed. Here are the two things that are never a ticket. First is your password, which nobody on the desk will ever ask you for. Next is a colleague signing you in with their account, which is a kindness that gets both of you into trouble. And here is the one that matters: you are not a nuisance. We would rather hear about a small thing on Tuesday than a big one in a month. A ticket in your first week is normal.

The briefing is training. The rule for training users is that it works in small, timed pieces delivered at the moment of need and fails as a lecture. Training Users to Write Better Tickets Without Lecturing explains in full. The handover is the best moment of need the desk will ever get. The person is sitting at the device, has nothing else to do for five minutes, and has not yet formed a habit. Everything said then is remembered. Everything sent in a document a month later is not.

Show, do not describe. Open the portal on the starter's own screen and leave it open. Have them send the desk a one-line test ticket, "test from Kwame, please close", and let them see the acknowledgement arrive. The first ticket is the hardest one, and a test removes it. The reply they get back, from the technician beside them, is a sentence with a name on it. That sixty seconds does more for first-week ticket rates than any poster.

For a starter who is not on site, the briefing happens on the first sign-in call, with the portal shared on screen. It is the one part of remote onboarding that is better done live than in writing. The shipping, the remote first sign-in and the rest of the remote starter's week are in Remote Onboarding and Offboarding. The briefing is the same five points, delivered with the technician's face on the screen rather than beside the desk.

The Day-Three Check-In

The check-in is a short message, or a five-minute visit, on the starter's third day, from the technician who did the handover. It asks the questions the starter will not raise on their own. Day three is chosen because day one is too soon: the person has not tried anything yet. Day five is too late, because by then the workarounds have formed and the week is gone. By the third day a starter has tried to print, tried to find the shared folder, tried to join a meeting, and tried the phone. They have an opinion about each, which they have told nobody.

Ask specific questions, because "how is everything?" gets "fine" from every new starter in every organisation. Can you sign in everywhere you have tried? Can you print? Can you open the shared folders your team uses? Is anything noticeably slow? Is there anything you were told you would have that you do not? Has anyone had to sign you in or do something for you on their own account? There are five or six questions, yes or no, on a message they can answer in a minute. Or they are asked in person at their desk, where the answers are more honest and the printer is right there to try.

Record the answers on the parent ticket, and turn every gap into a task ticket with a date, linked to the parent. "Cannot see the mortgage team folder" is a task for today; "second screen not arrived" is a task with the date it is due. The starter gets a reply that says what was found and when each thing will be fixed. That reply is the moment the desk's reputation with this person is set. It is the moment they learn that reporting a problem produced a date rather than a shrug.

The check-in is also where the desk learns about its own checklist. A gap found on day three that the ready test should have caught is a defect. It is a thing missing on day one that the process was supposed to deliver. Defects are counted and fed back into the checklist and the profile cards. That is the mechanism Measuring and Improving Onboarding describes. The check-in is a quality check on the onboarding as much as a kindness to the starter. It is also, in my experience, the only reliable way to find out that the printer at the north end of the floor has not worked for anyone since spring.

The Common First-Week Tickets, and Heading Them Off

Most first-week tickets are the same eight or nine, on every desk, for every starter. Each has a head-off: something done at the ready test, in the briefing or in the welcome note that means the ticket is never raised. The table below is a fictional desk's list from a year of starters; yours will have the same shape with different printers. Heading them off does not mean the desk does more work. It means the work is done once, in the checklist, instead of once per starter, in the queue.

Read the table from right to left and it is a list of lines for the ready test and the profile card. That is the point. Every ticket a desk sees from three starters in a row is a line missing from the checklist. The cheapest place to fix a first-week ticket is in the list that every future starter's onboarding is built from. The desk at Bluewater added "print from the actual desk" to its ready test the week Kwame started. It has not had the printer ticket since.

Resist the urge to head off everything by writing more into the welcome note. A note that anticipates twenty problems is a note about twenty problems, and the starter reads it as a warning. Head off the common ones in the process. Mention the two or three that need a decision from the starter in the note, and let the check-in catch the rest. A short note and a good check-in beat a long note and no check-in by a distance.

The Manager's Part

The manager is the starter's first channel for everything, including IT. The desk's job is to make the manager a relay rather than a repair shop. Ask managers for three things, in the onboarding acknowledgement and again in the manager's own induction checklist if HR keeps one. Ask them to introduce the portal in the team's first conversation, and to forward rather than fix when the starter brings them an IT problem. Ask them to tell the desk on day three if they have noticed anything the starter has not raised. The manager at Bluewater did the third of those, two days late and in passing. It was still the thing that found the printer.

Forward rather than fix matters because a manager who fixes becomes a shadow desk for their team, which is one of the ways a desk loses a department without noticing. Managers fix out of kindness and speed, and each fix teaches the starter that the manager is where IT problems go. The habit is hard to break once it is set, and it is set in the first week. The ask is small: "If Kwame mentions anything, send it our way with his name on it, and we'll take it from there." Most managers are relieved to be asked.

For a remote starter the manager is also the only person who can see whether the starter is struggling, because the desk cannot walk past their desk. Ask the manager, specifically, to put IT on the agenda of their first one-to-one, with the day-three questions in front of them. Ask them to forward the answers. It is five minutes of the manager's time and it replaces the visit the desk cannot make.

Closing the Onboarding at the End of the Week

The parent ticket closes at the end of the first week, after the check-in, with a note. The note records what was ready on day one, what was found on day three, and what the defects were. Anything still outstanding, a screen on order, an exception waiting on an approver, stays open as its own task ticket with its own date. The parent is not held open for it. The starter gets a one-line closing message: the onboarding is complete, here is how to reach us from now on, and anything new is a new ticket. From week two the starter is an ordinary user with an ordinary route, which is the outcome the whole process was for.

The closing note is what the measurement reads. The measurement reads on-time or not, how many defects, what they were, and how many working days' notice the desk had. Those are four facts, written in the same place on every onboarding, which is what makes a quarter's worth of them countable. A closing note that says "done" records nothing. A closing note that says "ready on time; two defects: printer mapping, team list; notice eight working days" is a row in a scorecard. The habit of writing a resolution note that somebody can read later is the same one Resolution Notes Worth Reading Later teaches for every ticket. The onboarding is simply the ticket where the reader is the desk itself, next quarter.

Do not reopen the onboarding for a problem in week three. A starter whose laptop misbehaves on day fifteen has an ordinary incident. It goes in the ordinary queue with the ordinary priority, which is what the welcome note told them. The onboarding is a request with a start and an end, and the end is the week-one close. Onboardings that never close become the ticket where everything about a person is filed, and after a year nobody can find anything in them.

A Short War Story: The Head of Science at Thornfield Academy

Thornfield Academy, a secondary school with a two-person IT team, appointed a new head of science called Beatriz for the September term. Her onboarding went well by every measure the team kept: account, laptop, access to the school's systems and the science department's shared area. All were ready a day early and handed over on the training day before the pupils came back. For two and a half weeks Beatriz could not print to the science block's printer, because the printer had been mapped for the main building. During that time she could not open the exam archive either. The group that held it had been renamed over the summer and the profile card still had the old name. She told nobody, because the IT team "seemed very busy with the start of term". She printed two weeks of worksheets in the staff room and asked a colleague to pull the past papers from the archive for her. The deputy head found out when he asked why the science department's printing costs had moved to the staff-room printer. The IT team found out from him, on a Thursday, twelve school days in. The two fixes took fifteen minutes between them. The damage was two and a half weeks of a senior teacher's time spent working around, and a colleague's time spent fetching. It also left a department head whose first impression of the school's IT was that it was something you coped with. The team wrote the welcome note that evening and put a day-three check-in on the calendar for every starter after that. The next new teacher raised two tickets on her second day, both fixed before lunch. A starter who raises no tickets in the first week has not been well served; they have been left alone.

The Welcome Message

The template below is the welcome note, written to be read in under a minute by someone with eight other things to read that morning. It is sent from a named technician, not a shared address. The blanks are the starter's name, the technician's name, the two or three things still to come with their dates, and the link to the how-to-ask-for-help page. The section on what the desk does not own is deliberately short and names the person who does. That sends the starter's first non-IT question to the right place instead of to the desk. Keep the whole thing to one screen; if it grows past that, move the growth to the page it links.

WELCOME NOTE FROM IT — SENT ON THE MORNING OF DAY ONE

Subject: Welcome from IT — how to reach us, and three things to do today

Hello ______________,

Welcome to ______________. I'm ______________ on the IT desk, and I set up your
account and laptop. This note is everything you need from us in your first week.

HOW TO REACH US
  Portal: ______________________ — fastest; a ticket number comes back straight away
  E-mail: ______________________        Phone: ______________
  In person: ______________________ — interruptions are welcome
  How it works, and what to put in a ticket: ______________________ (one page)

WHAT TO PUT IN A TICKET
  What you were trying to do, what happened instead, and what you expected.
  One problem per ticket. Screenshots help. You will get a reply from a named person.

THREE THINGS TO DO TODAY
  1. Sign out and back in once more, so the new password sticks.
  2. Open ______________ (the system your team uses most) and tell us if anything is wrong.
  3. Check you can see the ______________ shared folder and print to ______________.

STILL TO COME — no need to chase these
  ______________________ — by __________
  ______________________ — by __________

TWO THINGS WE WILL NEVER ASK FOR
  Your password, and a colleague's login. If anyone asks for either, tell us.

NOT US, BUT HERE IS WHO
  ______________ (expenses, payroll): ______________     ______________ (badges, desks): ______________

I'll check in with you on ______________ (your third day) with a few quick questions.
Until then, anything at all, send it in. A ticket in your first week is completely normal.

______________
IT desk, ______________

Imogen wrote the Bluewater version that afternoon and sent it to Kwame late, with an apology that did not need to be long. Imogen fixed the printer in four minutes at his desk. The day-three check-in went on the handover checklist the same day. The next starter, in the following month, raised two tickets before ten on her first morning, one for a folder and one for a screen input. Both closed within the hour. Imogen, reading the queue, counted them as the first sign that the process worked. A starter who asks on day one has been told she may. That is the whole of first-week support, and it fits on one screen.

Frequently Asked Questions