A simple mapping problem that we all encounter frequently is 'mentally translating' emails into outputs/actions. The typical inbox is full of email Subject Lines that offer no support for translating the email into a useful output from the recipient. Usually the recipient has to open them to even begin to process them. Even once the mail is open, the format usually does not map well onto the outputs required of the individual. In short, most emails take too long to process. They are a high-bandwidth activity; unnecessarily so. Given how many emails most of us have to respond to in a typical day, solving this problem really should be a priority of individuals and organisations.
Many books look in detail at how to improve email, so I'll just quickly look specifically at one small way to help by improving the mapping. In order to 'action' an email, the learner is usually trying to map the information from it to the following:
Do I need to open this email? is it important? can it wait?
Is this providing information or a request for information or action?
If this is sent to many people, who should respond? me?
If an action, when should this done by?
Is this a priority item? Can it wait? Does it have a small or major impact if I don't answer it?
What is the key information I need to see? What is secondary?
With a small amount of thought, it is easy to see how emails can be formatted to map more readily onto these recipient-requirements. Here's some examples:
Standard Subject Line
If all email Subject Lines followed a standard structure, many emails could be processed without even being opened. A good subject line should have:
ACTION vs. FYI (for your information) vs. INFO REQ (information request)
Meaningful headline
Completion date or priority
Some examples
ACTION complete task by TOMORROW
ACTION respond to proposal; HIGH PRIORITY
FYI cafeteria closed; LOW
ACTION comments on idea; by 5th June
These subject lines have a good mapping to the main concerns of the recipient, thus lowering the mental 'translation' required to do something useful with the emails and respond appropriately.
This approach also makes use of the rule of 'visibility' - well structured Subject Lines make important things 'stand out' (i.e. makes them visible) and thus speeds processing.
This approach can then be continued in the main body of the email. A good structure for an email might be:
Why copied in? Note why individuals have been copied in
Need to respond? Note anyone who needs to respond
Headline: main information/requirement of the email
Body text: detail to support headline
For example
John, Sarah, Bob - copied you in just for you information; no need to respond
Ian - need a decision from you please
Should we hold our annual conference in Hawaii?
As you know, we often have our conference in Slough. I can't help but think that a more sunny venue might improve our spirits for the important yearly brainstorm....
So, as an organisation, you could all agree to a standard format for emails to speed up daily email processing. If the format is adhered to firmly, it can even be used to support individuals who use automatic rules when processing emails (e.g. setting up a rule to send any email that starts with 'ACTION' to their tasklist).
I read one author who discussed how they format their emails in such a way as to guide responses in helpful ways to minimise their mental processing, for example:
When should we meet up? Please put YES after one of the following:
tomorrow at 10am
Wednesday at 2pm
Other date (please specify)
You could even create a web page that explains why your company uses these rules and share it with your customers to encourage them to join in.
Of course, this only starts to tackle the problem of information overload. The bigger issue is that email in general often maps poorly onto the tasks we want to perform. Often the solution is to choose an entirely different vehicle for certain types of task. E.g. using a specialist system to receive customer complaints that automatically sorts and organises them in different ways and ensures each is processed. More on that later...
