The Classic Email Ticket Categories, and the First Question for Each

Monday, 08:40, at Meridian Parts. Dev has the queue open and four new tickets in it, and all four have the same subject line: "Email not working". The first is from Rosa in accounts, whose mailbox reached its limit on Friday evening and has been quietly refusing invoices since. The second is from Khalid in the warehouse, whose phone stopped showing new mail the day after he changed his password. The third is from a sales rep who says a customer's order "never arrived". It is sitting in his junk folder with the day's other false alarms. The fourth is from the finance team, who can read their shared mailbox but cannot reply from it. They have reported that, in a tone, as "email is broken". Four tickets, one subject line, four different problems, and not one of them is an email outage.

An email ticket category is a bucket the desk sorts a mail complaint into, named for what is actually wrong rather than for what the user wrote in the subject line. Seven of them cover nearly everything a small desk sees: cannot send, cannot receive, mailbox full, missing mail, shared-mailbox and delegation confusion, mobile sync stopped, and "I think my email is hacked". Each has a first question that sorts it from the others in one exchange. This article is part of our Email Problems series. The series covers the user's mailbox from the first question to the measures that stop the ticket arriving at all.

It covers why the subject line never tells you the category. Then come the seven categories in turn, each with its first question and what the answer usually means. Next it covers what one fictional desk's month looked like when it was counted, and the category-to-first-question table to copy. It ends with a short war story and how to make the categories stick, in that order.

Why "Email Not Working" Is Never the Ticket

Every email complaint arrives wearing the same three words, because from the user's chair every email problem looks identical. The thing they rely on has stopped doing what it did yesterday. They do not know whether the message is stuck on their computer, refused by the mail service, or sitting one folder down from where they are looking. They should not have to know. The subject line describes the feeling. The category describes the fault, and only the fault can be fixed.

Three terms need defining before the categories make sense, because the categories are really about which of three things has failed. The mail client is the program the user reads mail in, on the computer or the phone. The mail service is the system, on a server somewhere, that stores every mailbox and moves messages between them and the outside world. The mailbox is the user's own store on that service: inbox, sent items, folders, junk, deleted items, and a limit on how much it can hold. A client can be broken while the mailbox is fine. A mailbox can be full while the client is fine. And the service can be down for everyone while every client and mailbox is perfectly healthy and empty-handed.

The categories exist so that the first question gets asked. Without them, the technician replies "can you tell me more?", the user replies "it just doesn't work", and the ticket has spent its first day establishing nothing. With them, the technician reads the complaint, guesses the category, and asks the one question that confirms or overturns the guess. Most email tickets are sorted correctly in one exchange this way. The ones that are not are usually two categories at once, which is the subject of the fictional month further down. (A full mailbox and a phone that has stopped syncing are the classic pair. One causes the other, and the user reports the phone.)

Cannot Send

Cannot send is the complaint that a message written and sent did not go. The first question is: "Did anything come back?" A message that left the mailbox and was refused somewhere along the way produces a bounce, an automatic reply from a mail service explaining what it could not do. A message that never left produces nothing, and sits in the outbox, the client's holding area for messages waiting to go. The answer to the first question therefore splits the category in two. A bounce means the message travelled and was refused, and the bounce text says where. Silence means the client never handed it over. That is a client, connection or sign-in problem on the user's own device.

The second question, if there was a bounce, is "to whom?". One address failing is a wrong address, a full mailbox at the far end, or a recipient service that did not like something about the message. Every address failing is the user's own account or the mail service, and that is a different and more urgent ticket. The whole diagnostic order, including how to read a bounce in plain words, is in Can't Send, Can't Receive: The Diagnostic Order. Here, it is enough that the first question is about the bounce, and that the user usually has to be told what a bounce is before they can answer it.

Cannot Receive

Cannot receive is the complaint that mail in general has stopped arriving, rather than one specific message. The first question is: "When did the last message arrive?" A mailbox that received something ten minutes ago is not broken. The user is waiting for a message that has not been sent, or that went somewhere else. In that case, the ticket belongs in missing mail. A mailbox whose last message is from Friday evening, when it is Monday, has stopped, and something happened on Friday evening. That something is usually the mailbox reaching its limit, a password change, or the client losing its connection to the service and not saying so.

The second question is the self-test: "Send a message to your own address and tell me whether it arrives." A message to yourself goes out of the mailbox, through the service and back in. That tests the whole loop in about a minute without involving anyone outside the building. If it arrives, receiving works and the ticket is missing mail. If it bounces because the mailbox is full, the category is mailbox full and the user has just read their first bounce. If it never arrives and nothing comes back, the client or the account is the problem. In that case, the next step is to look at the same mailbox on a different device. Cannot receive is the category most often reported and least often true, which is why its first question asks for evidence rather than for a description.

Mailbox Full

Mailbox full is the complaint behind more cannot-send and cannot-receive tickets than any other. The first question is: "What does the warning say?" Nearly every mail service warns a user as the mailbox approaches its quota, the amount of storage one mailbox is allowed, and again when it reaches the limit. The warning is usually a message in the inbox or a line across the top of the client. The user has usually seen it and closed it, several times, the way anyone closes a thing that asks them to do housekeeping. Ask what it says, and the ticket sorts itself: the text names the quota, the current size and what has stopped.

What stops depends on the service. Some stop receiving first and let sending continue for a while; some stop both at once; some stop sending first, which is cruel but not unheard of. Check what yours does, because the user's description of the symptom will follow that behaviour and you will otherwise be diagnosing the wrong half. The fix in the moment is to make room. The fix that lasts is a conversation about what the user keeps and why, which is the whole of Mailbox Full, and the Retention Conversation. The category's defining feature is that it comes back. A quota raised in a hurry is a quota reached again in a quarter.

Missing Mail

Missing mail is the complaint about one specific message, or one sender, that did not arrive while everything else did. The first question is: "Who sent it, to which address, and when?" All three parts matter. Who sent it tells you whether the sender is inside the organisation, where the desk can see both ends, or outside, where it can see only one. Which address catches the message sent to the user's old address, to a colleague's address, or to an address with a letter missing. When it was sent tells you whether to look in the junk folder, which is sorted by date, or in the filter's quarantine, which the desk looks at. The time may also point to the sender's own outbox, which nobody on this side can look at.

The missing message is almost never lost. It is in one of six places, and the order to check them is cheapest first. That list starts with the junk folder, a rule the user set up and forgot, and the mail filter's quarantine. Next come a bounce that went back to the sender, the sender's outbox, and the message that was never sent at all. The six places, the order, and the honest reply when the fault was at the sender's end are in Missing Mail, Junk Folders and "I Never Got It". The first question here only establishes that the category is missing mail and not cannot receive, which is the difference between one message and all of them.

Shared-Mailbox and Delegation Confusion

This category is every complaint about a mailbox that belongs to a team or to another person rather than to the requester. The first question is: "Which mailbox, and what do you need to do in it: read, reply as it, or reply for it?" A shared mailbox belongs to a role or a team, such as a sales address or a complaints address, and several people open it. Delegation is one person being given permission to work in another person's mailbox or calendar. The complaints look like permission errors, replies going out under the wrong name, and messages nobody answered because everyone could see them and nobody owned them.

The answer to the first question sorts the ticket into one of three requests, and the three are not interchangeable. Reading the mailbox is one permission. Sending as the mailbox, so that the reply appears to come from the team address, is a second. Sending on behalf of it, so that the reply shows both the person's name and the mailbox's, is a third. The difference between the last two is the source of most of the confusion. The permissions, the mailbox nobody owns, and the form that stops the ticket are in Shared Mailboxes, Delegation and Who Can See What. Shared mailboxes are the only category in this list where the fix is usually a decision rather than a repair.

Mobile Sync Stopped

Mobile sync stopped is the complaint that the phone no longer shows new mail, or shows it late, while the computer is fine. The first question is: "What changed in the last few days: a password, a new phone, or the account?" The answer is a password change far more often than anything else. The phone was set up once with the old password. The user changed it on the computer because the computer asked. The phone has been quietly failing to sign in ever since. Some phones say so clearly; some show a small warning nobody notices; some simply stop, and the user discovers it when a colleague asks why they did not answer.

The second cause is the device itself: a new phone with the account not yet added, a phone that lost its management profile, or a mail app that was updated and signed out. The category belongs to this series only for the first question. The setup, the re-enrolment and the guide that stops the ticket are in Email and Calendar on Mobile, which this series links rather than repeats. The one thing worth saying here is the pairing. A phone that keeps trying an old password can lock the account, and the user then raises a lockout ticket about their computer. The two tickets are the same ticket, and the phone is the cause. The article on the lockout that keeps coming back starts its search in the user's pocket for exactly this reason.

"I Think My Email Is Hacked"

The last category is the user who believes someone else is in their mailbox. The first question is: "What did you see that made you think so?" The question is not a challenge. It is the start of a security ticket. The desk's job at this point is to take the report seriously and find out what was observed. It must move the ticket to the security flow without trying to settle the matter in the first reply. What the user saw is usually one of a few things. It may be a message in their sent items they did not write, or a reply from a contact to something they never sent. It may be a colleague saying "I got a strange email from you", a rule they did not create, or a sign-in warning from the service about a place they have never been. Some of these have an innocent explanation. None of them should be explained away by a technician before anyone has looked.

The desk's part is small and specific. Record what was seen and when, in the user's words. Change nothing that would destroy the evidence. Hand the ticket to whoever owns security tickets with the account flagged for review. If the organisation's security function is the same two people who run the desk, the flow is still the same flow. It just has a shorter walk. The triage, the containment steps and what happens when someone clicked are in Phishing Reports and Security Tickets. The mail series hands this category over at the first question rather than carrying it further. The one thing the desk must never do is argue the user out of their worry in order to close the ticket. A user who reports a strange sent item is doing the desk a favour, and the correct first reply is "thank you".

One Desk's Month, Counted

Here is what the seven categories looked like at Meridian Parts, a distributor with about 140 staff and a desk of three. Dev counted one month's email tickets after the fact. The figures are that desk's, in that month, and nothing more. A clinic, a bank or a school would produce a different shape, and the point of counting is to learn your own. The method for counting by category over time is in Volume by Category Over Time and is not repeated here.

The month held 63 email tickets out of roughly 410 in the queue, so about one ticket in seven was about mail. Mailbox full was the largest single category, with 16, and 9 of those were from people who had raised the same ticket in the previous quarter. Mobile sync stopped was next with 14, 11 of them in the week after the directory began prompting for password changes. Missing mail had 12, cannot send 8, shared-mailbox confusion 7, cannot receive 4, and the hacked worry 2. Both of those turned out to be a message from a forged external sender and were handled by the security flow in an afternoon. Dev's note at the bottom of the count read: "16 mailbox-full tickets and we raised the quota 16 times." That sentence became the next quarter's project.

Two things in that table are worth more than the counts. The repeat column shows where the desk was treating symptoms. Nine of sixteen mailbox-full tickets were second or third visits, and four of seven shared-mailbox tickets came from the same two teams. And the cannot-receive row shows the category at its most honest, since three of its four tickets were really mailbox full and had been re-sorted by the first question. The categories are not there to describe the month. They are there to show which first question is being asked too late.

The Category-to-First-Question Table

The table below is the template this article exists for. Copy it into the desk's working notes. Put the first-question column in front of whoever takes new tickets. Put the same question on the request form where the user can answer it before anyone asks. The fourth column is what the answer usually means. The last is where the ticket goes next, which for most categories is another article in this series. Nothing in the table is a fix. It is the sort, and the sort is the part most desks skip.

A Short War Story: One Category Called "Email" at Tollgate Foods

Tollgate Foods ran a desk of two for a workforce of about 220. For a year its ticketing tool had exactly one category for mail, called "Email", which the technicians chose for anything with the word in the subject. When Aisha took over the desk she pulled the year's "Email" tickets and found 190 of them. She also found that the first reply on 140 of those was some version of "can you tell me more about what's happening?". The average ticket had waited a day and a half for the user's answer before anyone knew whether it was a full mailbox or a phone. The mailbox-full tickets, once she could see them, had been raised by the same fourteen people between three and five times each. She split the one category into the seven in this article, put the first questions on the request form, and spent an afternoon on the fourteen mailboxes. The cost of the year had been roughly a hundred and forty wasted first replies, each one a day of a user's waiting. The quota on fourteen mailboxes had been raised more than fifty times between them. The lesson she wrote at the top of the desk's notes was short: a category that cannot tell you the first question is not a category, it is a word.

Making the Categories Stick

Put the first question where the user answers it before the technician reads the ticket. The cheapest place is the request form: a mail problem picked from a short list, and one question beneath it that changes with the pick. "Did anything come back?" under cannot send. "When did the last message arrive?" under cannot receive. Users answer forms more completely than they answer replies, because the form is in front of them while the problem is. The reply arrives a day later when the problem is half forgotten. If you run QuerySolv, each department already has its own request form and mailbox. In that case, the mail questions can sit on the form of the department that answers them rather than on one form for everything.

Categorise at close, not only at open, because the category the user picked is a guess about the feeling and the category the technician closes with is a fact about the fault. Dev's cannot-receive row only became honest because the three mailbox-full tickets in it were re-sorted when they closed. The reasons for doing this on every ticket, not only mail, are in Categorize at Close, Not Just at Open. The mail categories are the easiest place to start the habit, because the fault is usually plain by the time the ticket is resolved.

Count the repeat requesters every quarter, because the repeat column is where the next project lives. A category with many tickets is busy; a category with many repeats is broken, and the two need different responses. Busy is a knowledge article and a form question. Broken is a cause. The sixth article in this series, Reducing Email Tickets, is about removing the causes one category at a time, starting with the one whose repeat column is tallest. Categories do not reduce tickets. They tell you which ticket to reduce, which is the part nobody can do by reading subject lines.

Frequently Asked Questions