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.
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.
Opening the incident associated to this entry, you can see that the incident was actually originated from a Chat session (Channel = Chat).
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.
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).
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.
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.
Doctor CX 