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 user’s email accounts, it is normal to give every user their own account, and when email arrives into the account it is stored in the 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.
A partial solution to this was to set a generic group email address, for example “email@example.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.
Although this works, it suffers from the fact that every email sent to the generic email address is needlessly duplicated. And duplication often causes problems because there is the potential for several versions of the same message to exist. Furthermore, if an employee responds to an email sent to the generic address, then the response will come from the employee, not the “group”, and the other members of the group will not necessarily know. It might well create a new thread, private to the first person in the group that responded.
An alternative, less confusing solution is to create email accounts specifically for shared use. These are exactly the same as the “group aliases” except they have their own inbox. To make these emails visible to authorised users, they simply add the account to their own email client. That way all the emails for “firstname.lastname@example.org” are nicely stored together without the need for duplication and possible tampering. Furthermore, responses will come from “email@example.com” and will be visible to all authorised users. Last but not least, a further benefit is that shared accounts can be added to and remove from user email apps without the need to involve a system administrator.
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?
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 companies. 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.
shared inbox, bcc