Case Deflection
We all know about Case Deflection. As a refresher, Case Deflection is a set tools and processes that are put in place to enable clients to resolve their own issues. This self-service approach can include assisted support (even AI assisted support more recently), a citizen community, knowledge articles and so much more. Essentially, anything that prevents the need to open a case with support can fall under the Case Deflection umbrella.
Regardless of the tool and processes, the end goals are the same:
- Resolve client issues faster
- Improve agent productivity
And that productivity can directly hit the bottom line. In organizations dedicated to constant case deflection improvements, you often see metrics such as “Cost to Touch”. We recently engaged with a client that even calculated “Cost to Re-evaluate” (the hidden cost incurred when a case cannot immediate be worked, due to incorrect assignments, poor refinement, etc.)
It’s interesting, in these examples, to see constant improvements applied to multiple support channels… yet time and time again we see one support channel neglected…. Email-to-Case.
Email-to-Case Neglect
Email-to-Case is a great tool. But it does not provide a lot of configuration options.
A basic Email-to-Case configuration typically includes a routing email address pointing to a support email (such as [email protected]), some default settings (such as case record type and priority) and some decisions on how to deal with email attachments. And that’s about it. Once activated, the process will process emails into cases.
There are more options on the back end (after the case has been created) such as:
- Run the case through assignment rules
- Send a confirmation email
- enrich/fix the data with triggers and/or flow by correctly setting data such as:
- record type
- status
- priority
- product data
But these processes all run AFTER the case has been created. This can cause issues with SLA, notifications, Round Robin assignment calculations, and more.
Here at Sproket Logic, we recommend evaluating and enriching email data BEFORE the case is event created. More precisely, we recommend a process we call Email-to-Flow Redirection.
Email-to-Flow Redirection
Email-to-Flow Redirection is the process of enriching and evaluating incoming email message (via our flow based AppExchange solution Email-to-Flow), to make direction decisions prior to populating any data in the Salesforce instance.
Every Salesforce implementation is unique. As such, every Email-to-Flow Redirection approach is unique. We built Email-to-Flow to be as flexible as possible. In addition to leveraging the power of Flow, the app comes baked with a number of Apex Actions (more added every day).
Need some ideas? Here are a few of recent Email-to-Flow Redirection solutions we helped build.
Example 1: The Thank You Dilemma
Use Case
When a support ticket is closed, the client is notified via email. Some clients respond to the ticket with a thank you message. When a client responds to the closed email message, the support ticket is reopened. Support agents waste time evaluating the ticket and reclosing the ticket.
Email-to-Flow Redirection
With Email-to-Flow, we have the ability to enrich and evaluate incoming emails BEFORE creating data in the Salesforce instance. As such, we can take appropriate action.
In this specific use case, the client implemented a solution, via Email-to-Flow, to block the email. Instead of accepting the email, the user was sent a reply email indicating that their email was blocked. The email further explained additional steps to reopen the case (in the event it was not a thank you email).
Of course, there are many additional options available for this use case:
- Accept the email and update the case status
- Accept the email and create a new case
- Simply reject the email
- Reject the email with additional instructions
- Accept the email and assign it to a triage queue
With Email-to-Flow, you can roll your own.
Example 2: The Unknown Contact
Use Case
Only existing contacts should be allowed to submit an email to generate a case.
Email-to-Flow Redirection
With Email-to-Flow, we have the ability to enrich and evaluate incoming emails BEFORE creating data in the Salesforce instance. As such, we can take appropriate action.
In this specific use case, the client implemented a straight-forward solution, via Email-to-Flow, to block the email. Instead of accepting the email, the user was sent a reply email indicating new steps to register as a valid user
Of course, there are many additional options available for this use case:
- Accept the email and create a contact records
- Accept the email, send an email with additional instructions, and create the case in a probationary status
- Accept the email and assign it to an appropriate case queue.
With Email-to-Flow, you can roll your own.
Example 3: Data Based Assignments
Use Case
Route cases based on email attachments
Email-to-Flow Redirection
With Email-to-Flow, we have the ability to enrich and evaluate incoming emails BEFORE creating data in the Salesforce instance. As such, we can take appropriate action.
In this specific use case, the client submitted documentation via the email-to-case process. Prior to implementing Email-to-Flow, cases were assigned to a triage queue. The support agents reviewed the documentation and assigned it to the correct queue. With Email-to-Flow, we implemented a basic OCR (Optical Character Recognition) process to retrieve documentation IDs. Cases were assigned to the appropriate team based on those IDs. (Of course, we compressed the files to save on file storage and removed annoying email signatures to reduce clutter as well… but that’s for another blog post.
Of course, there are many additional options available for this use case:
- Implement an IDP (Intelligent Document Processing) integration to extract data from the documents submitted
With Email-to-Flow, you can roll your own.
Have your own use case?
Have a use case you’d like to discuss? Give us a ping.