If you work for a company where collaboration is important – and tell me one where it is isn’t – you may have come across the idea of a so-called “shared inbox”. However, it is just as important to understand that a “shared inbox” is not the same as “sharing an inbox”, so let me explain.
When an email server is set up with users’ email accounts, it is normal to give every user their own account, and when an email arrives it is stored in the appropriate user’s inbox.
This is all well and good but user accounts are the enemy of collaboration. In the old days, when steel filing cabinets existed, correspondence would be stored in customer files and anyone with access to the file could see the correspondence. Once email became the de-facto standard for communication, correspondence often became locked inside private email accounts because the sender would, not unreasonably, address the recipient individually by name.
What Started it All
A partial solution to this was to set a generic group email address, for example, “sales@company.com” to which several employees could be subscribed. Whenever an email arrived with this generic email address, it would automatically be copied to all employees in the group. This is what is often termed as a shared inbox. In fact, this is not a good description because there is no inbox at all, just a common alias for all the designated recipients.
A Solution
It would be nice to be able to definitively distinguish how inboxes are shared in popular email servers such as Microsoft Outlook, Office365, and Google Mail, unfortunately, however, there is no common consensus in the use of the term Shared Inbox. Indeed, Microsoft actually changed the way Outlook handled shared inboxes in 2013. This is nothing uncommon for mail servers. Google Mail describes the copying of emails from one email account to another as forwarding, whereas it is generally accepted that forwarding (the term does not actually appear to be defined in any RFC document) would change the email headers so it was clear from which account the email had been forwarded. This too can lead to confusion – but who is going to argue with Google?
How Can Threads Help?
The Threads Message Hub effectively aggregates any number of disparate email accounts into a single list view. Although that sounds like the recipe for disaster, it is quite the opposite. Because messages are automatically grouped by companies and users, it is immediately evident where there is a thread of communication between several individuals in an external company. This would not be evident from a user’s own inbox when most users see their messages in the context of other employees they often describe it as a revelation.
With Threads, it becomes unnecessary to create shared inboxes because that is precisely what Threads is. However, there is still a lot to be gained by creating dedicated “user” accounts for different areas of the business – eg orders, support, enquiries – and including those “users” as authorised Threads users.
If you don’t like the idea of shared inboxes, be they managed by one email server or by other means such as Threads, the last option is to “cc” (carbon copy) everyone ever likely to be involved. This, sadly, is still a common practice and probably responsible for most of the spam you ever get. If you must share email by copying in every possible interested party, then use “bcc” (blind carbon copy). That way you will not be feeding the viruses designed to cull email addresses for spammers that statistically, 32% of recipients will have on their computers.
However you share your email, it pays to understand what is going on.