As a follow-up to my earlier e-mail post, what I’d like to do is shift the onus of e-mail prioritization from the receiver to the sender. Not unlike an administrative assistant who receives your phone calls and asks the purpose of any proposed meeting request. So here’s how I’d build my Inbox assistant: When you send me an e-mail (assuming you are not on my exclusion list), you’d get this reply:
This is not your normal auto-reply. If you spent any time crafting your email, I’d like to politely ask for a few extra seconds to help me understand how much time you expect me to read, act on, think about, and respond to your inquiry. My system over time will learn what kind of commitments you generally ask of me, and how I can make this process easier, but until then, please tell me if:
[ ] This message is a response to information that I requested. If so, thank you in advance. {if the user clicks on this, the response is automatically processed}
[ ] Is informational, and I should read it by ##/##/##.
[ ] Requires a decision from me, which I should be able to make within # minutes of reviewing your note, or after # hours after thinking about your note. If you need a decision by a certain date, tell me here. If you will default to a decision if I don’t read it by that date, indicate that default decision.
[ ] Is a request for information from me, which you suspect will take # minutes to fulfill.
Optional: My current backlog is ####, with a daily velocity of ###. Therefore with the current amount of non-meeting time allocated to e-mail, you can expect a response around ##/##/##.
Of course the above data point requires updates to anybody en queue if you receive something more important. And if you want to expose a some sort of priority indicator, it may be interesting to see
If you don’t reply to this request, I’ll assume your email is purely informational, of extremely low importance and that you don’t expect a reply.
Now of course these can all be designed as headers or part of the subject line I don’t actually think it would be all that difficult to start selectively parsing things like that. Some simple headers might be:
- RFI [5m] – a 5 minute request for information.
- RFR [a,b,c] – a request for response, with options a, b c, after the issue is explained.
- RFMI – response for more information (becomes part of the thread).
- FYI [2m] – For your information, a 2 minute read
- RFO – request for opinion
Optional Parameters:
- [DueBy XX/YY/ZZ]
- [CONR X] – Consequence of not responding.
- [blocked or default decision]
- etc.
As I wrote this, I wondered if it was fair or reasonable? Then I checked my inboxes and the amount of stuff in them. I don’t think it’s unfair to have a “minute” count on incoming email, or a link count (distractability warning).
What might be nice is a new UI for all of this, but we saw that with Google Wave (which I loved). You either have to disrupt email by completely replacing it, or making it an embedded feature. You can’t have it as a separate tool. It’s too easy to default to email, which is sad, because as I said when I started, it’s become completely broken.
Thoughts? I’d love to hear if you think I’m crazy.