Category: Reports & Analytics

How to deploy Live Chat in 3 Steps

Live Chat is a native channel of Oracle Service Cloud (OSvC), and one that is more and more in vogue. Text-enabled, real-time, conversations are the preferred way for many customers when engaging with companies.

One of the most popular ways of deploying OSvC Live Chat is placing the Conditional Chat Link syndicated widget in the company’s website. This is done in 3 simple steps:

Step 1 – Placed this snippet of code above any individual syndicated widget script. For performance reasons the recommended best practice is to place the code just before the closing tag and above any syndicated widget instance tags.

< script type=”text/javascript” src=”//yourdomain.widget.custhelp.com/euf/rightnow/RightNow.Client.js” >< /script >

Step 2 – This snippet of code is specific to the syndicated widget instance. For performance reasons the recommended best practice is to place this snippet of code just before the closing tag.

< script type=”text/javascript” >
   RightNow.Client.Controller.addComponent(
   {
      container_element_id: “myChatLinkContainer”,
      info_element_id: “myChatLinkInfo”,
      link_element_id: “myChatLink”,
      instance_id: “sccl_0”,
      module: “ConditionalChatLink”,
      type: 7
   },
   “//yourdomain.widget.custhelp.com/ci/ws/get”
   );
< /script >

Step 3 – Place this snippet of code on your page(s) wherever you would like the Conditional Chat Link syndicated widget to appear.

< div id=”myChatLinkContainer” >
   < div id=”myChatLink” >
      < div id=”myChatLinkInfo” >
      < /div >
   < /div >
< /div >

Once you place the above code in your company’s website page(s) you should be able to see the Conditional Chat Link syndicated widget display.

But to deliver a good customer experience, you need to manage customer’s expectations, therefore you don’t want to have the Conditional Chat Link syndicated widget available in your website if there isn’t anyone available to respond.

The Conditional Chat Link syndicated widget has various configuration settings, and some of the most used are:

  • min_sessions_avail – Minimum number of open agent sessions that must be available in order for the Conditional Chat Link to be actionable.
  • wait_threshold – Maximum wait time where the customer should still be allowed to launch a chat.

Note: Please notice that min_sessions_avail will always override wait_threshold.

So, for example, if you want to set min_sessions_avail to 2 and wait_threshold to 5 mins (or 300 seconds), you would need to set it on the syndicated widget and OSvC would generate new code adding the following lines to step 2:

min_sessions_avail: 2,
wait_threshold: 300,

In this scenario, where the Conditional Chat Link syndicated widget is unavailable, it is also useful to configure the setting label_unavailable_busy_template which is the label to be displayed when chat is unavailable due to agent session (Minimum Sessions Available) or wait time conditions (Wait Threshold).

By default, label_unavailable_busy_template is “All agents are busy“ but you might want to configure it to something more appropriate.

If you would like to know more information about the behaviour of the Conditional Chat Link syndicated widget, you can use the Conditional Link Stats report, which is used to display Conditional Chat Link syndicated widget statistics.

This report is out-of-the-box and displays the number of times the widget was loaded, the number of times the widget was active, the number of times the widget was clicked, and the respective percentages of each.

[Guest Post] Co-Browse & Reports

This is a guest post from Colin Campbell. My colleague at Capventis. A seasoned Oracle Service Cloud expert, with c. 10 years experience. To whom I thank for this post, as well as  for his invaluable expertise, which makes our implementation team even stronger.

I have to admit it, I love writing reports for service cloud, and whenever I have someone saying that they have an issue with a report the first thing I look at is the report definition.

This can be a bit confusing for some people but recently this immediately let me see that an out-of-the-box report (“Co-Browse Summary”) had a basic flaw.

Co-Browse 193 Report Definition.PNG

The first thing I noticed was the column definition for the Source:

if(cobrowse_sessions.tbl=1, msg_lookup(7475), msg_lookup(7494))

This gives a simple Binary result, if the co-browse session was initiated through a Phone Call or a Chat Session. You can see in the tables that the Interactions (what Incidents are called in this environment) is linked to the incident ID if the Co-browse session table = 1 (an Interaction).

This immediately made me think of the following situation, if a chat request comes in which includes a co-browse session, and then gets converted to an incident, it will have an incident ID, and as a result would be shown as a Phone Call rather than a Chat.

When I finally got round to running this report I saw exactly that. In the image below you can see Luis has had a phone call on the 18 Nov (row ID #9) and has an Incident Reference number next to it.

Co-Browse 193 Report Running.PNG

Opening the incident associated to this entry, you can see that the incident was actually originated from a Chat session (Channel = Chat).

Co-Browse phone call.PNG

So this could present an issue to the analysis of the data by whomever is using co-browse, as the out-of-the-box report is not showing the true channel of the incident and you could end up inflating the number of phone calls ending with a Co-Browsing session, which can then impact your resourcing and potentially having the wrong skilled staff waiting when it should be chat skilled staff. This increased wait will ultimately impact the Customer Experience.

It is not all doom and gloom as this is actually quite an easy fix for your reporting, ant you would just need to edit one table of the report.

Co-Browse Initial Modification Report Definition.PNG

The first change I have made is to the Source Column, rather than having the two message lookups I have edited the true condition to look at the incidents channel ID:

if(cobrowse_sessions.tbl=1, incidents.chan_id, msg_lookup(7494))

Using Luis’s incident above will mean that this co-browse session should now show it is a Chat session and not a phone call (notice again row ID #9).

co-browse-initial-modification-report-running

You can see here that my assumption is correct but it has shown something else. There are now some sources which are a “No Value” (and one as an “Email”).

The “Email” source itself is easy to explain and although co-browse is intended to originate from only two channels Phone and Chat, there can be occasions where a customer will phone about an e-mail, social media post, letter, etc. that they initially contacted you through with the phone call resulting in a co-browse session.

The “No Value” on the other hand is not, this is where a co-browse session has been initiated but it has not been associated to an incident, although you need to have the incident or chat workspace open for co-browse if you don’t save it, there is nothing to record it against.

To report on this I would look at updating the definition once again to include an additional IF statement against the source column so it reads as…

if(cobrowse_sessions.tbl=1, if(incidents.chan_id IS NULL, ‘Unlogged Phone’, incidents.chan_id), msg_lookup(7494))

With this last edit you can now define all of the channels and friendly terms that you need to aid you in your reporting and analysis.

Co-Browse Final Modification Report Running.PNG

Using this report as a base you can also add either a Contact ID or Incident ID/Ref No. Filter and embed this as a report within a Contact or Incident Record showing the history of the Co-Browse sessions.