Reducing Email Tickets Before They Reach the Desk

Monday, 08:10, at Oakhurst College. Marta runs the desk of three and has the quarter's tickets open in a spreadsheet, sorted by category. There were 184 about email, out of a little over nine hundred in all. And she has added a column that her technician Leo filled in over Friday afternoon. It is headed "could the user have fixed this with a page in front of them?". Leo wrote yes against 93 of them. A second column, "could we have warned them first?", has a yes against 41 more, nearly all of them full mailboxes. Marta adds the two columns up and looks at the result for a while. A hundred and thirty-four tickets in a quarter, answered by hand, that a page or a warning would have answered first. That is roughly a technician's month.

Reducing email tickets means removing the cause of a ticket or putting the answer where the user finds it before they ask. That way, the desk keeps only the email tickets that genuinely need a person. The general idea, that the answer arrives before the ticket does, is deflection. And the principles behind it are in What Deflection Means. This article applies them to one ticket type with five specific measures. It is the last part of our Email Problems series, and it assumes the categories from the first.

It covers counting before cutting, the mobile setup guide, self-help for junk and rules, and the quota warning before the wall. Then come the shared-mailbox standard and the "is it hacked?" education that sends reports to the right place. We cover fixing the source for the rest and measuring the drop. A short war story follows, then the email self-help index to copy, in that order.

Count Before You Cut

Count the quarter by category before choosing a measure, because the measures in this article each address one category. The one worth doing first is the one with the tallest column at your desk, not at anyone else's. The categories are the seven from The Classic Email Ticket Categories. The counting method, including how to compare quarters without fooling yourself, is in Volume by Category Over Time. To the plain count, add Leo's two columns: could the user have fixed it with a page, and could the desk have warned them first. Those two columns are the whole case for this article, and they take one technician one afternoon.

Oakhurst's quarter is below, and it is one college's quarter, nothing more. The shape at a law firm or a warehouse will differ, and the point of the table is the method, not the numbers. The table showed Marta that two categories, phones and full mailboxes, held half the tickets and nearly all of the preventable ones. It also showed that the hacked worry, small as it was, was arriving in the wrong queue every time.

Read the last column with some respect, because it is the desk's real work and it is not going away. Fifty tickets in a quarter that needed a technician is a reasonable load for three people. The measures below are not about making it smaller. They are about getting the other hundred and thirty out of the way so that the fifty are answered the same day.

The Mobile Setup Guide

The mobile setup guide is one page, with pictures, that walks a user through adding their work account to a phone. A second page walks them through entering a new password on a phone that has stopped syncing. That page will be read ten times as often. The second page exists because the commonest mobile ticket is not a setup at all. It is a phone still trying the password the user changed on their computer last Tuesday. The first article in this series calls that the classic pair. A user who knows that changing a password means updating the phone, and has a page showing where, raises no ticket. A user who does not know raises a ticket, and sometimes a lockout ticket a day later when the phone has tried often enough.

Write the guide generically, by step rather than by screen. The phone's platform will change its screens more often than the desk will update the page. Write "open the phone's account settings, choose the work account, enter the new password where it asks". Pictures from one common phone help and should be labelled as one phone's example. The mechanics of enrolment and setup are in Email and Calendar on Mobile. That article also covers the management profile and what the desk supports on a phone at all, and owns that subject. The mail series only needs the guide to exist. The guide must be the first thing the user sees when they pick "my phone has stopped getting email".

Then put one sentence in the place the password change happens. Put the line in whatever notice the directory or the desk sends when a password is about to expire. Or put it on whatever page the user sees when they change it. The line is "After changing your password, update it on your phone; here is how", with the link. Oakhurst had been sending a password notice for years that said nothing about phones. Adding the line was a ten-minute change, and it did more for the mobile column than the guide did. The warning that arrives at the moment of the cause beats the article that waits to be found.

Self-Help for Junk and Rules

Self-help for missing mail is one article called something like "Where did my email go? Three checks". It is the three cheapest places from Missing Mail, Junk Folders and 'I Never Got It' written for the user. Search the junk folder for the sender's address, search the whole mailbox for it, and read the rules list for anything that moves or deletes. Each check is a picture and two sentences. The article ends with the line that keeps it honest. "If the message is in none of these places, raise a ticket and tell us who sent it, to which address and when". That way, the user who genuinely needs the desk arrives with the three facts the desk would have asked for.

Two more small articles belong beside it. "Keep a sender out of junk" explains the safe-sender list and marking a message as not junk. It stops the repeat ticket from the user whose supplier lands in junk weekly. "Check your rules once a quarter" is a habit article, short. It asks the user to read their rules list and delete the ones from projects that have ended. It is dull, and it removes the single strangest category of missing-mail ticket. That is the one caused by a rule the user wrote in a previous job. The craft of writing these so that a frustrated reader can follow them is in Writing KB Articles People Can Follow. The three-checks article is a good first test of it.

Where the articles live decides whether they work. They are for users, not technicians, so they must be visible without signing in to anything technicians use. And they must appear at the moment the user is about to raise the ticket. If you run QuerySolv, the knowledge base holds articles visible to everyone alongside articles visible only to agents. In that setup, the user's three checks can sit beside the desk's own note on how to search the filter's quarantine. The user never sees the second. In any tool, the test is whether the request form itself offers the article when the user picks "missing mail". That is the deflection-at-submission idea in Deflection at the Point of Submission. An article nobody is shown is an article nobody read.

The Quota Warning Before the Wall

The mail service already warns users before their mailbox is full, and users already ignore it. So the desk's warning has to be different in three ways. It comes from a person, it names a date, and it offers help. Whoever runs the mail service can produce a monthly list of mailboxes within a tenth or so of their limit in a few minutes. Most services can produce it on a schedule. The desk writes to each person on the list, by name, with the mailbox-full reply from Mailbox Full, and the Retention Conversation adapted to the future tense. The reply says your mailbox will reach its limit in about two weeks at the current rate. Here are the three steps that usually free enough space. And here is how to book fifteen minutes with us to set up the archive before it happens.

The message works for a reason the service's own warning cannot copy: it is a person offering fifteen minutes, with a date attached. The service's warning asks the user to do housekeeping sometime; the desk's warning says "a fortnight, and we will do it with you". About half of Oakhurst's warned users dealt with it themselves from the three steps, and a quarter booked the fifteen minutes. The rest hit the wall anyway and were then the easiest mailbox-full tickets the desk had ever handled. That was because the archive conversation had already been offered and only had to be accepted. The mailbox-full column fell from 41 in the quarter to somewhere between 8 and 14 in each of the following two.

Set the archive up for new starters from day one, with the automatic move already on. A user who has never worked without an archive never raises a mailbox-full ticket at all. That is a line on the onboarding checklist, which belongs to The Day-One Checklist, and it is the cheapest item on it. The warning handles the people who are already here. The onboarding line handles everyone after them.

The Shared-Mailbox Standard

The shared-mailbox standard is one page that says what every shared mailbox at the organisation has. Each mailbox has a named owner, a named clearer with a backup, and a register entry. It has exactly one sending permission per person, chosen by the rule that send-as is for functions and send-on-behalf is for people. It has a reply address that returns to the mailbox, and a review date each quarter. The reasoning behind every line and the request form that collects it are in Shared Mailboxes, Delegation and Who Can See What. This section is the rollout, which is the part that reduces tickets. A standard that applies only to new mailboxes leaves the old ones generating the same tickets they always did.

Roll it out in three passes. First, build the register from the mail service's own list of shared mailboxes. That list will be longer than anyone expects and will include several nobody can explain. Second, find an owner for each, by asking the team that uses it. Where nobody will own it, set an end date and close it when the date arrives. Third, put every mailbox through one review against the standard, fixing the permissions as you go. This is where the nine readers with read-only access get send-as and the on-behalf permissions on team mailboxes come off. Oakhurst had thirty-one shared mailboxes, found owners for twenty-two, closed six, and gave the remaining three a quarter's grace. The shared-mailbox column dropped by more than half, and the tickets that remained were genuine requests for new access, which is what the column should contain.

The "Is It Hacked?" Education

The hacked worry does not need reducing; it needs redirecting. Every one of Oakhurst's eight arrived as an email ticket when it should have arrived as a security report. The difference is where it goes and how fast. The education is one short article and one sentence repeated everywhere. It names the three signs that are worth reporting. One is a message in sent items you did not write. Another is a colleague receiving something from you that you did not send. The third is a sign-in warning from a place you have never been. The education also names the one place to report them: the organisation's security address or report button, not the general desk. The article does not teach the user to investigate, because they should not. It does not reassure them that it is probably nothing, because it may not be.

The report route and what the desk does when a report arrives are in The User Reported a Suspicious Email. The reason to thank every reporter, including the ones whose worry turns out to be a forged sender, is in Rewarding the Reporters. The mail desk's contribution is to make sure the route is on the self-help index, on the request form under the hacked option, and in the article about missing mail. A rule the user did not create is found there more often than anywhere. Done well, the number of reports goes up and the number of hacked-worry tickets in the mail queue goes to nothing. Both of those are good news. A security report in the mail queue is a report that waited.

Fix the Source for the Rest

The tickets that remain after the four measures are the ones that need a technician. And some of them need more than that, because a pattern in the cannot-send and cannot-receive columns is a cause rather than a run of coincidences. The same bounce from three users is one problem with the organisation's address. The same phone platform failing after every password change is one problem with the guide, or with the platform. Six mailbox-full tickets from one team is one workflow sending attachments that should be links. The method for noticing these and recording them as problems rather than closing them one at a time is in Finding the Repeat Tickets. The email categories are an easy first place to apply it, since the tickets practically sort themselves by cause.

The source fix is usually a conversation with someone outside the desk. That might be the team manager whose staff mail each other spreadsheets. Or it might be the finance system owner whose reports go to one person forty times a day. Or it might be the records owner who has been meaning to write the retention policy. The desk cannot make those changes and should not try. What it can do is bring the count, say what the count costs in hours each quarter, and offer the fix. A manager shown that their team raised eleven of the quarter's mailbox-full tickets usually asks what would stop it before the desk has finished the sentence.

Measuring the Drop

Measure the drop by category, quarter against quarter, in counts and not in percentages, and say which measure went in when. The honest comparison is the same seven rows two quarters apart with a column for what changed between them. Add a note that the numbers are one desk's, because that is all they are. Oakhurst's second quarter after the measures looked like this. Mobile sync was between 12 and 18 a quarter instead of 52. Mailbox full was between 8 and 14 instead of 41. Missing mail was around 20 to 25 instead of 36. That is a smaller drop and an honest one, since many missing-mail tickets genuinely need the desk's side of the line. Shared mailboxes were between 6 and 10 instead of 22. And the hacked worry was at 0 to 2 in the mail queue, with the security address receiving more reports than before. The cannot-send and cannot-receive rows barely moved, and were not expected to.

Convert the drop into hours rather than claiming a saving, and be plain about the arithmetic. Suppose a page-answerable ticket took the desk a quarter to half an hour including the replies, and a hundred of them did not arrive. That is somewhere between twenty-five and fifty hours in a quarter returned to the fifty tickets that needed a person. That is why those got answered faster and the satisfaction comments on email tickets changed tone. The method for counting what was deflected without flattering yourself is in Measuring What Got Deflected. And the line for the monthly report is the one in The Monthly Report They Will Read: tickets by type, what changed, and what it freed, in hours. The before-and-after by month is a standard volume report in most help desk tools, QuerySolv among them. So the measurement is a filter rather than a project.

Watch for the drop that is not a drop. A category can fall because the measure worked or because users stopped raising the ticket and started asking a colleague. And the two look identical from inside the queue. The quiet-department test from The Seven Ways Support Quietly Fails applies here as everywhere. If one department's email tickets fell further than the measure explains, ask them how they got help last time. The answer is sometimes "the page", which is the measure working. It is sometimes a name.

A Short War Story: The Password Fortnight at Penrose Accountancy

Penrose Accountancy ran a desk of two for about ninety staff. Every spring its directory forced a password change for everyone in the same week. That happened to fall in the middle of the busiest fortnight of the firm's year. The spring that Dmitri joined the desk, the change produced forty-three tickets in ten days from people whose phones had stopped receiving mail. There were also nine lockouts caused by phones trying the old password. The two technicians spent something like twenty hours of the firm's worst fortnight walking accountants through a phone's account settings one at a time. They often did it by phone, while the partners asked why email was broken. The password notice the directory sent had never mentioned phones. Before the following spring Dmitri wrote the two-page mobile guide and added one sentence and a link to the notice. He also asked the directory's owner to stagger the forced change across three weeks instead of one. The next spring produced seven phone tickets and one lockout, and the desk spent the fortnight on tax-season tickets instead. The lesson Dmitri wrote on the desk's board, where it still is, was that the cheapest ticket is the one the warning prevented.

The Email Self-Help Index

The index below is the front page of the email section of the user-facing knowledge base. It lists every common symptom in the user's words, the page that answers it, and the one case where the user should not try to fix anything. Each page it points to is short and has pictures. It ends with "if this did not work, raise a ticket and say which page you tried". That way, the ticket arrives with the first step already done. Put the index where the request form offers it, under every email option. And keep the wording in the user's language rather than the desk's. The last line of the first section is the one most often clicked.

EMAIL SELF-HELP — INDEX PAGE
Start here when email is doing something odd. Each line is one page with
pictures. Each page ends with how to raise a ticket if it did not help.

MY PHONE HAS STOPPED GETTING EMAIL
  Changed your password recently? ......... Update the password on your phone
  New phone? ............................... Add your work account to a phone
  Neither of those? ........................ Raise a ticket: choose "phone sync"

I CANNOT SEND, OR MESSAGES COME BACK
  An automatic reply came back ............. How to read a bounce message
  Nothing came back and it is still there .. The stuck outbox
  The reply mentions "mailbox full" ........ Make room in your mailbox

I NEVER GOT A MESSAGE
  Someone sent it and it is not here ....... Where did my email go? Three checks
  It keeps happening from one sender ....... Keep a sender out of junk
  Mail is going to the wrong folder ........ Check your rules

MY MAILBOX IS FULL, OR NEARLY
  The warning has appeared ................. Make room in your mailbox
  Keep everything, safely .................. The archive, explained
  How long mail is kept .................... The retention policy, in plain words

TEAM MAILBOXES AND WORKING FOR SOMEONE ELSE
  Replies go out under my own name ......... Send as and send on behalf
  I need access to a team mailbox .......... The shared mailbox request form
  I manage someone else's calendar ......... Calendar delegation

I THINK SOMEONE IS IN MY EMAIL
  Do not investigate. Report it now ........ Report a suspicious message or
                                             sign-in: ______________________

RAISE A TICKET INSTEAD WHEN
  The page did not fix it; more than one person is affected; a customer
  or a deadline is waiting; or anything looks like someone else has been
  in the mailbox. Say which page you tried and what happened.

Marta's spreadsheet two quarters later had the same seven rows and a column headed "what changed". The figure at the bottom of Leo's "a page would have fixed it" column had fallen from 93 to somewhere in the twenties. The desk had not got faster at email tickets. It had stopped receiving most of the ones it was never needed for, and was answering the rest within the day. That is the only kind of email ticket reduction that anyone outside the desk ever notices. The fifty that needed a person still arrive every quarter. They are, after all, the job.

Frequently Asked Questions