I’ve always been in favor of addressing email overload from an enterprise point of view instead of just appealing to individual etiquette and time management. An example of that is when a slew of seemingly one-off emails is revealed to be a repeatable process that may be worthy of automation. What would be treated as a time management problem at the individual level is seen as an automation problem when viewed from the enterprise level. Luckily an example popped into my inbox this morning to illustrate my point.
Actually, not one email, but half a dozen in the thread, sent to a mailing list of ~90 people. It started with a simple question about whether anyone was attending a certain major vendor’s conference. As one respondent in the thread helpfully calculated:
In the future, please contact only the people that are likely to attend the conference in question. We probably have over 200 people with clients that attend their conferences. If each client attends 5 of their conferences a year, that’s 1000+ emails going to the 88 members of the distribution list. And if it takes each person 30 seconds to respond to the email, that’s over 88,000 minutes, or 30+ days of our time.
While the author labels this as an etiquette problem assuming the use of email to be constant (“please contact only the people that are likely to attend”), I see this as clear identification of a repeatable process. This vendor has several conferences, there are 88 people who might have to email up to 200 clients and aggregate results. And this occurs for multiple vendors. Rather than appealing to etiquette and time management, an organization should be trained to recognize cases where productivity automation could help and know the tools and/or people to get that done. Eliminating several emails, several times a year, for hundreds of people in one fell swoop of automation is certainly worth a little systematic attention.
Unfortunately, many non-IT users lack the tools or skills to automate their repeatable information-centric processes. And, annoying as these processes are, they usually fly below the threshold of IT to treat them as a project. One approach some organizations use is to have an end user enablement group in IT (or, rarely, in the business) that works with anyone in the business to apply end-user development tools for simple automation tasks. These could be folks on a SharePoint team that has open office hours, or another technology such as Notes/Connections, workflow, wikis, portals, or Office developers that can create macros/VBA to automate Excel and Word. These IT helpers are usually entry level (or close to it) and the work helps them learn quickly about many parts of the organization. I did work like this in my internship during college, using FoxPro (I’m dating myself here) or VBA to automate administrative tasks that previously had no technical assistance like the project proposal process and tracking org chart changes.
Now to delete all the emails in that thread and start my work day. I’m not going to the conference.