In New York State, and I suspect in other places as well, when you visit a Department of Motor Vehicle (DMV) office to get a new license, register your sailing vessel, or try to convince the nice bureaucrats that you did in fact pay those old parking ticket fines, there is generally a two-step process for obtaining services.
You first enter the office and wait in line to be triaged by a DMV rep, and once he/she determines the nature of your inquiry, you receive a little paper ticket by which you are assigned a customer number, and an estimated waiting time until you will be called by the next DMV agent. You then commence waiting until your number is announced and you can complete your business.
That little bit of information, the estimated wait time, is the aspect of the DMV experience that I think has tons of potential for in other areas, most notably in Email communications. The DMV estimates your wait time, (I imagine), in a really simplistic manner. It is a function of the number of customers waiting ahead of you, the number of DMV agents available, and the average transaction time for each customer to be served. Simple math, and probably is pretty accurate most of the time.
The Email version of the 'Estimated Wait Time' function would be used to auto-reply to every (or selected) incoming email messages with a 'Estimated Response Time' that would provide the emailer with information about how long they should expect to wait before receiving a reply.
How would this work, i.e., what would the 'Estimated Response Time' algorithm need to take into account? Probably, and at least the following data points.
1. The relationship between the sender and the recipient - how frequently emails are exchanged, how recent was the last exchange, and what has been the typical response time to this sender in the past
2. The volume of email needing action/reply in the recipient's inbox at the time the email is received, and how that volume level has impacted response times in the past
3. The recipient's calendar appointments (most email and calendar services are shared/linked), for the next 1, 3, 12, 24, etc. hours. Is the recipient in meetings all day? Going on vacation tomorrow? About to get on a cross-country flight in two hours?
4. The subject matter of the email, (parsed for keywords, topics mentioned in the message, attachments, etc.)
5. Whether the recipient is in the 'To' field or in the 'CC' field, whether there are other people in the 'To' and 'CC' fields, and the relationship of the recipient to anyone else receiving the email
And probably a few more data points I am not smart enough to think of in the 20 minutes or so I have been writing this.
The point?
That a smart algorithm, even a 'dumb' one like at the DMV, could go a long way to help manage communications, workflow, and to properly set expectations. When you send someone an email you (usually) have no idea how many other emails they just received that hour, what their schedule looks like, the looming deadlines they might be facing, and the 12,458 other things that might influence when/if they can respond to your message. But with enough data, and the ability to learn over time, the 'Expected Response Time' algorithm would let you know as a sender what you really need to know: whether and when you might hear back.
Let's just hope once the algorithm is in place, we all don't get too many "Expected Response Time = NEVER" replies.
Now please Google, or Microsoft, or IBM get to work on this.