Mailbox Full, and the Retention Conversation

Wednesday, 09:05, at Ashgrove Housing. Ticket 5520 is from Graham in lettings and reads, in full, "My email has stopped working again." The word doing the work is "again". It is the third time in a year. The previous two tickets were closed the same way, by raising the limit on his mailbox and wishing him well. Graham has every message since his first day, eleven years of them, including every automatic notification the tenancy system has ever sent him. It sends them about forty times a day. Beth, on the desk, raises the limit a third time, because it is five past nine and he has viewings at ten. Then she does the thing the previous two technicians did not: she books fifteen minutes with him on Friday.

A quota is the amount of storage one mailbox is allowed on the mail service. A retention policy is the organisation's written rule for how long messages are kept, where, and what happens to them after that. The retention conversation is the fifteen minutes on Friday. It is a talk with the user about what they keep, why, and where it should live. That conversation is the only thing that has ever ended a recurring mailbox-full ticket. This article is part of our Email Problems series. It is about the ticket, the conversation and the policy behind it.

It covers what a quota is and why it exists, then the ticket step by step, from confirming the fault to making room today. Next come the archive in plain words, the user who keeps everything, and retention policy in plain words. Then it covers the manager who wants an exception and ending the recurring ticket. It ends with a short war story and the mailbox-full reply to copy, in that order.

What a Quota Is and Why It Exists

A quota is a limit on storage. It exists because mailboxes are kept on disks that cost money. Mailboxes are copied every night by a backup that takes longer for every extra gigabyte. They are also searched by a service that slows as they grow. The biggest mailboxes set the pace for everyone. A backup that finishes at six in the morning because of nine very large mailboxes is a backup that one day will not finish. Where the mail service is rented rather than owned, the quota is often the limit the provider sells, and raising it has a price. Either way, the number is not arbitrary and it is not personal. Users are entitled to hear both of those things said plainly.

Every mail service I have run warns before the wall. As the mailbox approaches the limit, a message arrives or a line appears across the top of the client saying so, usually more than once. When the limit is reached the service refuses new mail and says that too. Users ignore these warnings, and it is worth understanding why rather than being annoyed by it. The warning asks for housekeeping. Housekeeping has no deadline, and the warning arrives on a Tuesday afternoon when there are eleven other things to do. The wall, by contrast, arrives at nine on a Wednesday with viewings at ten. The desk's job is to make the warning do what the wall does, which is the subject of the reducing article in this series. This article is about what to do once the wall has been hit.

What stops at the wall varies between services, and the desk should know its own. Some stop receiving and let sending continue for a while; some stop both; a few stop sending first. The messages that cannot be received are not lost. The sender's service gets a bounce saying the mailbox is full, and most senders will try again or phone. That reassurance is the first thing to tell the user, because the fear under a mailbox-full ticket is not the mailbox. It is the invoice that went nowhere.

The Ticket, Step by Step

Confirm the fault before touching anything, because "stopped working" has seven meanings and only one of them is a full mailbox. Ask what the warning says, since it names the limit, the current size and what has stopped. Or have the user send a message to their own address and read the bounce. The diagnostic order for every cannot-send and cannot-receive ticket is in Can't Send, Can't Receive: The Diagnostic Order. The full mailbox is the stop it reaches most often. Once confirmed, tell the user three things in one sentence: what has stopped, that nothing sent to them is lost, and that the first fix takes ten minutes.

Making room today is a matter of finding the few hundred messages that hold most of the space. The table below is the order to look. Deleted items and junk are first because emptying them deletes nothing the user wanted and often frees a tenth of the mailbox on its own. Sent items are second, because the big attachments the user sent are sitting there in copies nobody remembers. Then the inbox and the folders, sorted by size, where the largest hundred messages usually hold more space than the smallest twenty thousand. The automatic notifications, Graham's forty a day, are last in the table and first in the conversation, because they are the ones that come back.

Do the first two rows with the user watching, so that they learn where the space goes. Never delete anything from the third row down without asking. A technician who deletes a user's mail to free space has fixed a ticket and started a grievance. The user owns the mailbox; the desk owns the limit, and the retention policy, when there is one, owns the rest.

If making room is not enough, or the user genuinely cannot do it before the thing they need to send at ten, raise the quota temporarily and write the date it goes back on the ticket. A temporary raise with no date is a permanent raise with a modest name. The permanent fix starts in the next section.

Archive in Plain Words

An archive is a second mailbox attached to the first, where old messages are moved so that the main mailbox stays small. It is the single most useful thing to explain to a user who keeps everything. The archive is still theirs. It is still searchable, usually from the same client, usually with the same search box. It is slower to open and is not always copied to the phone, which is the trade. The mail from three years ago is a few seconds further away and the mailbox the user works in every day stays fast and under its limit. Most mail services can move messages into the archive automatically once they are older than a set age. That is the mechanism that stops the ticket recurring without anyone doing housekeeping.

Users confuse three words, and the desk should separate them once, plainly. Archiving moves a message somewhere slower; the user can still read it. Deleting removes it, and after the deleted items folder is emptied and any recovery window has passed, it is gone from the mailbox. The backup is the desk's copy of the whole service, taken for disasters. It is not a place users can go to fetch an old message on a Tuesday, however often they ask. When a user hears "archive" and reaches for the word "delete", that is the moment to give the three explanations. It takes thirty seconds and it changes the rest of the conversation. The recovery side of this, including what the backup can and cannot bring back, belongs to Deleted Files and Recovery Requests. The mail desk should know where its own line is before promising anything.

Set the archive up on the ticket, with the user, and show them one search that finds a message from before the archive age. That one demonstration does more than any explanation. The user who has watched a three-year-old message come back from the archive in four seconds stops being afraid of it. The user who has only been told about it never does.

The User Who Keeps Everything

The user who keeps everything is not being difficult, and the conversation goes badly from the first sentence if the desk treats them as if they were. They keep everything because mail is the only record of their work they trust, and because they were once asked for a message from four years ago and found it. They also keep it because the audit or the regulator or the complaint might need it. And they keep it because deleting feels like risk while keeping feels free. All of those are reasonable. The desk's job is not to argue them out of keeping, which cannot be won and should not be tried. It is to give them a way to keep everything that does not live in a mailbox that has to fit on a phone.

Open with what they need rather than with what they have. "You need to be able to find any message you have ever been sent, quickly, and to know it is safe. Is that right?" It almost always is, and it is a need the archive meets better than the inbox does. That is because an archive with automatic moving does not depend on the user remembering to file things. Then show the search. Then ask about the one category that genuinely should go: the automatic notifications. Nobody has ever needed those from more than a week ago, and the sending system keeps them anyway. Graham agreed to a rule that deleted tenancy notifications after seven days in about ten seconds, once he was told the tenancy system had its own record. Nobody had told him. For eleven years.

Never say "you don't need that". The desk does not know what a lettings officer needs. The sentence is heard as a judgement about the person's work rather than about the message. Say instead what the archive does, what the policy keeps, and what the rule deletes, and let them decide. A user who chooses to archive keeps their dignity and their mail. A user who was told to delete remembers the technician's name, and not fondly.

Retention Policy in Plain Words

A retention policy is a written rule, owned by the organisation rather than by the desk. It says how long each kind of record is kept, where it lives while kept, and what happens when the time is up. For mail, it usually takes the shape of two numbers. These are the age at which messages move from the mailbox to the archive, and the age at which the archive itself discards them. There are exceptions for anything under a legal hold or in a category the law says must be kept longer. The numbers are not the desk's to choose. They belong to whoever owns records, compliance or legal, with management's signature. That is because a policy that discards mail is a decision the organisation must be able to defend. "IT picked a year" is not a defence.

The desk's part is to implement and to explain. Implementing means setting the archive age on the mail service and the discard age on the archive, as a change with a record. Switching on automatic deletion for every mailbox is exactly the kind of change that needs a plan and a rollback. The shape of that record is in Lightweight Change Management. Explaining means being able to say, in two sentences, what happens to a message on its first birthday and on its last, without the word "compliance". At Ashgrove the records manager chose a year to the archive and a figure for the archive's own life that legal provided. Those are that organisation's numbers and nothing more. Yours will come from your own records owner.

Where there is no policy, which at a small organisation is common, the desk cannot invent one and should not try. What it can do is write a one-page proposal that says what the mail service currently does (usually: keeps everything forever, until the disk or the bill says otherwise). The proposal can say what the two numbers would be and who would need to agree. It can also say what the quota tickets are costing in hours while nobody decides. Take it to whoever owns records and management together. A quota ticket a quarter from fourteen people is a figure that gets a meeting booked.

The Manager Who Wants an Exception

The manager who wants an exception arrives in one of two forms: "my team needs bigger mailboxes" or "just raise mine, I'm not going through all that." Both are reasonable requests the desk is not authorised to grant on its own. The way to handle them is the way to handle every request from above: not a flat no, but a redirect to whoever owns the rule, with a bounded alternative offered on the spot. That move, in detail, is in Saying No Upward, and the mailbox exception is one of its commonest cases.

The bounded yes for a quota has four parts: a limit, a reason, a date, and a name. "Raised to double the standard limit, because the team receives signed contracts as attachments, until the archive is in place for the team at the end of next month, approved by the records owner." Each part protects someone. The limit stops the exception becoming unlimited. The reason makes it possible to say no to the next manager whose team does not receive contracts. The date means the exception ends without a second argument. The name means the desk is not the one who decided. Write all four in the ticket, in the approver's own words if possible, and put the date in the desk's calendar.

Keep the list of exceptions somewhere the desk can read it in one glance, because exceptions breed quietly. A mailbox limit with twenty exceptions is not a limit. It is a suggestion with a spreadsheet. Review the list when the policy is reviewed, and expect to find that half the reasons have lapsed with the project that caused them.

Ending the Recurring Ticket

A mailbox-full ticket that comes back is telling the desk that the last fix was a postponement. The first move on a recurring one is to read the requester's history before replying. Ask how many times, how far apart, and what was done each time. If the answer is "three, a quarter apart, raised the quota" then the quota was never the fix and raising it again is not either. If you run QuerySolv, the requester's earlier tickets and the complete event history on each are a search away. In that case, the word "again" turns into "the third time, and here is what was done the other two" before the first reply is written. In any tool, the history is the diagnosis.

Recurring mailbox-full tickets have three causes, and each has its own ending. The first is a flow of automatic notifications, from a system that writes to the user many times a day. The ending is a rule that deletes them after a week. Ending it also takes a word with whoever owns that system about whether the user needs them at all. The second is attachments, in a role that receives large files by mail every day. The ending is a workflow change, files to the file service and a link in the message. That is a conversation with the team's manager rather than with the user. The third is a user with no archive and no policy. The ending is the archive set up on the ticket and the policy proposal written for the organisation. A quota raise addresses none of the three. It addresses the ticket.

Treat the pattern as a problem, not as a run of incidents, once it shows up in more than one mailbox. Fourteen people hitting the wall each quarter is one cause with fourteen symptoms. The method for finding and recording such a pattern is in Finding the Repeat Tickets. The mailbox-full category is one of the easiest places to apply it, since the tickets practically sort themselves. The step that stops the wall being reached at all, a warning from the desk before the service's own warning is ignored, belongs to Reducing Email Tickets and is not repeated here.

One sign is worth watching for in the ticket itself: the requester replying "it's happened again" to the resolved ticket rather than opening a new one. In QuerySolv, as in many tools, that reply reopens the ticket. A reopened mailbox-full ticket is the clearest evidence available that the fix was a raise and not a change. Count them. A reopen rate on this one category tells you more about the desk's habits than the month's volume does.

A Short War Story: The Fourth Raise at Northgate Retail

Carol ran the finance team at Northgate Retail, and her mailbox hit its limit four times in eighteen months. Each time was resolved by a different technician raising the quota and closing the ticket within the hour. The fourth time was the second day of month-end, when supplier invoices arrive by mail in their hundreds. For two days every invoice sent to her bounced back to the supplier with a full-mailbox notice that most of them did not read. Finance found out when the payment run was short by forty-odd invoices. Carol and two of her team spent about fourteen hours over the following week phoning suppliers to ask them to resend. Meanwhile the desk raised the quota for a fifth time and, finally, looked at the mailbox. Nearly half of it was automatic reports from the finance system, sent to her every morning for six years. Most of the rest was attachments that were also on the file service. The desk set up the archive, wrote a rule that deleted the reports after a month, and took the pattern to the records owner, who wrote the policy the organisation had been meaning to write. The lesson, which the desk lead put in the next monthly report in exactly these words, was that four quota raises had cost less than an hour each and the fifth had cost finance a week.

The Mailbox-Full Reply

The reply below is the message the desk sends on every mailbox-full ticket, filled in with the service's own behaviour and the user's own numbers. It tells the user what happened and what is not lost, and gives three steps that usually free enough space today. It records what the desk did and when the temporary raise ends, and names the follow-up. The last section is the retention sentence, which is the same for everyone once the policy exists and is left blank until it does. Send it as the public reply, and keep the sizes and the date in an internal note. Do the first two steps with the user on the phone if they will let you. Humour has no place in it; the user has an invoice to send.

MAILBOX FULL — THE REPLY
Subject: Your mailbox is full: three steps to get it working now

Hello ________,

WHAT HAS HAPPENED
Your mailbox has reached its limit of ________. Until there is room it
will not receive new messages ________ and will not send ________.
Nothing sent to you is lost: senders receive an automatic notice and
can send again once there is room.

THREE STEPS THAT USUALLY FREE ENOUGH SPACE TODAY
  1. Empty the deleted items folder and the junk folder.
  2. Sort the inbox and sent items by size, and delete or file the
     largest messages; these are usually the ones with attachments.
  3. Search for messages from ________________ and delete the ones
     older than a week. These are automatic notifications, and the
     system that sends them keeps its own record.

WHAT WE HAVE DONE
  [ ] Raised your limit temporarily to ________ until ________ so that
      you can work today.
  [ ] Turned on the archive, which moves messages older than ________
      into a second folder that you can still search from your mail.

WHAT HAPPENS NEXT
We will check the mailbox size on ________. If it is still close to the
limit we will book fifteen minutes with you to set up the archive and a
rule or two, so that this does not come back.

HOW LONG MAIL IS KEPT
Nothing in the archive is deleted by these steps. Messages are kept
according to the retention policy, which is at ________________.

Reply to this message if anything in it is unclear or if the steps do
not free enough space.
________, IT Support

Beth sent Graham the reply at twenty past nine and did steps one and two with him on the phone before his viewings. The deleted items folder alone freed a sixth of the mailbox. On Friday they set up the archive and wrote the rule for the tenancy notifications. He searched for a message from his second year and found it in a few seconds. He described that as "a bit unnerving". Ticket 5520 did not come back. The eleven years are still there, one folder over, and the fourth raise never happened.

Frequently Asked Questions