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.
The post Using Exchange Shared Mailboxes for Help Desk and Customer Service Scenarios appeared first on Practical 365.
