We are always pleased to be complemented on our customer support. Often the complement comes with a request for advice on how to handle a large volume of email efficiently, be it at work or home. The trick is an empty inbox. This does not mean that our inbox is empty on the contrary, it normally has a few tens of emails in it yet everything in the inbox is being actively worked on. We don’t move messages to new folders based on priority or who should deal with them as they will inevitable be forgotten.
The inbox automatically then works as a to do list and by keeping it date ordered the priority of messages decline as they drop down the stack. This puts you on the habit of dealing with messages as they arrive or if not a few days later as you continue to stare at them in the inbox. The corner stone of the philosophy of getting things done – if you can do something right away then get to it.
However, there comes the occasional feature request that would take many hours to complete and you do need a long term to do list for those. For these emails we transpose the request into a Lighthouse ticket that allows us to search it and give it a priority and define the milestone it should be associated with. Lighthouse issues are only reviewed and worked on with major releases to keep us focused on our own road map of features.
There are two weaknesses to this system. First being rare and impossible to reproduce bugs that tend to fall quickly down the stack and against our own advice go into a bugs folder after a few weeks. This is the black hole of support requests. The only reason they go into a folder instead of being deleted is that they have become so hard to fix or inconsequential that I am now waiting for someone else to report the same issue to cross reference it. Currently the Bugs folder has 28 messages, of which I am pretty sure most are fixed and irrelevant today. For example the oldest, from 1/4/09, is about Pocketpedia1 not displaying a few Korean characters correctly. I like to think it’s fixed, but otherwise will wait for another Korean user to report it with Pocketpedia3.
The second issue is that by waiting to take action on an email before replying to the users means a few users might feel they didn’t get through to you when their request takes several days to complete. This is the recent case of Tom, who emailed us about printing and emailing a selection with a specific template. I immediately got to work on improving the programs. They now have the ability to print a selection instead of having to create a “Collection from Selection” and then use print. In the beta version of Bookpedia you can hold down the option key when clicking on the File menu and you will get a “Print Selection” command instead of the regular print or command-option-P; saving Tom and other users a couple of steps. This feature has been in the beta since two days after Tom wrote, yet the template requires painstaking work in HTML that I haven’t gotten around to. I foolishly wanted to finish the template before writing back to Tom, this was were I failed. Although I view Tom’s email everyday and sometimes work on it (tried to print out the edit window but did not succeed – the final template would have a similar look) he doesn’t know that we are paying attention.
To make sure this never happens all email in your inbox should be read after a couple of hours of being received, if not being worked on immediately they should be flagged and if they reach the point were they been in the inbox for more than a day they should be marked as replied so that users have the peace of mind that you are given their email attention. Even if it’s a simple “We are on it”.
On the days you achieve an empty inbox, then it’s time to celebrate and have a nice meal with loved ones. Now if I can get that template done, I would be at zero inbox Today.