Onboarding as a Ticket Type, Not a Surprise

Monday, 08:50, at Tollgate Foods, a wholesaler with two depots and a head office. Dana runs a desk of three and has just sat down with the first coffee when reception rings. "I've got a Marcus here, starting in purchasing. He says his laptop is with you?" Dana has never heard of Marcus. Nobody on the desk has. A quick search finds no ticket, no e-mail, and no account. HR, when reached at 09:05, has an offer letter dated five weeks ago. The purchasing manager, when reached at 09:20, says "I assumed HR told you," which is the sentence every surprise onboarding ends with. Marcus spends the morning in reception reading the staff handbook on his phone. Dana spends it building a laptop from scratch while the queue waits.

Onboarding, in the desk's sense of the word, is everything that has to exist before a new person can do the job they were hired for on the first morning. That includes an account, a mailbox, a device, the right access, a phone if the role needs one, and the smaller things like a badge and a desk. Treating it as a ticket type means giving it what every other kind of work on the desk already has. That means a trigger that opens it, a form that captures it, a named owner, a target date, a set of tasks, and a definition of done. This article is part of our Employee Onboarding series. It is about the first move: turning the surprise into a request that arrives on time with the right information in it.

It covers why onboarding arrives as a surprise and why it is a request and not an incident. Next come the trigger moment, who raises it and who owns it, and what the request must contain and why each field earns its place. Then come the parent ticket and its task tickets, with a table of who owns what, and the first hour after the request lands. It ends with a short war story and the onboarding request form to copy, in that order.

Why Onboarding Arrives as a Surprise

The desk is the last to know because, in everyone else's picture of a hire, the desk is the last to need to know. HR's process runs from the vacancy to the signed contract and ends there, with the new person filed as a solved problem. The hiring manager's process runs from the interview to the first morning and is mostly about the work the person will do. The desk's process runs from the first morning to the first morning, which is to say it has no process at all until the surprise defines one. Nobody is at fault. Nobody owns the telling, and a thing nobody owns does not happen.

The information was never missing; it was in the wrong place. Marcus's start date existed in writing for five weeks, in the offer letter, in HR's filing, in the manager's calendar and in Marcus's own diary. The only place it did not exist was the one place that needed to act on it. Surprise onboarding is not an information problem. It is a routing problem, and routing problems have routing fixes.

The news reaches the desk three ways, in descending order of dignity. It comes from the manager the afternoon before ("just a quick one, I've got someone starting tomorrow"), or from reception on the morning. Or it comes from the new starter, who asks politely whether there is a computer they should be using. New starters do not appear on the desk's calendar. They appear at reception.

The cost is paid twice. The desk pays it in a morning of unplanned work that pushes every other ticket back. It pays in a device built in a hurry with the mistakes that hurry produces. It also pays in a loan laptop that goes out with someone else's wallpaper on it. The new person pays it in a first day that teaches them, before they have met their team, that things here do not work. First impressions of an organisation are formed in about a morning, and the desk is usually the first department a new starter interacts with. That is a lot of reputation to hand to whoever is on the rota.

Onboarding Is a Request, Not an Incident

A desk handles two broad kinds of work, and the surprise forces onboarding into the wrong one. An incident is something that was working and has stopped: a printer, a login, a mailbox. It arrives without warning, it is urgent in proportion to what it stops, and the desk's job is to restore service fast. A request is planned work that somebody wants done by a date: a new account, a software install, a desk move. It is known in advance and has a deadline rather than an urgency. The desk's job is to deliver it on time with the right information. The four kinds of work and how they differ are laid out in The Four Work Types in Plain Words. Here the point is simply that onboarding is a request by nature and an incident only by neglect.

When onboarding arrives on the morning, it behaves like an incident. The desk responds like it would to an outage: drop everything, improvise, restore the person to a working state. That is the correct response to a surprise and the wrong way to run a process. A request has the properties an incident never has. It has a trigger, the moment at which it is known to be coming. It has a form, so the information arrives complete. It has an owner, a target date, a list of tasks for the people who do them, and a definition of done. Giving onboarding those six things is the whole of this article.

Requests also carry an approval, in most organisations, and onboarding is the one request where the approval has already happened. The offer was signed. The budget exists. The manager wants the person. No part of the onboarding needs anyone's permission except the access. The access can be agreed in advance for the role, which is the subject of Role Profiles and Standard Kits. The result is that onboarding, done as a request, is one of the few ticket types a desk can deliver almost entirely from a plan.

The Trigger Moment: Offer Accepted

The trigger is the event that opens the ticket. For onboarding the right trigger is the accepted offer: the moment the candidate says yes and a start date is agreed. Not the signed contract, which may follow by weeks. Not the start date minus a week, which is a reminder rather than a trigger. Not the manager remembering. The accepted offer is the earliest moment at which the three facts the desk needs, that a person is coming, who they will be, and when, are all known with reasonable certainty.

Reasonable certainty is the right standard, and "but what if they fall through?" is the objection that follows. Some do. A candidate accepts, then takes another offer, and the desk has opened a ticket for someone who never arrives. The cost of that is small: an account that is never enabled, a kit that goes back on the shelf, a ticket closed with a note. An hour, perhaps, spread over a fortnight. The cost of the opposite mistake, waiting until the person is certain, is the Monday morning at Tollgate Foods. When one error costs an hour and the other costs a day, choose the one that costs an hour, every time.

The trigger has smaller cousins that deserve the same treatment. An internal transfer is an onboarding with an existing account and a different access bundle. A contractor start is an onboarding with an end date and a narrower kit. A return from long leave is an onboarding in which the account exists but may have been disabled. The device is a year out of date, and the person's role may have changed. Each of these can use the same form and the same parent ticket, with a field that says which kind it is. They are the same shape of work, and the desk that treats them as the same shape stops being surprised by any of them.

Getting the trigger to fire reliably means getting HR to fire it. The agreement that makes that happen, with the ten-working-day ask and what to do when you get two days, has its own article in this series, Lead Time: Getting the Request Before the Start Date. This article assumes the trigger exists and deals with what it opens.

Who Raises It, and Who Owns It

HR raises the request, the hiring manager supplies the detail, and the desk owns the ticket. Three roles, and getting any of them wrong produces a familiar failure. HR is the raiser because HR sees every hire. A manager hires once or twice a year and forgets the form between hires. HR processes every offer in the organisation and can make raising the ticket a line in a procedure they already follow. The raiser needs to be the person for whom a new starter is routine, and in most organisations that is HR.

The hiring manager supplies the detail HR does not have: what the person will do, which systems they need, whether they travel, who they report to, and anything unusual about the role. The cleanest arrangement is for HR to raise the request with the facts of the hire. Then the manager is asked, on the same ticket, for the role detail. The worst arrangement is for the manager to be the only raiser, because the manager is the person least likely to remember and most likely to assume somebody else did it. (Somebody else did not.)

The desk owns the ticket because the desk does the work, and ownership means one named technician, not a queue. A request that sits in a shared mailbox or an unowned queue is a request everybody has seen and nobody has started. Claim it on the day it arrives and put a name on it. Let that name be the person who answers "where are we with Marcus?" for the next two weeks. Claiming a ticket, which most help desk tools support in one form or another, exists for exactly this kind of work. It makes one person responsible, visible to everyone, until the job is done or handed on with a note.

Ownership of the parent is not the same as doing every task. The technician who owns the onboarding coordinates it, chases the tasks that belong to other teams, and signs off that the person is ready. The task tickets below the parent each have their own owner, and that is the next section.

What the Request Must Contain

A request that arrives without a start date is not a request; it is a rumour with a form attached. The fields below are the ones the desk cannot work without. Each has a reason that can be given to HR in one sentence when they ask why the form is so long. (It is not long. It is seven fields and a comments box.)

The full name as it should appear is first, because the account name, the e-mail address and the display name in the directory are all built from it. A name entered as a nickname or with a typo is an account rebuilt on day two. The start date is second, because it sets every other date by counting backwards, and without it nothing can be scheduled. The role and the department are third, because together they pick the role profile, the standard bundle of kit and access that most starters fit. That choice drives the device, the software and the permissions. The manager is fourth, because the manager approves anything outside the profile, answers questions about the role, and is the person the desk hands the ready device to.

The location is fifth. A person starting in the Eastfield depot needs a kit delivered there. A person starting at head office needs a desk. A person starting at home needs the kit shipped a week earlier, which is covered in Remote Onboarding and Offboarding. The type of start is sixth: new hire, internal transfer, contractor with an end date, or return from leave, because each changes which tasks apply. The profile itself is seventh, chosen from a short list, with the manager asked to confirm it. Everything non-standard goes in the comments box, where the desk reads it and turns it into a task.

Two fields are tempting and should be left out. The personal e-mail address and the personal phone number of the starter are HR's data, not the desk's. The desk does not need them until the welcome message, which goes through the manager anyway. The starter's date of birth, home address and anything else from the HR file stay in the HR file. The onboarding ticket will be read by every team with a task on it, and the less personal information it carries the better. The ticket's job is to describe a role arriving on a date, not a person.

The form that captures these fields is an ordinary request form. The craft of building one that people complete is in A Request Form People Will Finish. The desk-side convenience worth having is a form of its own for this request, with these fields and nothing else. The aim is for an onboarding never to arrive as a free-text e-mail with half the facts. If you run QuerySolv, a department can have its own web form and mailbox. In that setup, an onboarding form with these seven fields lands in the desk's queue as a ticket with the fields already filled. That is most of the triage done before anyone opens it. In any tool, the test is whether the request arrives complete more often than not.

The Parent Ticket and Its Task Tickets

One onboarding is one person and eight or so pieces of work done by four or five different teams. The structure that fits is a parent ticket for the person with a task ticket linked to it for each piece of work. The parent carries the facts from the form, the start date, the owner and the overall status. Each task carries one job, one owner and one due date. The jobs are to create the account, build the device, grant the access bundle, and set up the phone. They also include issuing the badge, allocating the desk, entering the starter into the payroll and HR systems, and booking the induction. The parent is ready when every task is done.

The two alternatives both fail, in opposite directions. One ticket with a checklist in it fails because the tasks belong to different people with different due dates. A checklist inside a ticket owned by the desk is invisible to facilities and telecoms, who will not look in it. Eight unrelated tickets fail because nobody can see the whole person. The account is done, the laptop is done, and nobody notices that the badge task was never raised until Marcus is standing at the turnstile. The parent-and-tasks shape is the only one in which both questions, "what is left for this person?" and "what is facilities waiting on?", have a one-glance answer.

Most help desk tools can link tickets to each other, and QuerySolv links them in the ordinary way. So the parent shows its tasks and each task shows its parent. Where a tool cannot link, the parent's number in the subject line of every task does the same job less elegantly. The point is not the feature. The point is that whoever opens the parent two weeks later can see, without searching, which five tasks are closed and which one is still waiting on the telecoms team. That visibility is what turns "where are we with Marcus?" from a ten-minute investigation into a glance.

The table below is a typical task set with its owners and due dates counted back from the start date. The order is not arbitrary. The account must exist before the mailbox. The role must be known before the access. The profile must be chosen before the kit is built. Those dependencies, and the sign-off at the end, are the subject of The Day-One Checklist, which owns the full list. This table is the shape, not the detail.

Not every task is the desk's, and that is the point of the structure. The desk owns the parent and the tasks that are its own. Facilities, telecoms and HR own theirs. The parent's owner chases what is late. A desk that tries to own every task becomes the department that does facilities' job with worse tools. A desk that owns none of them becomes the department that is surprised.

The First Hour After the Request Lands

The onboarding request gets the same first-touch discipline as any other ticket, and the first job is to check that it is complete. Read the seven fields. If one is missing, go back to HR the same day with a one-line question, not a form rejection: "Thanks for this; which site will Marcus be based at?" A request bounced for incompleteness a week later has lost a week. The desk will be blamed for the delay it caused by waiting. The general habit of asking once, early and completely is in Gathering the Right Information Up Front. Onboarding is the request where the habit pays most, because every missing fact is a task that cannot start.

The second job is to confirm the profile with the manager. HR has picked "office worker" from the list; the manager knows that the role also needs the purchasing system and a second screen. One message to the manager, on the ticket, with the profile named and the question "anything this role needs beyond the standard?", gets the exceptions in writing before the kit is built rather than on day two. Exceptions that need approval beyond the manager go through the same path as any other access request, which The Access Request, Done Properly describes. The onboarding ticket raises them; it does not decide them.

The third job is to set the dates and create the tasks. Count back from the start date. Create each task ticket with its owner and due date, and link it to the parent. Send the ones that belong to other teams on their way with the parent number in the subject. Then acknowledge the request to HR and the manager with the parent ticket's number and the date by which the person will be ready. Include the one or two things the desk is waiting on from them. That message is the last time anyone should need to ask the desk what is happening, because from then on the parent ticket says.

Where the request arrives with two days' notice rather than ten, the first hour is the same and the dates are different. In that case, the tasks that take days get the honest answer "not by Monday", and the plan becomes the partial day one that the lead-time article describes. The structure does not change when the notice is short. It just produces a shorter list of things that will be true on the morning.

I will admit that I ran a desk for about a year in which the first hour did not exist, because the request did not exist, and every onboarding started at reception. The parent ticket felt like paperwork when I first set it up. It stopped feeling like paperwork the first time a manager asked where we were with a starter and I answered from the screen in four seconds.

A Short War Story: The Monday Three at Redbrook Engineering

Redbrook Engineering, a design consultancy with about ninety staff, hired three graduate engineers to start on the same Monday in September. Its single technician, Tom, learned of all three at 08:40 that morning from the office manager. The office manager had assumed HR would tell him, while HR had assumed the department head would. Tom had two spare laptops, one of which had come back from a leaver the previous week and still held that leaver's files. He spent the whole of Monday and most of Tuesday building accounts, finding a third machine, and granting access to the drawing system by guesswork. That was because nobody had told him which projects the graduates were on. The three graduates sat in a meeting room for a day and a half with a printout of the staff handbook. The queue grew by twenty tickets that nobody touched. One of the laptops went out before the leaver's files had been cleared, which took a further afternoon to put right. The department head's view, expressed to the managing director, was that IT had let the graduates down. Tom's reply was that nobody had told IT the graduates existed, which was true and did not help. The onboarding form was written that Thursday. HR agreed to raise it for every accepted offer. The next intake, in January, was ready a day early. A hire is known weeks before the start date to everyone except the people who have to build the desk. The fix is a form, not a faster technician.

The Onboarding Request Form

The template below is the form HR fills in when an offer is accepted. It is deliberately short: seven fields the desk cannot work without, and a comments box for everything else. It also has a section the desk completes on receipt so that HR can see the request has been acted on. Put it on the portal as the onboarding request and give HR the link. Ask them to raise it for every accepted offer, transfer, contractor start and return from leave. The desk-only section at the bottom is filled in during the first hour and copied into the parent ticket. It is the record that the request was checked, the profile was confirmed, and the tasks were created on a date.

ONBOARDING REQUEST — ONE PAGE
Raised by: ______________ (HR)   Date raised: __________   Ticket: __________

1. THE PERSON AND THE DATE
   Full name, as it should appear on the account: ________________________
   Start date: __________   Working days' notice from today: ____
   Type of start:  [ ] new hire   [ ] internal transfer   [ ] contractor, end date: __________
                   [ ] return from leave   [ ] other: ______________

2. THE ROLE
   Job title: ______________________   Department: ______________________
   Reports to (manager): ______________________
   Location:  [ ] head office   [ ] site: ______________   [ ] home-based, address held by HR
   Role profile (pick one): [ ] office  [ ] field  [ ] finance  [ ] warehouse  [ ] manager
                            [ ] other: ______________
   Phone or extension needed: [ ] yes  [ ] no

3. ANYTHING OUTSIDE THE STANDARD PROFILE
   ______________________________________________________________________
   ______________________________________________________________________

4. DESK USE ONLY (completed on receipt)
   Received on: __________   Owner: ______________   Complete on arrival: [ ] yes  [ ] no
   Missing fields requested from HR on: __________
   Profile confirmed with manager on: __________   Exceptions raised as access requests: __________
   Task tickets created on: __________   Ready-by date given to HR and manager: __________

Dana wrote the Tollgate Foods version of this form on the Monday afternoon, once Marcus had a laptop and an account and was, by three o'clock, mostly working. HR took it without argument, because the form took them two minutes and the alternative had taken Dana a morning. The next onboarding request arrived eleven working days before the start date, with every field filled. The desk built the kit on a quiet Thursday. Nobody rang from reception. It was, by every measure the desk kept, an uneventful Monday, which is the only kind of Monday an onboarding should ever produce.

Frequently Asked Questions