Support Emails to a Support Form — Moving from Email-to-Case to Web-to-Case

The Context:

Most companies nowadays have a support email address that you can reach out to when you need some help, and typically, it’s how startups first set up a support channel for their clients. It works well at the start, but over time, as your company, client base, and the complexity of your services all grow, managing support through email becomes a problem. Support reps spend a lot of time asking the basic questions over and over again — please confirm your business address, the specific issue you’re having, what part of the service is being affected, etc. Because of the nature of Salesforce email-to-case, you’ll also have a lot of duplicate cases — clients will email the support address to check in on cases they’ve opened previously, but because they don’t respond to the thread that they had previously created, Salesforce will open a new case. This could get assigned out as normal and will ultimately confuse both the support team and the client. You probably also get emails from clients that read: “it’s broken.” Obviously that’s not useful for your team to begin to help.

As companies scale, all of the above starts to happen hundreds of times per day. Bad news.

There’s an additional challenge, too. A lot of support departments will use Salesforce’s ability to send emails directly from case records. This is a great tool — it allows support agents to easily reach clients from a company support address and ensures that emails are being logged — but if you’re trying to transition away from email-to-case and you want to continue to be able to email from the case, we’re left with a problem. How can you prevent incoming emails from creating new cases while also making sure that clients responding to emails coming out of Salesforce reach your sales team?

The Plan:

Transition away from email-to-case to a webform that gathers the basic information we had to ask anyone anyways. Prevent new incoming support emails from creating cases, send an auto-response to the client informing them of the change and directing them to the form, without removing your general support email from Salesforce or removing the ability for support agents to send emails to clients directly from case records.

This means:

1. Create webform

   1. gathers information

   2. creates a case in SF

   3. puts that case in a specific queue

2. Auto-response on new incoming emails to old support email address

   1. inform whoever emailed that support process is changed and that a case wasn’t created

   2. direct them to the form

3. Immediately delete the case that’s created when a new email hits the support email address

Now, new cases have all the basic information we need. Support reps won’t spend time asking the same questions over and over again. No more duplicate cases, because if an email came in that wasn’t associated with a case, it wouldn’t create a new one.

This also creates a higher bar for someone to submit a support case — it’s harder for a client to create a support case. Internally, there can be some pushback here. Companies always want it to be easy for their clients to receive support. Let’s take a second and focus on what’s really important, which is fixing the client’s problem, not making it easy for them to open a case. Ultimately, whatever business you’re in, making sure you’re serving the client is the most important thing, and if asking the client for 3 minutes of time on the front end is going to save your team 24 hours on back-and-forth to confirm details, it’s a win for you and your clients. You can resolve their issues faster which keeps them happier.

The Setup:

First, creating the webform. This is easy.

Identify what pieces of information you want to collect up front from the client. For example:

1. Name

2. Email

3. Phone number

4. Business Name

5. Business address (street, city, state, zip, in individual fields)

6. Subject of issue

7. Detailed description of issue

8. Part of our service that’s affected

9. Are you following up on a previous case?

Create custom fields for all that information in the case object. Add those fields in a section on the page layout of your case, say, “Web-to-Case Details” with all the fields from the webform.

Create the webform using the out-of-the-box “Web-to-Case HTML Generator.” Add the fields to the form. Uncheck “Available in self-service portal” and “Include reCAPTCHA,” unless you’d like to use those tools. Create a “submission successful” page on your website (or wherever you’re putting this support form) and put that link under “Enter the URL that the user will be returned to.” Click on “Generate.”

You’ll get a bunch of HTML. An important change — make all these fields required. You don’t have to do this, but the whole point here is to create a standard that’s followed every time. The HTML for each field will look something like this:

<label for="email">Email</label><input id="email" maxlength="80" name="email" size="20" type="text" /><br>

Make it required by adding required=”true” at the end of the line. It will look like this:

<label for="email">Email</label><input  id="email" maxlength="80" name="email" size="20" type="text" required="true"/><br>

Once you’ve made all the fields required, plop the HTML on your website. Ask your webmaster to do it, or you can do it yourself if you haven’t got one. It’s easy enough to throw this code up on a wordpress page even with no website management experience. Test the form yourself by filling it out a couple of times — you should see new cases being created in your Salesforce org.

At this point, we’ve got a functional webform that’s creating new cases when filled out. You can route these cases however you’d like — in the past, I’ve set up a process that changes the owner of newly created cases to a case queue that serves as the support team’s inbox.

Next, we need to deal with the support email. Any incoming emails to the support email need an auto-response pointing them to the form without a case being created in Salesforce.

If you’ve tried to tackle this issue, you’ll quickly find that there isn’t a good way to do this. We need to capture the incoming sender’s email address, and we can’t do this without creating a case. So we need to allow incoming emails to create a case, fire off a response, and then immediately get rid of the case.

Here’s how we do this. Create an email template telling the client email-to-case is no longer supported and pointing them to the webform. Create an email alert to fire that template to the sender email address capture in the case. Create a flow to delete cases. Wrap all these things up using process builder so that when someone emails the support email, they get a response and then the newly created case is deleted.

Creating the email template and email alert is easy — go to the respective categories inside of Salesforce setup and follow the steps.

Now for the Flow. Go to Flow builder in setup and create a new autolaunched flow. We’re going to create a variable that we’ll eventually pass the ID of the case into so we can delete it. Call it “caseIdForDelete.” You can do this by clicking the “manager” tab in the Toolbox and creating a new text variable. Make sure “Available for Input” under the “Availability Outside the Flow” section is ticked.

We’re going to include a 1 minute pause in this flow as well. This ensures that all of our process builder actions that we’re going to set up later (the email to the client letting them know their case wasn’t created) fire before we delete the case and can no longer reference the client contact information.

Create a formula called “fiftyNineMinutesAgo.” Data type should be Date/Time, and your formula should be the following:

Now() - (59/24/60)

Now, drag a pause element into your workflow. Set your pause condition to “Always Pause Flow—No Conditions.”

Set up your resume event as follows:

• Pause Until: A Specified Time

• Time Source: Specific Time

• Base time: the formula you just created. You can click into this field and find the formula. If you named your formula fiftyNineMinutesAgo, this should read {!fiftyNineMinutesAgo}

• Offset number: 1

• Offset unit: Hours

This gives us a 1 minute pause.

Next, drag a Delete Records element onto your workflow. Select the Case object to delete, and filter case records so that the Id field is equal to your caseIdForDelete variable. Hit done, and save and activate your flow.

Now we need to set up a process that, when an incoming email hits your support email address, emails the sender back with the template we created, then deletes the case.

Your process should start when a Case record is created. Set up your conditions so that the actions happen when cases are created. In the past, I used the “Case Origin” field and the Case Record Type field. I set Case Origin = Email, and put the record type ID in there as well. It’s common to expand cases to several record types in the future, and for now, we just want this to apply to general support inqueries.

Once your conditions are set, we need to set up our actions.

We need two actions here. Set up an email alert action, and select the email alert you created earlier. Your email alert should take the template that tells the client that you’re no longer supporting email-to-case, points them to the webform, and lets them know a case wasn’t created. It should send to the email on the case.

Next, create a flow action. Select the flow we just made, and click “Add Row” under “Set Flow Variables.” In this step, we are filling the “caseIdForDelete” variable we made in the flow with the ID of the case that’s causing this process to fire.

Insert your caseIdForDelete variable where it says “Select a variable…”, change “Type” to Field Reference, and set “Value” to [Case].Id.

Save and activate your process.

You’re done!

You’ve now got a full solution to this problem. You’re redirecting clients to the new support form, which is collecting the information your agents ask for every time and automatically creating cases with that information filled. Any client that tries to contact support the old way is getting an email back with instructions on what the new steps are. Your support team can still email directly out of Salesforce, and clients can respond in those threads and still write activity to your cases.