Email and Calendar on Mobile: The Recurring Tickets

Monday, 07:50, at Bellweather Logistics. Ola, a dispatcher, rings the desk from the yard. "My phone stopped getting email on Friday night. I've restarted it twice." Femi opens the account's sign-in history before he says anything, because he has taken this call before. And there it is: a password change on Friday at 16:40. There has been a failed sign-in from a phone every fifteen minutes since, all weekend. The account was locked at 17:10 on Friday and again every morning when the overnight lockout expired. Ola changed her password on the laptop at the end of Friday because the laptop told her to. Nobody told the phone.

Mobile mail tickets are the ones about work mail and calendar on a phone. They cover mail that stopped arriving, a prompt the user does not understand, old mail that seems to have vanished, a meeting at the wrong hour, and a phone that has gone quiet. They recur because the phone keeps its own copy of the account and its own copy of the password. They also recur because the phone is where most people look first in the morning. This article is part of our Mobile Device Support series. The user's mailbox in general, on any device, is the subject of the Email Problems series. This article is about the phone's copy of it, and the five ways that copy goes wrong.

It covers why mobile mail breaks more than desktop mail, then sync that stopped because the password changed. Next come the certificate prompt, the full mailbox on a small screen, the calendar in the wrong time zone and the notifications that stopped. The checks in order, writing the ticket so it does not come back, a short war story and the mobile-mail checklist to copy follow, in that order.

Why Mobile Mail Breaks More Than Desktop Mail

The phone saved the password once and intends to use it forever. A laptop asks the user to sign in again when something changes. A phone's mail app keeps the saved credential and retries it quietly, in the background, on a schedule, without telling anyone. That one difference explains the commonest mobile mail ticket on every desk I have seen. It explains why the account was locked at 17:10 on a Friday by a phone that was in a coat pocket. A phone will keep trying an old password with a patience no human has.

The second difference is that the phone hides its state. On a laptop, "cannot sign in" is a dialog box. On a phone, it is an inbox that has stopped changing, which looks exactly like a quiet morning. The user sees no error, or sees a small badge they have learned to ignore. They report the symptom as "no new mail" when the cause is "no sign-in since Friday". The desk's first job on every one of these tickets is to find out which of the two it is. The user cannot tell you, because the phone did not tell them.

The third difference is that the phone is managed by its platform as much as by the organisation. Battery saving throttles apps in the background. Platform updates reset settings the user chose. And the work profile on a personal phone can be switched off for the evening and not switched on again. None of that is a fault, and none of it is anything the desk can see, and all of it produces tickets that start "my phone has stopped". The desk learns to ask the questions the phone will not answer on its own.

Sync Stopped Because the Password Changed

The mechanism is simple and the ticket is not, because the two halves are usually a weekend apart. The user changes the password, on the laptop or through a reset, and the phone keeps the old one. The mail service refuses the old password. The phone retries it. After a handful of failures the directory locks the account, as it is designed to. The user, now locked out of everything, rings about the laptop and does not mention the phone. The lockout that returns every morning after the desk unlocks it is the signature. The whole diagnosis of that pattern, including the other devices that cause it, is in The Lockout That Keeps Coming Back. The phone is the usual culprit. It is not the only one.

The fix is in two steps and the order matters. First the desk unlocks the account, if it is locked, and checks the sign-in history to see which device is still failing. Then the user puts the new password into the phone. One way is by opening the mail app and signing in when it asks, which managed phones mostly do. The other is by going to the place in the mail app where the work account is listed and entering it there. Do the phone step within minutes of the unlock. That is because a phone that is still holding the old password will lock the account again before the user has finished saying thank you. If the user has two devices, a phone and a tablet, both need the new password, and the tablet is the one they forget.

Prevention is one sentence, sent every time. Every reset reply and every password-change confirmation carries the line "your phone and tablet have the old password; open the mail app on each and sign in again now, or they will lock your account". That sentence, added to the reset template, removes most of these tickets on most desks. The practice of carrying it is the subject of Reducing Mobile Tickets. The reset itself, done so that the new password reaches the user safely, is in The Reset Itself, Done Properly. A desk that resets a password and does not mention the phone has booked the next ticket.

The Certificate Prompt

A certificate is the mail service's proof of who it is. The phone checks that proof every time it connects. That is why a phone can suddenly show a prompt asking whether the user trusts something with a long name. The prompt appears for a few reasons, most of them innocent. The organisation may have renewed or replaced the mail service's certificate. The phone's clock may be wrong so every certificate looks expired. The phone may be on a hotel or café network that interrupts every connection until the user has clicked through a welcome page. Or the phone's platform may be old enough that it has never heard of the authority that issued the certificate. One reason is not innocent: something on the network is sitting between the phone and the mail service, presenting its own certificate in place of the real one.

The advice to the user is the same in every case and it is the opposite of what the prompt invites: do not accept it. Connect to a network you know, check the phone's date and time are set automatically, and try again. If the prompt comes back on a known network, ring the desk. Never tell a user to "just tap accept", in a ticket, a guide or a corridor. That is because the one time the prompt is not innocent that advice is the whole of the attacker's plan. A certificate prompt that persists on the office wireless is a security ticket until the desk has shown otherwise. It goes where Other Security Tickets the Desk Will See says it goes.

The desk's checks are quick. Did the organisation change the mail service's certificate recently, and was that change on the calendar? A planned renewal that nobody told the desk about produces a morning of these prompts. The way to avoid that morning is in Certificates, Expiry and the Morning Everyone Fails at Once. That article is about the VPN and applies word for word to mail. Is the phone's clock right? Is the phone on a captive network? Is the platform old? If none of those, treat it as the security ticket it might be. Certificates are dull for eleven months and then the most important thing on the desk for a morning.

The Full Mailbox on a Small Screen

Three different tickets arrive in the same words, "my mailbox is full", and the desk tells them apart with one question: can you still send? The first ticket is the user whose old mail "has gone" from the phone. It has not gone anywhere. The phone shows only a recent window of mail, a few weeks or a month by default, to save space. Everything older is on the server and reachable by searching from the phone or by opening the laptop. The user can widen the window at the cost of storage on the phone, and the guide says how in plain words. This ticket is closed by explanation, and the explanation is worth writing once in the knowledge base.

The second ticket is the mailbox that is genuinely full on the server. The user cannot send. The warning was a small banner the phone showed once. The fix is a conversation about retention and archiving that has nothing to do with the phone. That conversation is the subject of Mailbox Full, and the Retention Conversation. The phone's only part in it is that the phone is where the warning was missed. The third ticket is the phone's own storage being full, which stops attachments downloading and eventually stops mail syncing at all. That is a ring-two problem in the terms of What the Desk Supports on a Phone. The desk helps the user clear space for a bounded time, because until it is cleared something the desk owns does not work.

Ask "can you send?" and then "is it the phone or the mailbox that says it is full?", and the three tickets separate in under a minute. The user will not know which they have, and should not have to. The phone showed them one word, and the word was "full".

The Calendar in the Wrong Time Zone

The travelling user lands, and the phone changes its time zone on its own. The calendar follows the phone, and the ten o'clock meeting now shows at a different hour. This is correct and it is alarming, and the ticket arrives as "my calendar is wrong". It is not wrong. The meeting is at the same moment it always was; the clock on the wall has moved. The honest explanation is that sentence, and it is worth saying slowly. That is because a user who understands it stops ringing about it, and a user who was told "that's just how it works" rings from every airport.

The genuine faults are elsewhere and the desk should know the three. The mailbox on the server has its own time zone setting, fixed when the account was created. A starter whose mailbox was created in head office's zone while they sit in another sees every invitation offset until it is corrected, on the server and not on the phone. The laptop may have a different time zone from the phone, so the same meeting shows two different hours on two screens on the same desk. And all-day events, which have no hour, can appear to span two days on a phone in a different zone. That is not a fault but is reported as one every single time. Time zones are the one subject on which the phone is usually right and the user, the laptop and the organiser are each wrong in a different direction.

The checks are: what zone is the phone in? What zone is the mailbox set to on the server? What zone was the meeting created in? And does the laptop agree with the phone? Correct the mailbox setting where it is wrong, leave the phone alone, and send the user the one-sentence explanation. Write that sentence into the knowledge base article as the first line, because it is the answer most of the time and the other three are edge cases.

The Notifications That Stopped

Mail arrives when the app is opened and nothing announces it, and the user, reasonably, reports that mail has stopped. It has not; the announcement has. The causes live entirely on the phone, where the desk cannot see them. They come in a short list: the platform's battery saving has restricted the mail app in the background, or a platform update switched the app's notifications off or reset them to silent. Another possibility is that a do-not-disturb schedule or a focus mode is on and the user forgot setting it. On a personal phone the work profile may have been paused for the evening and never resumed. Or the phone is new and the mail app was never allowed to notify in the first place.

The desk reads the list and the user checks each item, in that order, because the order is roughly by likelihood and exactly by ease. The desk describes each check rather than naming a setting, because the names move. It asks about "the place where the phone decides which apps may run in the background" and "the app's own notification switch". It asks "whether the phone is set to be quiet right now" and "whether the work side of the phone is switched on". Five questions, five minutes, and the cause is found in the first two more often than not. (The user who says "I never touched anything" is telling the truth; the update touched it.)

Set the expectation honestly, because the platform does. Notifications on a phone are delivered on a best-effort basis by the platform's own design. They are delayed when the phone is saving power. The organisation cannot make them certain without the user keeping the app awake at a cost to the battery. A dispatcher who needs to know within seconds that a message arrived should not rely on a phone's notification. That is a conversation about the right tool for the job, not a fault in the mail app.

The Checks in Order

The order below is cheapest first and most revealing first, which on this ticket happen to be the same. The desk's own screens are checked before the user is asked to do anything. That is because the sign-in history answers the commonest question in ten seconds and the user cannot answer it at all. Re-adding the work account on the phone is the last step and never the first. It hides the cause, so the ticket comes back. It loses nothing on a managed phone but on some setups it removes more than the mail. And it is what the user has already tried before ringing, which is why they are ringing.

Step two deserves a word, because it is the step that turns one ticket into a dozen. If the sign-in history looks clean and the mail service changed something this morning, stop treating the ticket as one phone and check the queue for others. That is because, in that case, the second and third are already on their way. The general diagnostic order for a user who cannot send or receive on any device is in Can't Send, Can't Receive. The mobile order above hands over to it at step two whenever the service, not the phone, is the suspect.

Writing It So It Does Not Come Back

The ticket's resolution note carries the cause in one line, the fix in one line, and the prevention sentence that was sent to the user. That is because the next technician to open a ticket from the same person will want to know it was the phone last time too. What the note never carries is the password, the new one or the old, or a screenshot that shows either. The internal note on a ticket is for the desk's eyes and it still holds no secret. In QuerySolv the public reply and the internal note are separate things on the same ticket. The rule on both is the same. The rule for what never goes in a ticket at all, and where it goes instead, is in What Never to Write in a Ticket.

The user-facing article is one page with three things to check before ringing. Did you change your password recently? Is the phone on a network you know? And does the mail app show a message at the top? Three questions deflect the tickets that users can close themselves and bring the rest to the desk with the answers already in hand. The place that page belongs, and the index of mobile self-help it sits in, are in Reducing Mobile Tickets. One page, written once, read by every user who was about to ring.

Record the cause as well as the symptom. That lets the monthly count say "password change: twenty-two of the thirty-one mobile mail tickets" rather than "mobile mail: thirty-one". The symptom is what the user reported. The cause is what the desk found. And the count by cause is what tells the desk which sentence to add to which template. The symptom count tells it only that phones exist.

A Short War Story: The Tablet in the Drawer at Fairmile Dental

At Fairmile Dental, the practice manager, Ruth, was locked out of her account at half past seven every morning for three weeks. Hamid, who was the whole desk, unlocked it every morning at a quarter to eight and checked her phone and her laptop, both of which had the new password. On the sixteenth morning the lockout landed in the middle of the appointment-book sync and the reception could not see the day's bookings for twenty minutes. That is when Hamid stopped unlocking and started reading the sign-in history properly. He found a third device, an old tablet, failing every morning at 07:30. It was in a drawer at reception, on a timer that woke it to show the day's schedule. It was still carrying the mail app with the password Ruth had changed three weeks earlier. Twenty lockouts, about five hours of Hamid's time and as much of Ruth's, and one bad morning at reception, for a device nobody remembered owning. When a lockout follows a password change, hunt for the device still holding the old password, and expect it not to be the one in the user's hand.

The Mobile-Mail Checklist

The checklist below is the one Femi keeps beside the phone. Section A is the desk's own checks, done before the user is asked anything. B is the questions to the user in order. C is the five recurring causes with their fix and the prevention line for each. D is what goes in the ticket when it closes. Print it, and add the organisation's own words where the blanks are. It fits on one side and it is read from, not remembered.

MOBILE MAIL — THE CHECKLIST
Ticket: ________   User: ______________   Phone: company / personal   Symptom in the user's words: ______________________

A. BEFORE ASKING THE USER ANYTHING (desk screens)
   [ ] Sign-in history: account locked?  password changed on ________?  last good sign-in from a phone: ________
   [ ] Any other device failing sign-in (tablet, old phone, second phone)? ______________
   [ ] Mail service healthy today?  Any certificate or settings change today? ______________
   [ ] Management service: phone enrolled and compliant? ______________

B. QUESTIONS TO THE USER, IN ORDER
   1. Did you change your password recently, on any device? ________
   2. Open the mail app: is there a message, banner or prompt anywhere on the screen? Read it to me.
   3. Is the phone on a network you know? Does a web page load?
   4. Can you send a message to yourself? Does it arrive?
   5. Is the phone low on storage? Set to save battery? Set to be quiet right now? Work side switched on?

C. THE FIVE CAUSES — FIX AND PREVENTION
   Password changed     Fix: unlock; new password into the mail app on EVERY device within minutes
                        Prevent: the reminder sentence in every reset reply and change confirmation
   Certificate prompt   Fix: do not accept; known network; check date and time; retry; persists = security ticket
                        Prevent: certificate renewals on the calendar; desk told in advance
   Mailbox "full"       Ask: can you send?  Old mail "gone" = sync window, explain; server full = retention
                        conversation; phone storage full = clear space, bounded time
   Wrong time zone      Fix: check phone zone, mailbox zone on the server, meeting's zone, laptop zone;
                        correct the mailbox setting; leave the phone alone
                        Prevent: mailbox zone set correctly at account creation
   Notifications quiet  Fix: background restriction, app's own switch, quiet mode, work profile paused,
                        new phone never allowed; read the list in order
                        Prevent: a line in the setup guide; honest expectation about best-effort delivery

D. WHEN IT CLOSES
   Cause (one line): ______________________   Fix (one line): ______________________
   Prevention sentence sent to the user: [ ]   Cause recorded for the monthly count: [ ]
   No password, old or new, anywhere in the ticket: [ ]

Femi unlocked Ola's account at 07:52. He kept her on the line while she opened the mail app and signed in with Friday's password. He watched the sign-in history go green before he let her go. The weekend's mail arrived in the yard in a single rush at 07:55. Then he opened the reset template and added one sentence to it. The following month the desk's count showed the password-change cause at a third of what it had been. The one dispatcher who still rang had a tablet in the cab.

Frequently Asked Questions