Personal Devices: What You Will and Will Not Touch

The laptop on Dana's desk has a crack running from the top corner of the screen to the middle of a spreadsheet. The spreadsheet is this quarter's forecast. The laptop is Dana's own, bought for an evening course. It has been doing the forecast since the company one went back for a keyboard that never came. It is 08:50, the forecast is due at noon, and Dana is looking at you, hopefully. "Can you do anything with this?"

You can, and you should, and there is a limit. The whole difficulty is that nobody has said what the limit is. This article is part of our What IT Supports series. It is about the limit: the two questions every personal-device request comes down to (what we will configure, and what we will not touch). It covers what best-effort means when the thing on the desk belongs to the person sitting at it. Then it covers the security floor a personal device has to meet before it carries work data. Next come the one-page policy that makes all of this boring, the conversations for when it goes wrong, the executive exception, and a policy template to copy. BYOD, bring your own device, is the practice of staff using their personal phones and laptops for work. Most small organizations have it, whether or not they have decided to.

One thing this article is not is a security policy. The minimum is here, as a shape; the detail belongs to the security topics in a later group of this library. This is about support, which is to say about what you do when Dana asks.

The Two Questions

Every personal-device request reduces to two questions: what will IT configure, and what will IT not touch. Answer them once, in writing, and most requests answer themselves. Leave them unanswered and each request is a negotiation held at a desk, with a deadline, in front of other people.

What IT will configure is usually two things: work e-mail and the remote-access client. Those are the two pieces of the organization's own services that have to live on the device for it to be useful for work. They are the two pieces IT knows how to set up on anything. Add a third if your organization has one, such as the sign-in app for multi-factor authentication. The list should be short enough to say in one breath. The whole of it is "we will connect you to our things".

What IT will not touch is the device itself. That includes its operating system, its updates, its storage, its battery, its screen, and its other applications. It also includes the account the owner signed in with when they bought it. Not because those things are beneath the desk, but because the desk cannot own them. A technician who updates a personal laptop's operating system owns the next thing that breaks on it, in the owner's mind, forever. The line is "the device is yours; our services on it are ours".

The two answers belong in the catalog as one entry. The entry belongs next to the one for company devices so that the contrast is visible. The catalog is the subject of The Service Catalog Idea, Without the Platform. The personal-device entry is the one most catalogs are missing, and the one that would have saved the most arguments.

Best-Effort, Defined for Devices

Best-effort for a personal device means three promises and three refusals, and it is only honest if you say all six. The promises: we will try, for fifteen minutes. We will tell you what we found. We will point you at who can help if we cannot. The refusals: we will not take the device apart. We will not install or remove anything that is not ours. We will not be responsible for the device afterwards. The general idea of best-effort, and why it needs a ring of its own between "we do" and "we do not", is in Scope Boundaries and the Gray Areas. Devices are where it gets personal, in the literal sense.

Fifteen minutes is the number because it is long enough to fix the common things and short enough to stop before the uncommon ones. Mail that will not sync, a remote-access client that will not sign in, a certificate warning: fifteen minutes covers them. Take a phone that cannot update, a laptop with a failing disk, a screen with a crack through the forecast. Fifteen minutes finds out that the problem is the device, which is the whole answer. The answer is "this one is the maker's, or a repair shop's".

Here is what fifteen minutes looks like. At 14:05 on a Wednesday, Marcus, a shift supervisor at Northgate Retail, brings his own phone to the desk. Work e-mail stopped arriving two days ago. Sam says the sentence first: "I can give this fifteen minutes; if it is the phone itself, I will tell you who to talk to." Sam logs ticket 7318, checks the account on the server (fine), and re-enters the mail settings (no change). At 14:14 Sam finds that the phone has been declining its operating system update for forty days. The mail app now requires the newer release. At 14:18 Sam writes the ticket note: "Mail requires current OS; phone has not updated; owner to update at home tonight, then mail should resume. Not a desk issue." Marcus updates that evening, and mail returns. Thirteen minutes, one note, no argument, and the desk never touched the update button.

Say the fifteen-minute sentence before you touch the device, not after. Said first, it is the terms of the help. Said after, it is an excuse, and it sounds like one. I learned this the way most things in support are learned. I did it the wrong way around in front of someone with a deadline.

The "not responsible afterwards" refusal is the one people forget to say and the one that matters most. If a personal laptop fails the week after IT touched it, the owner will connect the two. That is a reasonable thing for a person to do. Saying it out loud at the start ("anything I change here is the mail settings; the laptop itself is as it was") is not unfriendly. It is what lets you help at all. If you are the whole IT department, the limit is also what protects the rest of your day. The One-Person IT Department series has more on holding it alone.

The Security Floor

A personal device needs to meet a minimum before it carries work data. The minimum is a policy shape, not a product. There are three things. First is a lock: a passcode, a fingerprint, a face, something that stops a stranger reading the mail off a table. Next are current updates: an operating system its maker still supports, with updates installed. Last is the ability to remove work data. When the person leaves or the phone is lost, the organization's mail and files must be able to come off it without taking the holiday photographs too.

The floor is what makes best-effort safe to offer. If the desk sets up work e-mail on a phone with no lock, the desk has put the organization's correspondence in whichever coat pocket the phone ends up in. The three conditions are quick to check: ask, look, and ask again. If a device cannot meet them, the answer to "will you set up my e-mail" is "not on this one, and here is why". That is the kindest version of no that exists, because it is about the device and not the person.

Which tools enforce the floor, how to configure them, and how far the organization should go toward managing personal devices in earnest are security questions. They belong to the security topics in a later group of this library. For support scope, the shape is enough: the three conditions, checked before configuring anything. They are written in the policy so that nobody at the desk has to invent them under pressure.

The Written Policy

The policy is one page, and one page is a feature. It says what IT will configure, what IT will not touch, the fifteen-minute limit, and the three conditions. It says what happens when a device is lost or a person leaves, and who can grant an exception. Anyone can read it in two minutes. Anyone at the desk can say it from memory, which is the real test. A policy that needs a search box is a policy that is not followed.

Write it in the second person and in terms of what the reader gets. "We will set up your work e-mail and remote access on your own phone or laptop, and we will spend up to fifteen minutes helping when they stop working" is a policy. "Personal devices are supported on a best-effort basis subject to the conditions herein" is a sentence nobody has ever read twice. The warmer wording is not softer. It draws exactly the same line. It just tells the reader which side of it they are on.

Publish it where the requests come from: the portal's first page, the knowledge base, and the new-starter pack. The sentence a technician says at the desk should be the first line of the page, so that the page and the person agree. How to publish scope so that people find it and do not feel scolded by it is the subject of Publishing What You Support.

The Conversation When It Goes Wrong

Three conversations recur, and each has a script: the lost phone, the device that cannot update, and the person who expected a repair. Have the words ready, because all three arrive at bad moments and none of them is improved by improvising.

The lost phone is a security event first and a support ticket second. The script: "Thank you for telling us quickly. We are going to remove work e-mail from the phone now and change your password. Your own data is yours to handle with the phone's maker." Then do exactly that, log it, and tell the person it is done. The person who lost a phone is already having a bad day. The desk's job is to make the work part of it short.

The device that cannot update is a floor problem, and the script is about the floor, not the device's age. "Work e-mail needs a system the maker still updates, and this one has stopped getting them. So we cannot set it up here. If you get a newer one, bring it in and it is fifteen minutes." Nobody is being told their phone is bad. They are being told what the floor is, and that the floor is the same for everyone, including the IT manager's.

The person who expected a repair is Dana, at 08:50, with the crack. The script has three parts. First is the fact ("the screen is a hardware fault, and we do not repair personal devices"). Next is the help ("I can get your forecast off it onto a company machine in the next ten minutes, so noon is safe"). Last is the pointer ("a repair shop can quote on the screen; the maker's site lists the authorized ones"). The help is the part that makes the fact bearable. A no with nothing after it is a wall. A no with ten minutes of help after it is a colleague.

What none of the scripts contain is the phrase "not my problem", in any of its dialects. It is often true. It is never useful, and it lands on the person rather than on the device. The person is the one place the line is not supposed to land.

The Executive Exception

There is an executive exception at nearly every organization, and the honest thing is to write it down. Someone senior will have IT set up and look after a personal device beyond the policy. That might be a tablet for board papers, a home laptop that runs the finance system, a phone that gets a little more attention than the page allows. Pretending the exception does not exist does not make it go away. It makes it invisible, which is worse, because invisible exceptions cannot be reviewed and spread by rumor.

Write the exception with three facts: who it applies to, what it covers, and who approved it. "The managing director's tablet: configured and supported by IT as if it were a company device; approved by the board chair; reviewed yearly" is enough. A named approver is the part that keeps it an exception. "It has always been that way" is not an approver.

Route executive requests through the same door as everyone else's, and treat them as requests. In my experience most executives are relieved to be given a process. The alternative is being the person everyone thinks gets special treatment, which is not comfortable either. The exception, when it is granted, is granted by the executive's own manager or the board, in writing. In that case, the desk does the work without resentment. The work was decided above its pay grade and written down. That is what "above my pay grade" is for.

A Short War Story: A Quarter at Kestrel Payroll

Kestrel Payroll's desk spent one quarter supporting personal laptops with no policy at all. Half the payroll team had brought their own machines when a hardware order was delayed. The desk, being helpful, had configured mail, installed the remote-access client, cleaned up a disk, and swapped a battery. On one memorable afternoon it reinstalled an operating system that then refused to recognize the owner's printer. By the end of the quarter, personal-device tickets were a fifth of the queue. Nearly every one was an argument about what IT should have done differently. Lena, who ran the desk, wrote the one-page policy in an afternoon. It said: configure mail and remote access, fifteen minutes best-effort, nothing else, three conditions, a lost-phone procedure, exceptions through the operations manager. She put it on the portal's first page. Over the following quarter the personal-device tickets fell by two thirds. That was not because the laptops got better but because people finally knew what to expect before they walked over. The remaining third were real, short, and ended with a pointer instead of a debate.

Making the Policy Easy to Follow

A policy is followed in proportion to how easy it is to follow from the device in question. So make the request path work from a personal device with nothing set up on it. The person whose phone will not sync is, by definition, the person who cannot e-mail you from it. If the only way to raise a ticket is from a configured company account, the policy has told them to ask and then locked the door.

The fix is a request route that any browser can reach. Take a web form on the portal that needs no account, no password and nothing installed. With that form, Dana can open the page on the cracked laptop, raise the ticket, and follow the replies, all before anyone has configured anything. QuerySolv's requester portal is built that way: no account, no JavaScript, no particular browser, with the requester identified by e-mail address. So a personal device can open and follow a ticket without being set up first. Whatever tool you have, test it from a phone that has never been on the office network. If that fails, the policy has a hole in its first line.

Then the walk-up sentence. Every technician should be able to say the policy's first line without looking: "We will set up work e-mail and remote access on your own device, give it fifteen minutes when it misbehaves, and not touch the device itself." Say it the same way every time. Consistency is what turns a limit into a rule. A rule people can predict is one they stop arguing with, mostly because there is nothing left to argue about.

The One-Page Personal-Device Policy

Copy this, change the names and the numbers, and have the person the desk reports to sign the bottom. The signature is not ceremony. It is what the desk points at when the line is tested.

PERSONAL DEVICES AT [ORGANIZATION]: WHAT IT WILL AND WILL NOT DO
Owner: IT manager      Approved by: ______________      Last reviewed: ________

WHAT WE WILL SET UP ON YOUR OWN PHONE OR LAPTOP
  - Work e-mail and calendar
  - The remote-access client
  - [The sign-in app, if you use one]

WHAT WE WILL NOT DO
  - Repair, open, or replace parts of the device
  - Install, update, or remove the operating system
  - Install or support other software on it
  - Be responsible for the device after our services are set up on it

HOW MUCH HELP YOU GET
  - Up to fifteen minutes at the desk when our services on the device stop
    working
  - An honest answer about what we found, and who to ask if it is the device
  - A ticket, every time, so that we can see what happens most

BEFORE WE SET ANYTHING UP, THE DEVICE MUST
  1. Lock (passcode, fingerprint, or face)
  2. Run a system its maker still updates, with updates installed
  3. Allow work data to be removed without touching your own

IF THE DEVICE IS LOST OR STOLEN
  - Tell the desk the same day, by any route. We remove work data and reset
    your password. The device and your own data are yours to handle.

WHEN YOU LEAVE
  - Work e-mail and remote access are removed from the device on your last day

EXCEPTIONS
  - Granted only by: ______________ (in writing, on the ticket, with an end date)
  - Standing exceptions, with who approved each:
    ________________________________________________________________

Dana's forecast reached a company laptop by 09:05, which left the morning for the forecast and the afternoon for the repair shop. The crack is still there. It is Dana's screen, on Dana's laptop, and the desk's fifteen minutes went where they were supposed to. Everybody got what the page said they would get, which is a quieter outcome than it sounds.

Frequently Asked Questions