Enrolment and Setup Without a Visit to the Desk

Thursday, 16:10, at Ashgrove Housing. Carla runs the desk at head office. On her desk is a box containing a company phone for Jonah. He starts on Monday at the housing office forty miles away. The courier collects at five. Nobody from the desk will see Jonah, or the phone, or the moment on Monday morning when he opens the box. Whatever Carla puts in it has to do the job that a technician standing beside him would have done. She has fifty minutes and a phone that has never been switched on. She also has a guide she wrote last spring on her own handset, which she now realises already had everything on it.

Enrolment is the process that introduces a phone to the organisation. The phone takes on the management profile that says who it belongs to. The user signs in with the work account. The second sign-in factor is registered on the phone. The work apps arrive and run. Setup without a visit means the user does all of that themselves, following a guide. The desk is at the end of a phone line rather than at their elbow. This article is part of our Mobile Device Support series. It describes the steps in plain words, with no product named. That is because the products change their screens every season and the steps have not changed in years.

It covers what enrolment actually does; the steps in plain words; why a visit is the wrong default. Next come the self-service guide, the work account on the device, and the second factor, set up at the same time. Then come the starter's first-day kit and the user who cannot follow the guide. A short war story and the setup guide outline to copy follow, in that order.

What Enrolment Actually Does

Underneath every platform's own vocabulary, enrolment is four things happening in order. First, the phone is told which organisation it belongs to, by taking on a management profile. This is a small piece of configuration that links the phone to the organisation's management service. It lets that service set rules, deliver apps, and lock or wipe what the organisation owns. Second, the user signs in with the work account, the identity the organisation knows them by. This is the same sign-in they will use on the laptop. Third, a second factor is registered on the phone, so that signing in from then on needs the password and the phone together. Fourth, the work apps arrive, usually by themselves, and run because the first three things are in place.

Enrolment comes in two shapes, and the desk needs to know which it is before the box is packed. A company phone is enrolled whole: the management profile covers the entire device and the organisation can do anything to it. A personal phone gets a work profile, a separate managed compartment that holds the work apps and their data. The organisation can empty that compartment without touching the rest of the phone. The four steps are the same in both shapes; the footprint is smaller in the second. What the organisation can and cannot see inside that compartment is the subject of BYOD Boundaries in Practice. The user setting up a personal phone will ask, so the guide should say.

Enrolment is not the same as installing the mail app. A phone with the mail app and no management profile is a phone carrying an unmanaged copy of the organisation's mail. The organisation cannot lock it, cannot wipe it and cannot see it. The day that matters is the day the phone is left in a taxi. The whole of Lost and Stolen Devices assumes the profile is there. A user who skipped the profile and "just added the mail" has produced something that works on Monday and fails on the one day it is needed. That is a sentence that describes most shortcuts.

The Steps in Plain Words

The table below is the sequence as the user experiences it, with what tends to go wrong at each step. It also shows what the desk can check from its own screen without seeing the phone. The wording is deliberately generic: "the prompt that mentions the organisation" rather than any button's name. That is because the button will be renamed and the prompt will still mention the organisation. Steps are numbered because the guide numbers them, and because a user on the phone saying "I'm on step five" is worth three minutes of description.

Three checks from the desk's side confirm an enrolment without a single question to the user. Do them in the order the table gives them. The device is enrolled, the account signed in from it, and the second factor is registered on it. Each of those is visible in a management service, a directory or an identity service that the organisation already runs. And the desk should know where each one is before the first box is shipped. If any of the three is missing, the desk knows which step failed before the user has noticed. That is the whole trick of setup without a visit: the desk cannot see the phone, so it checks the three places that can.

Why a Visit Is the Wrong Default

A visit is the way most desks start, and it feels like care. The technician sets the phone up by hand. The user watches. Everyone is reassured. It is the wrong default for three reasons. It does not scale, because the starters are at the housing office forty miles away, or at home, or in another country, and the desk is not. It teaches the user nothing, because a technician's hands make the steps invisible. The user who watched the setup is no better placed to repeat it on their next phone. And it teaches the desk nothing, because a technician who can do it from memory never finds out which step a stranger gets stuck on. A technician who sets up every phone by hand becomes very good at setting up phones and very hard to replace, which is a compliment with a long tail.

The arithmetic on a fictional desk makes the case. Say forty starters a year, and a hand setup of forty-five minutes each including the walk to the right building. That is thirty hours of desk time, none of it recorded as anything but "helping". With a guide, the user spends twenty minutes on their first morning and the desk spends five minutes on the three checks. So the same forty starters cost the desk three to four hours a year, plus the two hours it took to write and test the guide. The user's twenty minutes is also their first encounter with the organisation's systems, done at their own pace, with the guide beside them. That is better preparation for the next year than watching someone else's thumbs. Keep the visit for the user who genuinely cannot follow the guide, which this article comes to below. Do not keep it for everyone because it is pleasant.

The Self-Service Guide

The guide is written for a person on their first morning who has nothing: no mail, no colleague at the next desk, no idea what the organisation means by its own words. So the first thing the guide does is define those words in a line each. "Your work account is the sign-in you will use for everything here; it looks like an e-mail address." "The authenticator is an app that proves it is you by producing a code." "The management profile is how the phone knows it belongs to Ashgrove, and it is what lets us help you if the phone is lost." Three sentences at the top remove half the calls, because half the calls are a user who did every step correctly and could not tell.

Then give one action per step, numbered, in the order the table above gives them. Say what the screen will say and what success looks like at the end of each. The craft of that is the subject of One Action per Step. This article does not repeat it, except to say that a phone guide has one extra discipline. Describe what the screen says rather than where the button is. That is because phone screens change shape with every platform update and a screenshot of a button is out of date within a season. The thinking behind pictures that age and how to keep them honest is in Keeping Media Current. For a phone guide, fewer pictures and more "you will see a prompt that mentions Ashgrove" is the safer bet.

The guide is tested on a phone that has never met the organisation, by a person who has never met the guide. The author is in the room and silent. This is the single step that separates guides that work from guides that were written. A technician's own phone already has the profile, the account and the apps. And a guide written from it will skip the step the author no longer sees. The guide lives in the knowledge base on a page visible to everyone rather than to agents only. A paper copy goes in the box, because the starter may not be able to reach the knowledge base until step seven is done. The paper copy is one card. The card carries the steps, the link, the ticket number and the desk's number. It is the thing the user holds while the phone is in their other hand.

The Work Account on the Device

The starter password is never in the box. It travels by a different route from the phone, because a box that holds both is a box that signs in on its own if it goes missing in the post. One usual route is the starter's manager handing it over in person or by phone on the first morning. Another is the organisation's own starter-password process. Use whichever the onboarding checklist already uses. The conventions for conveying a temporary password without writing it anywhere it will last are in The Reset Itself, Done Properly. And they apply to a starter as much as to a reset. The guide says where the password will come from and says, in plain words, that it is temporary and that step four will ask for a new one.

Signing in on a phone looks different from signing in on a laptop, and the guide should say so. The organisation's sign-in page appears inside the management app or inside the mail app rather than in a browser the user chose. It may appear more than once as each app learns who the user is. The user types the work e-mail address, then the password, then may be asked whether to stay signed in. And the guide's answer to that question is whatever the organisation decided, stated plainly. On a personal phone, the sign-in is followed by the phone asking whether the organisation may create a work profile. The guide explains in two sentences what that is and what it is not. A user who is not told will say no. The no is hard to undo without starting again.

The failure at this step is almost always on the desk's side and almost always visible before shipping. The account was created but not enabled. The account is enabled but its start date in the directory is Monday and the user opened the box on Monday at eight. The account is fine but was never allowed mobile access by whatever rule the organisation uses for that. Check all three on the Thursday, from the desk's own screens, and the sign-in step on Monday becomes the boring one. The guide cannot fix a disabled account. It can only tell the user to call, and by then the courier has been paid.

The Second Factor, Set Up at the Same Time

The second factor is registered during setup, in the same sitting, before the user reads a single e-mail. And the guide does not offer it as a later step. A phone with the work account and no second factor will produce a ticket. That happens the first time the mail service, the VPN or the organisation's single sign-on asks for a code. It is usually the second day, when the user has forgotten that the guide mentioned it. Registering the second factor at setup also means the desk's third check can be done on the Monday with the other two. That check confirms the second factor shows this phone. It can be done then rather than chased on the Wednesday.

The guide walks the user through installing the authenticator app and linking it to the account. Then it does the one thing most guides leave out. It tells them to save the backup codes somewhere that is not the phone, and says why in one sentence. "If this phone is lost, these codes are how you get back in without it." A user who understands that sentence stores the codes. A user who was told "save these" in bold with no reason puts them in the phone's own notes. That is the one place they are useless. The whole subject of the second factor on a new phone, a lost phone and a refused code belongs to Second-Factor Problems, including the re-enrolment runbook. This article adds only the timing: do it at setup, every time.

The new starter has an identity problem the desk should see coming. Nobody at the desk knows Jonah's voice. His manager has met him twice. On Monday morning he may ring to say the code is not arriving. The standard for confirming that a caller is who they say they are is in Verifying Identity Before You Reset Anything. For a starter the usual answer is that the manager vouches, by a route the desk initiates rather than one the caller suggests. Write that route into the onboarding ticket before the start date. The starter who cannot be verified is not a problem to solve at nine on Monday with a queue behind them.

The Starter's First-Day Kit

The phone is one item in a kit the onboarding process already owns, and this article only says what the phone part of the kit holds. The box contains the phone, the SIM already in it and activated or the carrier's activation route on the card, and the charger. It also contains one printed card with the eight steps, the link to the guide, the ticket number for the onboarding, and the desk's number. The card includes the sentence "if you are stuck for more than ten minutes, ring us; it is not you." The box does not contain the password, for the reason above. And the box does not contain a sheet of policies, which the starter will read later or never. The whole kit, by role, is the subject of Role Profiles and Standard Kits. And the order things must be ready in is The Day-One Checklist. The phone is one line on each.

The phone's line on the onboarding checklist is more than "phone shipped". It is "SIM activated, account enabled for mobile, welcome message and first-day meeting sent so step seven has something to show, card printed, box collected", with a date against each. And it is done by the Thursday so that nothing is being discovered on the Monday. If you run QuerySolv, the onboarding request from its own form becomes a ticket with linked tickets for each task. In that case, the phone's linked ticket is where those lines live. So the person running the onboarding sees "phone: ready" without opening the box. In any tool, the test is whether someone other than Carla could tell on Friday that the phone was ready. On the desk that fails that test, Carla is the checklist.

The courier is part of the setup. A box that arrives on Tuesday has produced a starter with no phone on Monday, which is a worse outcome than a starter with a phone and no guide. The practicalities of shipping, tracking and the swap when the box is wrong belong to Shipping and Swapping Hardware. The mobile article borrows one rule from it: ship to arrive the working day before, and put the tracking reference on the ticket. Phones are small, and small boxes are the ones that sit in a sorting office.

The User Who Cannot Follow the Guide

Some users will not get through the guide. And the first thing to say is that this is usually the guide's fault, or the phone's, and rarely the user's. The three causes, in order of likelihood, follow. First, the guide is wrong, because it was written on a phone that already had everything on it. Second, the phone is not in the state the guide assumes. It is not factory fresh, already has a personal account on it, or is waiting for a platform update that is blocking everything behind it. Third, the user is anxious on their first morning and reading faster than the phone is moving. Each has a different fix, and the call is for finding out which.

The call runs on the user's eyes, because the desk has none. Ask them to read the screen aloud, word for word, including the small print, and ask what the last thing they tapped was. Do not ask them to tap a button by name, because the name on the technician's phone may not be the name on theirs. Say "the option that mentions Ashgrove" or "the choice that says something about work". If they have a second device to hand, a laptop or a family member's phone, a photograph of the screen sent to the ticket is worth five minutes of reading aloud. Describe, never drive. The technician who starts guessing at labels is the one who sends the user round in a circle. And the circle is the thing the user remembers.

Set a limit in advance for when the call stops and the alternative starts: two calls, or thirty minutes, whichever comes first, on a fictional desk. The alternative is not a visit forty miles away. It is a phone the desk has already enrolled, with the management profile on it and the sign-in left for the user. That phone is shipped the same day, with the stuck phone coming back in the same box. Where the user is in the building, the visit is fine, and short. Either way, the failure is a note on the guide: which step, what the screen said, what the fix was. A guide that has been through ten failed calls and ten edits is a guide that works. A guide that has never failed has never been read.

A Short War Story: The Missing Step at Redbrook Engineering

At Redbrook Engineering, a technician called Owen wrote the phone setup guide on his own handset in an afternoon. Because his handset already carried the management profile, the guide went from "switch on the phone" straight to "sign in with your work account" with nothing in between. Twelve starters followed it over the next quarter. Nine of them rang the desk. Each call ran about forty minutes. Three of the nine spent their first week with mail on a laptop and nothing on the phone. That was because the mail app would not run without the profile the guide never mentioned. The desk lost about six hours to the calls and a good deal more to the reputation of "the phone thing never works". The fix, when it came, took one hour. It involved a spare phone wiped to factory settings and a colleague from accounts who had never seen the guide following it aloud. Owen sat beside her with his hands in his lap. She stopped at step two and asked what a management profile was. And the guide has had a second step and a definition at the top ever since. Test the guide on a phone that has never met the organisation, with a person who has never met the guide.

The Setup Guide Outline

The outline below is the skeleton of the guide the user holds. Fill in the organisation's own words where the blanks are. Keep each step to one action and one "you will see". Resist adding a step that is not needed for the phone to work on day one. Section A is the definitions; B is the eight steps. C is the two things that go wrong most and what to do. D is how to tell the desk it is done, which is the step everyone forgets. The outline is the same for a company phone and a personal one. The personal version adds the two sentences about the work profile at step three.

PHONE SETUP GUIDE — OUTLINE
Organisation: ______________________   Guide owner: ______________   Last tested on a fresh phone: ________

A. THREE WORDS YOU WILL SEE
   Your work account: the sign-in you use for everything here; it looks like ____________@__________
   The authenticator: an app that proves it is you by producing a code
   The management profile / work profile: how the phone knows it belongs to ______________,
   and what lets us help you if the phone is lost. On a personal phone it covers only the work part.

B. THE STEPS — one action each, with what the screen shows after it
   1. Switch on, choose a language, connect to wireless or let the SIM connect.
      You will see: ______________________
   2. When the phone asks who it belongs to, or when you install the ______________ app,
      accept the management profile. You will see a prompt that mentions ______________.
   3. Sign in with your work account. Your starter password comes from ______________, not from this box.
      Personal phone: the phone will ask to create a work profile; say yes. It is a separate
      compartment for work apps and we cannot see outside it.
   4. When asked, set a password of your own. The rules are: ______________________
   5. Install the authenticator app and link it to your account when prompted.
      Save the backup codes somewhere that is not this phone: ______________________
      If the phone is lost, the codes are how you get back in without it.
   6. Wait. The work apps arrive on their own; allow up to ______ minutes before worrying.
   7. Open mail; you will see a welcome message. Open the calendar; you will see ______________.
   8. Reply to the welcome message with "done". That tells us it worked.

C. IF SOMETHING GOES WRONG
   Stuck for more than ten minutes: ring ______________ and read the screen aloud to us. It is not you.
   The phone says it already belongs to someone: stop; ring us; do not reset it.

D. WHAT WE CHECK FROM OUR SIDE — nothing for you to do
   The phone is enrolled; your account signed in from it; the authenticator is registered on it.
   Ticket number for this setup: ______________

Carla rewrote the second step and the definitions at the top in the fifty minutes she had. She printed the card and put the phone and the charger in the box without the password. She sent the welcome message and a ten o'clock meeting to Jonah's calendar so that step seven would show him something. On Monday at 09:20 a reply arrived on the onboarding ticket that said "done, I can see the ten o'clock". Carla opened three screens and saw the device, the sign-in and the authenticator. She closed the phone's linked ticket without having spoken to him. He rang on Wednesday about something else entirely. She was quietly pleased that it was something else.

Frequently Asked Questions