Reducing Mobile Tickets: Standard Device, Guide and Reminder

Friday, 15:30, at Northgate Retail. Marta, who leads a desk of four across eleven stores, has the quarter's ticket export open and a filter on the word "phone". Two hundred and twelve tickets, which is about one in seven of everything the desk did in three months. Until this afternoon she had thought of them as weather: phones are fiddly, people have them, tickets happen. Then she adds a column for the cause, fills it in from the resolution notes for an hour, and sorts. Seventy-one of the two hundred and twelve are the same ticket. The cause column says "password changed, phone not updated" seventy-one times, in four technicians' handwriting.

Reducing mobile tickets means finding the handful of causes behind most of them, in order of count, and removing each cause at the cheapest point. That might be a sentence in a template, a line in a guide, a page users can find, a standard phone the desk knows by heart. It is not about making users ring less. It is about making the reason to ring not happen. This article is part of our Mobile Device Support series, and it leans on the five articles before it for the fixes. This one is about which fix first, and how to know it worked.

It covers counting before cutting, then the standard device, the setup guide that prevents the call, and the password-changed reminder. Next come the authenticator-on-a-new-phone runbook, the self-help index, measuring the category, and what will not go away. A short war story and the mobile self-help index to copy finish the article.

Count Before You Cut

The symptom is what the user said; the cause is what the desk found; and the count that matters is by cause, because the fixes attach to causes. A desk that counts "mobile: 212" knows that phones exist. A desk that counts "password changed, phone not updated: 71" knows which sentence to add to which template on Monday. The cause goes on the ticket at close, in a short fixed list, which is the discipline set out in Categorize at Close, Not Just at Open. The mobile list needs about eight entries and the last one, "other", should be small and re-read every quarter. "Other" is where tickets go to avoid being counted.

The table below is Marta's quarter, with the minutes per ticket as a range from the four technicians' estimates and the hours worked out from the middle of each range. It is a fictional desk and the numbers are its own; yours will differ in the counts and probably not in the order. The method for cutting a quarter's tickets by category and watching the cut over time is the subject of Volume by Category Over Time, and the mobile cut is one row of that sheet given its own page.

Three causes make up one hundred and thirty-eight of the two hundred and twelve. All three are the same shape: a thing the user was never told, at the moment they needed to be told it. That is good news, because a sentence is the cheapest fix there is. The order of work is by hours, not by count, and here they agree. Where they do not, do the cause that costs the most hours first, because that is the one the desk will feel. The general craft of finding the few sources behind most tickets, across devices, apps and processes, is in Finding Hotspots in the Ticket Data, and this article is that craft applied to one category with its sleeves rolled up.

The Standard Device

A standard device is the one or two phone models the organisation issues, on one platform where it can manage that, chosen so that the desk knows them by heart. Every argument for a standard laptop applies to a phone and one more besides. The phone's guide, the phone's known failures and the phone's loan pool all assume a model. A fleet of fourteen models has fourteen guides or, more usually, one guide that is right for three of them. The case for standards, refresh cycles and the retirement of models that generate tickets is in Reducing Hardware Tickets. The way to find the model that is quietly producing more than its share is in Device and Model Hotspots. Phones go through both exactly as laptops do.

The standard device also makes the loan pool work. A lost or broken company phone is replaced from a small pool the same day only if the pool holds the same model as the one it is replacing, enrolled to the same guide. A pool of mixed hand-me-downs is a drawer of phones nobody can issue. Two models in the pool, one for most roles and one for the few that need something different, and the swap is a ticket of twenty minutes rather than an afternoon. The person who wants a third model because they prefer it is asking the desk to carry a third guide, a third set of known failures and a third pool. The honest answer is the arithmetic rather than the word no.

Personal phones cannot be standardised and the desk should not try. There, the standard is the work profile, which behaves the same way on every phone the platform supports. The guide is written for the profile rather than for the handset. The desk supports the work on a personal phone and not the phone, which is the boundary drawn in What the Desk Supports on a Phone. The boundary is what keeps the personal estate from generating a guide per model.

The Setup Guide That Prevents the Call

The twenty-nine starter calls in Marta's quarter were the guide's fault, which she found out by reading the notes. The guide skipped the management profile, assumed a wireless network that the store floor did not have, and told starters to register the second factor "later". The guide itself, how it is written, tested on a fresh phone and checked from the desk's side without a visit, is the subject of Enrolment and Setup Without a Visit. Here the point is only that a good guide prevents calls that arrive weeks after setup as well as the ones that arrive on day one.

Three lines in the guide remove three later causes. The second factor registered at setup removes the day-two ticket when the mail service first asks for a code. The backup codes saved off the phone remove the lockout when the phone is lost. And the line "changing phones? register the authenticator on the new one before wiping the old one" removes a share of the thirty-eight new-phone tickets before they are born. That is because the user read it once, on the day they set up, and remembered it when the new phone arrived. A guide is not only a setup document. It is the one page every user reads carefully, because they cannot get mail until they have.

The Password-Changed Reminder

Seventy-one tickets, and the fix is a sentence: "your phone and tablet still have the old password; open the mail app on each and sign in again now, or they will lock your account". The sentence goes in every place the password changes. That includes the reset reply the desk sends and the confirmation a self-service reset shows on its last screen. It includes the message the organisation sends when a password is about to expire, and the resolution note of any lockout ticket. The reset itself, and the template the sentence lives in, are in The Reset Itself, Done Properly; the diagnosis when the sentence was not sent and the lockout returns every morning is in The Lockout That Keeps Coming Back. The mobile article's contribution is to insist that the sentence is sent every time, by everyone, including the technician who is sure this user does not have a phone.

Add one question to the reset runbook as well: "which devices do you read work mail on?", asked before the unlock. That way, the technician can say "and update the tablet too" rather than unlocking an account that a tablet in a drawer will lock again in eleven minutes. Marta's seventy-one fell to the low twenties the following quarter, and the twenties were users with a second device they had forgotten, which the question then caught. A sentence and a question, both free, and about fifteen hours a quarter returned to a desk of four. Nothing else in this article pays back as fast.

The Authenticator-on-a-New-Phone Runbook

The thirty-eight new-phone tickets have one story. The user bought or was issued a new phone, moved their things across, and wiped or traded in the old one. They discovered the next morning that the authenticator app on the new phone was empty and the old phone was gone. The runbook for getting them back in, with the identity check it needs and the order it runs in, belongs to Second-Factor Problems and is not repeated here. What this article adds is the prevention, which happens the week before the ticket and is two things: a page and a step.

The page is a self-help article titled in the user's words, "Changing phones? Do this first". It says: before you wipe or hand in the old phone, register the authenticator on the new one. Then check that a code from the new phone works, then wipe the old one. Three steps, written without a setting name, put where users will see them before the moment matters: in the setup guide, in the self-help index, and in the reply to any ticket that mentions a new phone. The step is for company phones, where the desk issues the new handset. The swap-day checklist has "second factor registered on the new phone before the old one leaves the building". The technician does it at the desk with the user present. Thirty-eight became nine in Marta's next quarter, and the nine were personal phones whose owners had not read the page. The page was then linked from the reset confirmation too, on the theory that everyone reads that.

The Self-Help Index

A self-help index is one page that lists the handful of mobile problems users actually have, in the words they use. Each has a one-line fix and a link to the fuller article. It is not a knowledge base section; it is a single page a user can read in a minute before ringing, and its whole value is that it is short. The five entries, for most desks, are the password change, the new phone, the notifications that stopped, the office wireless, and the lost phone. The lost phone's entry is a number to ring rather than a fix. Write each title as the user would say it: "my phone stopped getting work email", not "mail synchronisation failure".

Put the index where the user is when the problem happens, which is on the phone with no mail. So it is a knowledge base article visible to everyone rather than agents only, as QuerySolv and most tools allow. It is also linked from the three messages every user receives: the setup guide, the reset confirmation and the first reply to any mobile ticket. The question of where an answer has to be for someone to find it before they raise a ticket is the subject of Where the FAQ Goes. The mobile index is a short answer to it: in the three places the user already is.

Keep the index to one screen, keep every entry free of setting names so it survives platform updates, and date it. The index is owned by the same person who owns the setup guide, reviewed when the quarterly cause count changes, and pruned when an entry stops earning its place. An index with twenty entries is a knowledge base section with a modest title, and nobody reads it on a bus.

Measuring the Category

The measurement is the same count by cause, repeated each quarter and laid beside the last, in counts and in hours. The honest report is "about 210 mobile tickets a quarter to about 120, roughly 40 hours a quarter returned, with the password cause down by two thirds and the new-phone cause down by three quarters", in ranges, with the counts beside the hours. The trend sheet that holds those quarters, and the way to read a drop that is real against one that is noise, are in Volume by Category Over Time. The line for the leadership report, which turns hours returned into a sentence a director will read, is in The Monthly Report They Will Read. The mobile count is one line in both.

Watch for the drop that is not a drop. Mobile tickets are the easiest kind to stop logging, because "it was just a phone thing" and the technician fixed it at the till. A category that falls because the desk stopped counting has measured nothing but its own habits. Log every one, including the one fixed in the corridor. If the cause count must be cut by technician at all, read it as coaching and never as ranking. Do not read that count from fewer than forty or so tickets of a comparable kind. A technician whose mobile tickets take longer is usually the one who gets the lost phones.

Report the floor as well as the drop. The lost devices, the starters and the platform's own updates do not go away, and a desk that promises "mobile tickets to zero" has promised something the platform will break by autumn. The honest shape of the report is "the category is now mostly the things that cannot be prevented, and here is what those cost", which is a sentence that stays true.

What Will Not Go Away

Three causes are the floor. Phones are lost, and the runbook makes that fast rather than rare. Starters arrive, and the guide makes their setup quiet rather than absent. And the platform updates itself, every season, in a way that moves settings, resets notifications, and occasionally asks every enrolled phone to accept something again. Those updates produce a spike the desk can see coming and cannot prevent. The platform update is the one to plan for: it is on a calendar the platform publishes. The guide is retested on a fresh phone after each one. A short note goes to users the week before saying what they may see and what to do. That is the subject of the war story below.

The carrier is a fourth, smaller floor: signal, bills, roaming and SIM problems belong to the carrier and arrive at the desk anyway, because the desk is where people go. Those are ring-three tickets, pointed and not fixed, and the index's job is to point them before they are raised. A category made of the floor and little else is the goal, and it is reachable in two or three quarters on most desks. (The fourth quarter is when someone proposes a tablet pilot.)

A Short War Story: The First Week of Term at Oakfield College

At Oakfield College, a platform update over the summer meant that every enrolled staff phone, about ninety of them, needed the management profile accepted again before the mail app would open. The two-person desk found out on the first morning of term when the first forty of them rang between half past eight and ten. There was no guide for the re-acceptance, and the setup guide had not been tested since spring. The step that the phones were asking for had a name neither technician had seen before. So each call took twenty to forty minutes of reading the screen aloud. The desk lost most of the first week of term to it, somewhere over sixty hours between the two of them, with the queue for everything else growing behind it. The following year, the desk retested the guide on a fresh phone in August. It wrote a two-step self-help note titled "your phone may ask you to accept the work profile again". It sent the note to all staff the week before term with a line saying it would take two minutes. The first week's spike was eleven tickets, and the technicians had their coffee. The spike was on the calendar both years. The second year, so was the guide.

The Mobile Self-Help Index

The index below is written for the user and published where they already are. It is a knowledge base article visible to everyone, linked from the setup guide, the reset confirmation and the first reply to any mobile ticket. Each entry has the title in the user's words, the one-line fix, and a blank for the link to the fuller article. Fill in the organisation's own number for the lost phone and its own words for the wireless, and date the page. Five entries, one screen, no setting names, reviewed each quarter against the cause count.

BEFORE YOU RING ABOUT YOUR PHONE — FIVE THINGS TO TRY
Last checked: ________   Owner: ______________   Desk number, any day: ______________

1. MY PHONE STOPPED GETTING WORK EMAIL
   Did you change your password recently, on any device?  Open the mail app on the phone and sign in
   again with the new password. Do the same on a tablet if you have one. Mail usually returns in a minute.
   Still nothing? Check the phone is on a network you know, then read us any message at the top of the mail app.
   More: ______________________

2. I HAVE A NEW PHONE AND THE AUTHENTICATOR IS EMPTY
   Before you wipe or hand in the old phone: register the authenticator on the new phone, check a code
   from it works, then wipe the old one. Already wiped the old one? Ring us; we will confirm it is you
   and set the new phone up. Have your backup codes to hand if you saved them.
   More: ______________________

3. MY PHONE HAS GONE QUIET; MAIL ARRIVES ONLY WHEN I OPEN THE APP
   Check, in this order: is the phone saving battery and limiting the mail app in the background;
   is the mail app's own notification switch on; is the phone set to be quiet right now; on a personal
   phone, is the work side switched on. One of the first two is usually it.
   More: ______________________

4. MY PHONE WILL NOT JOIN THE OFFICE WIRELESS
   Our wireless network is called ______________. Join it with your work account, not a personal one.
   If the phone asks you to trust a certificate, do not accept it; ring us instead.
   More: ______________________

5. I HAVE LOST MY PHONE, OR IT HAS BEEN STOLEN
   Ring ______________ now, on any day, at any hour. We will protect your work account first and sort
   the phone out second. Thank you for ringing straight away; that is the thing that matters most.
   More: ______________________

ANYTHING ELSE ON THE PHONE
   The carrier handles signal, bills and roaming: ______________.  A repair shop handles screens and batteries
   on a personal phone; for a company phone, ring us.  The phone's own help pages cover its camera, photos and apps.

Marta published the index on the Monday and added the sentence to the reset template on the same afternoon. She asked the store managers to pin the "changing phones" page to the back-office noticeboards, where it was read by people who never read e-mail. The following quarter's export had a hundred and eighteen tickets tagged "phone". The cause column was filled in on every one, and the biggest row was starters, which was the row she wanted to see at the top. Nobody told her phones had stopped being fiddly. They had simply stopped being a surprise.

Frequently Asked Questions