Unorthodox Salesforce Email-to-Case

Email-to-Case is not a sexy, new Chatter style feature of Salesforce, yet is a keystone for business success. For many customer service teams, it is critical to how companies interact with their client base, and acts as the pipeline to the all-powerful Case object in Salesforce. Recently I had the pleasure of using Cases and Email-to-Case in an unorthodox way, and it may inspire readers to consider alternative uses for declarative functionality to solve interesting business problems.

The Problem: What and Why

A client prompted me with an interesting question: how do we log a large volume of important emails to Salesforce with little effort? These emails were sent to a distribution list by their customers, and all of the emails needed to be captured, and associated to the appropriate contact and account record. With more exploration, each customer was requested to send information periodically to the email distribution list, and emails often would contain attachments. The content of the emails was not part of a daily interaction between a client team member and the customer, but instead an important update that needed to be logged and reviewed.

Why not Email to Salesforce, Salesforce for Outlook?

Breaking down the problem, there are key phrases that I found interesting: large volume, important, little effort. Let’s take a look at the following ways to get data into Salesforce in some fashion:

• Email-to-Salesforce (E2S): requires user action, potential for missing an email or duplicate emails logged
• Salesforce for Outlook (S4O): same functionality as Email to Salesforce
• Apex email service: can be pricey for some clients, and many considerations for long-term maintenance

Both Email to Salesforce and Salesforce for Outlook can log to tasks, and the idea of intermingling normal user interactions with customers (i.e. standard emails) with these important customer responses was suboptimal. Salesforce for Outlook can handle creation of cases by piggy-backing on Email-to-Case, which led me to think that Cases was the optimal declarative-based solution.

Rebranding cases, Email-to-Case

Cases have a ton of great functionality built in, namely Email-to-Case and assignment rules, we were able to solve our problem. The first step was to strip down Cases to the bare essentials: relationship to account and contact, a status, subject, and description. Next is to determine where and how these cases are created; our client had two email aliases, one for prospects and one for customers. By creating two Email-to-Case setups, we were able to handle both sets of cases, and typify them appropriately based on origin, which in turn drove business logic.

A few emails would originate from a contact that was not logged in Salesforce, thus creating orphan case records. To minimize user effort we used workflow rules to determine if the Contact Name field was populated, and if so automatically close the case. All orphaned emails were visible through list views, email alerts, and scheduled reports. The results were astonishing: the client was able to handle hundreds of inbound emails automatically with approximately a 10% orphan rate. Most orphans were typically caused by a new email address, which is easily solved by creating a contact record once.

By thinking about a problem and expanding the scope on potential platform features that could be a potential solution, we were able to deliver a process that satisfied client requirements and did not require AppExchange apps or custom code.

Have you ever used Email-to-Case or Cases in an atypical way? I’d love to hear about it, either via Twitter @RogerMitchell, via Disqus below, or on our Facebook page.