Key Criteria for Evaluating Shared Inbox Appsv1.0

1. Summary

Companies need to communicate with customers and prospects; historically that communication was often email based. But email, as it is generally supported — inl platforms from Google and Microsoft — is organized around unshared email. In many functional areas — like customer support, marketing, accounting, and IT — companies are better off if they can avoid the mess of forwarded emails, broken cc: chains, and other techniques that do a poor job of sharing email. Starting a few years ago, software developers began to build better approaches to sharing email and related customer information around the model of shared inboxes, based on email addresses like support@xyz.com where emails are synced and shared among team members instead of forwarded. This report profiles many of the leading vendors in this work technology niche.

Shared Inbox = Email-First Customer Communications

A Key Criteria report analyzes the most important features of a technology category to understand how they impact an enterprise and its IT organization. Features are grouped into three categories:

1. Table Stakes
2. Key Criteria
3. Near-term Game-changing Technology

The goal is to help organizations evaluate capabilities and build a mid-to-long-term infrastructure strategy. In a mature technology, the solutions are divided into three target market categories: enterprise, high-performance, and specialized. In a mature market, these differ in their characteristics and how they can be integrated with existing infrastructures. Given that, the evaluation is more dependent on the specific user’s needs and not solely on the organization’s vertical market.

Email and Chat: Operating at Two Tempos

The single most important idea in shared inbox tools is that an email — for example, a request for information or a demo sent to sales@xyzcorp.com — is routed to the social inbox tool as an email object. The members of the sales team can view the email and chat about the subject matter.

So, the email acts as a trigger for action within the organization or team sharing the inbox, which can lead to chat-style messaging among the team.

These are the two tempos: email is sent with the expectation of an asynchronous and possibly slow pace of response, such as a day or two. Meanwhile, within the team receiving the email, the communication is much faster and possibly synchronous: chat. This is shown in the screenshot below, with the email from a customer shown at the top, and the chat between coworkers at the bottom.

Two Architectures

There are two approaches taken in the building of shared inbox tools:

• integrations with existing email clients (like Gmail and Microsoft Office 365) — these have a number of benefits, such as support for other plug-ins and leveraging the scale and reliability of major players.
• standalone email clients (like the example above, from Front) — these can sidestep decisions made in the original tool that might work counter to the needs of shared inbox teams.

The Baseline Use Case

The baseline use case is customer support. An on-line commerce company or software manufacturer wants to be able to handle an incoming stream of customer requests about orders, software bugs, or billing questions, and they may start with a shared account (in say, Gmail), associated with support@adjectivenoun.com. But quickly they run into some of the limitations of a non-shared implementation:

• multiple team members may access the same email and initiate multiple conversations with the customer, causing confusion
• team members may forward customer request emails to other team members asking for assistance, and that ‘pending’ status is not indicated anywhere
• email clients like Gmail do not have a good mechanism for sharing notes, or contact information, so that has to be managed in another context, like a CRM tool

Unsurprisingly, when given the option to use a real shared inbox app, most will transition.

Shared inbox apps differ in the capabilities they offer, but most support these capabilities:

• creation of shared inboxes with actual email addresses, like support@adjectivenoun.com, and giving access to a list of team members
• a chat-like means to communicate among team members while viewing an email (or set of emails)
• a means to create persistent notes regarding specific email cases or customers
• a collection of prepared answers to queries that can be directed to customers as emails or within emails
• the ability to hand off a particular email case to a coworker, like an administrator, payment clerk, or engineer
• assigning a status to a case, such as pending or completed (note that in many cases, these status changes are managed by the system itself)

Of course, there are other use cases, and other scenarios that the vendors have aligned their solutions to match, but this is a good starting point.

These are the dimensions we will use to understand and evaluate shared inbox solutions:

• Standalone or Integrated email client — Is the shared inbox app a standalone app or an integration with email platforms from Google and/or Microsoft? Both types have their pros and cons. As one example, a company may have other services integrated with Gmail that they wish to use on a regular basis which they might have to drop if switching to a standalone shared inbox tool. On the other hand, a standalone app might offer capabilities that are not available or are overly difficult in an integration with Gmail or Outlook.
• Interaction — Central to shared inbox is the interaction with customers through email communications, and perhaps other mechanisms, and chat-link interaction with coworkers.
• Visualization — Is the design of the tool intuitive? Does it provide useful ways to see the process associated with receiving and responding to customer interactions?
• Case management — These solutions generally provide a means to see the cases being handled, and to filter by date, customer, team member assigned, status, and so on. As companies scale, they develop the need for defined roles and access permissions, so that finer-grained controls over data can be managed.
• Reports and Analytics — Various reports that collate case information in useful ways, to help understand productivity and problems, based on gathering underlying analytics.
• Mobility — What mobile solutions are offered?
• Automation — Are any aspects of customer interaction automated, such as routing based on roles, rules, and other information gleaned from the customer email or other customer-related information, like customer categorization?
• Integrations — In-context integrations with external tools, like CRM, help desk, work management, and document management solutions. The classic example is pulling up the customer’s information from a CRM solution in a widget when looking at an email. Another common integration is posting notifications from a shared inbox tool to defined channels in Slack.