Shared mailboxes in Exchange Server and Exchange Online are a great way for a team of your users to share the workload of reading and responding to emails. Shared mailboxes are often used in customer service scenarios, whether that be internal customer service (such as Payroll or Human Resources matters), or external customer service (such as providing service and support to buyers of your products).
Although shared mailboxes provide a basic, single point of contact for customer service, they’re not well suited to any situation that requires one of more of the following:
- tracking of individual cases (e.g. by assigning ticket numbers)
- tracking against SLAs or response targets (e.g. time to answer, time to close)
- task assignments (e.g. to avoid duplicating effort, or to assign to specialists)
- easy access to historical correspondence (e.g. looking up previous support requests from a customer)
- communications between support team members (e.g. adding notes for others to understand the context of a ticket)
- integration with knowledge bases (e.g. keywords in customer requests surfacing existing KB information)
- workflows and business rules (e.g. routing requests through multi-stage processes for resolution)
- any type of reporting (e.g. number of tickets received vs closed per day/week/month)
- mobile access (a long-standing pain point for Exchange shared mailboxes)
Those features, and many others that are common to support scenarios, are not natively available in Exchange mailboxes. While it’s quite normal for an organization to initiate a basic customer support model using a shared mailbox, it’s also quite normal to quickly outgrow the limitations of shared mailboxes. Even a small organization with a single IT support person can struggle with managing cases through a basic helpdesk@company.com shared mailbox.
I see a lot of questions in forums, especially from IT pros, and also field a lot of questions from customers about how they can achieve any of the above features for their shared support mailboxes. And while it’s true that almost anything is possible in the world of technology, I generally advise to use a service like Zendesk, Help Scout, or SupportBee instead of trying to DIY a solution with custom scripts or other bits and pieces. Pretty much any of those three services, or one of the many others that are available on the market today, will do the job better than any custom script you throw at the problem. You’ll be happier using a service that is designed to provide those required features, and your customers will get better support as well. It’s win-win.
But there are a few things to consider. Integration with third party SaaS is a common approach these days, but not all SaaS is equal. At the most basic level you should consider how your support users will be logging in to the system. The Azure marketplace helps you to identify SaaS applications that support Azure AD identities for SSO. Your sales team might also like to ensure that your support application integrates with their CRM, so that they can check a customer’s latest support interactions before they call them to avoid surprises. Similarly, it’s helpful for support agents to understand who a customer is when they’re handling a ticket (all customers are treated equally, but some are treated more equally than others).
There are also general cloud service considerations, the same ones you’ve likely applied to your decisions about utilizing Office 365 services. For example, data sovereignty, compliance with industry regulations for privacy and personal data, encryption and general security of your customer data, auditing, retention/preservation, and so on. Those are all issues that will be specific to your organization, which is why I am only making general recommendations in this article.
For integration, you should look at whether the SaaS application needs access to an Exchange mailbox to ingest customer support emails, e.g. via EWS, IMAP, or POP. Some systems work by utilizing a forwarding email address instead, removing the need for access to your Exchange servers. The SaaS application also needs to be able to send email back to customers (e.g. to let them know their ticket number, and update them on the status of their request). If it will be sending email using your domain name, then SPF configuration needs to be taken into consideration as well. Alternatively, running the SaaS application on a separate email domain (e.g. @support.company.com) can simplify the SPF configuration by separating it from your primary email domain.
But the main point that I’m making here is that shared mailboxes are not a good solution for anything but the most basic support scenarios. Hopefully you’re able to use the guidance in this article to convince your organization to invest in proper support tools that will benefit both you and the customers that you serve.
Our support emails are currently set up as shared inboxes. We are looking to move one team to Freshdesk but they say they do not recommend the use of shared inboxes.
What would you say is the best workaround with minimum disruption for staff and customers?
Thanks
I’m struggling with this exact problem. I’m a new team lead who has inherited a support model that is rife with duplication of support issues and requests. The team uses a shared inbox, a whiteboard and various excel/word docs to track and manage support requests/issues.
These issues then need to get escalated to IT and system vendors.
The thing I see as the biggest downfall (apart from duplication) is that there is no method of capturing updates and sharing these with the team (unless in a face to face meeting).
The team has tried using a shared inbox, but it has ballooned out to about 20 sub folders. They have tried colour coding the emails to identify who the email request is being actioned by – but it gets messy and this mess compounds.
We’re essentially acting as a middle man, and the shared inbox doesn’t work very well.
I’ve been thinking about using Sharepoint and PowerApps Help Desk template, but don’t want to introduce ‘another thing’.
Tricky situation, but it can’t carry on like it is!
Have you looked at a free solution like Spiceworks for helpdesk? It seems like it will take care of most of your pain points:
* No duplication
* Updates are recorded with the ticket so everyone can see it in the portal
* Most/all of your 20 sub-folders can probably be used as tags to give more information without causing folder bloat
We are facing the same issue and trying to move from a shared mailbox to a better helpdesk system. Only thing I cannot find is the following. How do you integrate for example something like zendesk with an external helpdesk of your infrastructure provider.
So for example:
* Internal user sends an email to itsupport@ourdomain.com
* This gets auto forwarded to the helpdesk system of our choice where a ticket is created.
* Internal IT person looks at the ticket and sees, hmm thats something for our infrastructure provider
Now I am a bit puzzled how to solve it nicely.
* Internal IT person sends an email from the itsupport@ourdomain.com address to itexternal@thirdparty.com
* external it system comes back with an email “Hey we created your ticket”
* This ticket gets picked up by the helpdesk system and creates an internal ticket again?
So in an ideal world, would be nice you can easily create and communicate with your external provider using your chose helpdesk system. Would you have any thoughts how to tackle this or which helpdesk systems would work well in this way?
The nice thing about the shared inbox scenario is that this is quite easily done by just using email?
Thanks!
The Real Person!
The Real Person!
Yes, usually you’d just escalate to the third party, have them log a ticket, and then cross-reference that in your own ticketing system.
To stop the replies getting turning into a new ticket, either send from a different address, or have an exception set up in your help desk system to not auto-log tickets for emails from that third party. Or a wider exception that says don’t auto-log tickets unless sender domain is @yourcompany.com.
Great article, this issue is most common overlooked by the companies and causes major headaches for the support personnel.
Our organization is mired in using Shared Mailboxes with complicated MANUAL workflows! Large numbers of users manipulating items at the same time has left us in a configuration of ‘live’ shared mailboxes, because caching them was causing issues due to their use. But live mode has it’s own performance hit…
The Real Person!
The Real Person!
Sorry to hear that. Perhaps one of your more ambitious teams can move to a proper platform and then be cheerleaders/advocates for the other teams to follow once they see how much better life can be.
Excellent answer go a problem that most IT departments do not always consider.
The Real Person!
The Real Person!
So many… sooo so many