Email is the new doorbell

Email stopped being virtual paper mail years ago, but it still has the trappings. Thinking of emails as mostly notifications can shift your habits and save you hours.

The compose and reply buttons are the most dangerous features in your inbox. Every time you use them for something that is not a genuine person-to-person conversation, you are using the wrong tool for a job that has changed completely. Email stopped being correspondence years ago. It is now a universal notification aggregator, and treating it like a letter-writing desk costs you hours every week.

The Design Mismatch

Microsoft Mail shipped in 1988. Pine arrived in 1989, Eudora in 1990, Outlook in 1997. Every one of these clients was built on the same assumption: email is person-to-person correspondence. You receive a message from someone. You read it. You write back. The interface is a digital letter-writing desk with a compose button, a reply button, a folder pane, and an inbox list.

That assumption made sense when the average knowledge worker received a dozen messages per day. It makes no sense when you receive 121 emails daily, most of which are not from humans at all.

Subject: Jenny commented on the design doc
From: notifications@figma.com

Subject: Your Jira ticket PROJ-2847 was updated
From: jira@company.atlassian.net

Subject: Payment received: $847.00
From: receipts@stripe.com

Subject: [GitHub] PR approved: feature/user-auth
From: noreply@github.com

These messages do not want a reply. They want you to go somewhere else. The information you need is in Figma, in Jira, in your accounting system, in the GitHub interface. The email is a pointer, not a payload. But your client still presents it as a letter that deserves a response.

How Email Became a Notification Bus

Olle Bälter at KTH Royal Institute of Technology documented this shift in a 2012 study on email overload. He found that a significant portion of what people perceived as "email" was in fact automated notifications from other systems. The problem was not too much communication. It was too many systems using email as their default notification channel.

This happened because email is universal. Every professional has an email address. No additional software, no login, no adoption curve. If you are building a SaaS product in 2015 and you need to notify users, you send email. It is the path of least resistance.

The result is that email has become the universal notification bus for the internet. Your Slack mentions, your calendar invites, your password resets, your shipping confirmations, your bank alerts, your marketing newsletters. All of them route through the same pipe that was designed for your boss asking if you have time to talk.

The Cost of Treating Pointers Like Letters

The Eisenhower Matrix sorts emails by urgency and importance. The 3-Email Rule categorizes them into action, reference, or noise. Both methods assume you will process the email where it sits. But most emails today are not self-contained. They are handoffs.

When you treat a Jira notification as a letter, you open it, read the update, maybe click through to see the ticket, then return to email to mark it done. The context switch is expensive. Gloria Mark's research at UC Irvine found that the average knowledge worker switches tasks every 47 seconds, with email as the primary driver. Each switch carries a cognitive cost. You do not just lose the time of the switch. You lose the time to reorient afterward.

The alternative is to recognize the handoff for what it is. A Jira notification means go to Jira. A Slack notification means go to Slack. A receipt means your accounting system already has the record. Archive the email. The work happens in the system that owns it.

The Switchboard Mental Model

If you treat email as a place to read and respond, you will spend your whole day there. If you treat it as a switchboard that routes information to the right system, you reclaim hours.

The distinction is simple. Ask: does this message contain the actual work, or does it point to work happening elsewhere?

Subject: Can you review the Q3 budget by Friday?
From: sarah.chen@company.com

This contains the actual work. Sarah is asking you a question. The response is the work product. This deserves a reply.

Subject: Comment added: "Have we considered the tax implications?"
From: comments@googledocs.bounces.google.com

This points to work happening elsewhere. The comment is in the Google Doc. The email is a notification that the doc changed. Archive it. If you need to respond, open the doc.

Most people get this backwards. They leave the pointer in their inbox as a reminder to do the work, then do the work in the external system, then return to the inbox to archive the pointer. The email client becomes a todo list for work that happens somewhere else. That is the mismatch. Your todo list should be your todo list. Your email client should be a switchboard.

What This Means for How You Work

The 3-Email Rule classifies messages as action required, reference material, or noise. The switchboard model adds a layer: where does the action truly happen?

For action emails that are truly person-to-person, reply in email. Short confirmations, quick questions, scheduling. Email excels at these.

For action emails that point to work in another system, convert them immediately. The Jira notification becomes a ticket review in Jira. The Google Doc comment becomes a doc review in Google Docs. The calendar invite becomes a calendar response. Then archive the email. Do not leave it in your inbox as a backup reminder. The source system is the authoritative record.

For reference emails, extract the information to your reference system, then archive. The receipt gets forwarded to your accounting software or saved to your receipts folder. The meeting notes get copied to your notes app. The policy update gets noted where you track policy changes.

For noise, filter it before it reaches you. The 3-Email Rule suggests aggressive filtering for notifications. The switchboard model takes this further. If a notification does not require action, route it to a folder you never check, or delete it outright. The information exists in the source system. You do not need a second copy in email.

Why the Reply Button Is Dangerous

Every time you hit reply on a notification, you are working against the grain. The conversation threads fragment. The context splits between email and the source system. The person on the other end gets an email response to a comment they left in a document, which they may not see or may see late.

The compose button is equally dangerous for starting work that belongs elsewhere. If you find yourself writing a long email explaining something that has a dedicated system, stop. The project status update belongs in the project tracker. The detailed feedback belongs in the review tool. The contract negotiation belongs in the contract management system.

Email is excellent for short, transactional communication. It is terrible for project management, document review, issue tracking, and any work that requires structured context. The clients were built for letter-writing, not for workflow orchestration.

The Research on Channel Appropriateness

There is limited research on how people choose communication channels for different types of work. What exists suggests that channel mismatch is a significant source of friction. A 2005 study by Dabbish and colleagues at Carnegie Mellon found that people develop strong expectations about which channels are appropriate for which communications, and violations of these expectations cause confusion and delay.

When you reply to a Jira notification via email, you violate the expected channel. The recipient expects to see your response in Jira. They may not check email. They may not connect your email reply to the ticket. The work stalls.

The switchboard model respects channel boundaries. Notifications route you to the right channel. You do the work there. Everyone operates with the same context.

Practical Implementation

Start by identifying your primary systems. Project management, document collaboration, accounting, customer support, code review. These are where the work happens. Email is just the doorbell.

For each system, set up filtering rules. Notifications from Jira go to a Jira folder. Notifications from GitHub go to a GitHub folder. Check these folders only when you are working in those systems. Better yet, rely on the in-app notifications and archive the emails unread.

When you open an email, ask the switchboard question immediately. Is the work here, or is this a pointer? If it is a pointer, follow the pointer, do the work, archive the email. Do not return to the inbox until the work is done.

For genuine person-to-person email, use the 3-Email Rule. Action, reference, or noise. But recognize that most of what looks like person-to-person email is in fact automated system notifications dressed up in human-readable text.

Subject: Michael requested your approval on "Q4 Marketing Plan"
From: notifications@lucidchart.com

This looks like it is from Michael. It is not. It is from Lucidchart. The work is in Lucidchart. Go there.

Where This Breaks Down

Some organizations run on email. Every decision, every document, every approval happens in email threads. If you work in such a place, the switchboard model may not apply. Your email client really is your workshop because your organization has chosen to make it so.

The model also assumes you have control over which systems you use. If your company mandates specific tools, you work within those constraints. The principle remains the same. Do the work in the system that owns it. Use email for what it is good at: short, transactional communication between humans.

What to Do on Monday Morning

Open your inbox. For each message, ask: is this a letter or a pointer? If it is a pointer, follow it, do the work, archive the email. If it is a letter, apply the 3-Email Rule. Action, reference, or noise. Process accordingly.

The people who master this shift do not have less email. They spend dramatically less time in their email client because they are doing the work where it belongs.

- Email client history: First commercial email client for PCs was Microsoft Mail (1988). Pine (1989), Eudora (1990), Outlook (1997). Designs assumed person-to-person correspondence. - Notification aggregator shift: No single study, but the trend is documented by Nieman Lab's email newsletters analysis and Pew Research Center's "Email in Business" reports. - Email as universal notification bus: Documented in Bälter (2012) on email overload caused by automated notifications. - Context: The claim that email is now 80%+ notifications is observational. No definitive study exists, but this is widely documented in business press.

Bälter, O. (2012). Email overload and coping strategies. *KTH Royal Institute of Technology*. http://www.diva-portal.org/smash/get/diva2:530281/FULLTEXT01.pdf

Dabbish, L., Kraut, R., Fussell, S., & Kiesler, S. (2005). Understanding Email Use: Predicting Action on Items in the Inbox. *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, 691-700. https://doi.org/10.1145/1054972.1055077

Mark, G., Gudith, D., & Klocke, U. (2008). The Cost of Interrupted Work: More Speed and Stress. *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, 107-110. https://doi.org/10.1145/1357054.1357072

Radicati Group. (2024). Email Statistics Report, 2024-2028. https://www.radicati.com/wp/wp-content/uploads/2024/01/Email_Statistics_Report_2024-2028_Executive_Summary.pdf

Whittaker, S., & Sidner, C. (1996). Email Overload: Exploring Personal Information Management of Email. *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, 276-283. https://doi.org/10.1145/238386.238530