If you’ve implemented Salesforce Live Agent, or are about to, you have probably looked at all the declarative options from the Setup pages related to Live Agent. But what more can you do to help agents reduce clicks or to accomplish common goals such as ensuring a case is always created for the chat interaction?
Remember, the Salesforce1 platform is an “API first” solution. Most product features are also exposed via an API. For example, with two lines of code you can capture the URL of the page the customer was on when they initiated the chat request, and save that URL in a case field. Does this sound like functionality you could use? Let’s do it. This article assumes you have read the first part of this series: 4 Tips for Implementing Chat as a Support Channel and completed the agent side configuration in the console.
Set up a test chat page
Go to Setup | Customize | Live Agent | Deployments to create a new deployment code. This is what the code looks like from the configuration wizard when you save the setting.
Next, go to Setup | Customize | Live Agent | Chat Buttons and Invitations to create a new button code. This is what the code looks like from the configuration wizard when you save the setting.
Note your Organization ID, deployment ID and button ID will be different.
Notice I uncommented the “Offline Chat Content” from default code. For a test, I want to see the offline message to verify Live Agent code is actually running even if there is no agent available.
Now log in as a chat agent from your service cloud console, next thing you know you are chatting with yourself. Isn’t that fun? This is what I always recommend in Live Agent implementation – test the deployment code and make sure it works before implementing it in your web pages. You don’t have to set up a server first to test the chat configuration.
Automatically create a case
Now that we have a base chat page set up, let’s do something cool. Remember we said a common request was to always create a case, let us add a line in the deployment code, after the “init” method.
And I am sure it would help if we actually load the case record when agent starts the conversation. Might as well attach the chat transcript to the case too.
See what we did? With two lines of code, we actually created the case, loaded the case for agent in the console, and attached the transcript automatically. We also bypassed one screen as well. If you use the OOTB open new case option in the console app, an agent will have to manually select case record type then open a new case. Now, it will be defaulted to the case record type that is set in the agents’ profile. BTW, don’t forget to uncheck the New Case setting in the console app for Live Agent since you have already created a case automatically.
Preset fields with values
Let’s do something dynamic. One of the most commonly requested features in Live Agent implementation is to capture the URL where chat is initiated and store that URL in a case field. To accomplish this, let’s first create a case custom field and name it “Chat_Request_Page__c”. Then we can pull the URL value from the “DOM” property of the page and pass the URL to the custom field.
As I promised, two lines of code to capture URL and pass it to a case field!
What else can you do?
With the Deployment API offered by Salesforce1 platform, you can use similar mechanism to enable your agents like never before. How about setting a dynamic subject based on where that page is, so knowledge one widget can preload the most relevant articles for the agents? Or perhaps passing over customer’s shopping cart data to a case field and know how much value you may potentially save with this chat engagement? If you don’t know what the customer is thinking at the moment, at least you can tell what’s in their shopping cart.
In summary, we showed examples what you could do without even leaving the page where chat button is embedded. In the next blog, we will show you what can be done with an extra Pre-Chat form. See you next time.