Service Cloud August 2014 Contact Center Modernization

I am on a plane to Open World in San Francisco and thought that taking the time to finally write up my review of the new Oracle Service Cloud release would be an appropriate use of my time. As a reminder eVerge Group will be featured in four Service Cloud Sessions and I will be speaking at two. Please stop by and say hello I will be at all four:

  1. Oracle Service Cloud for Siebel Service[CON8917] Wednesday, Oct 1, 12:45 PM – 1:30 PM – Moscone West – 3001A
  2. Best Practices in Online Customer Engagement[CON8911]  Wednesday, Oct 1, 3:15 PM – 4:00 PM – Moscone West – 3001A
  3. The Best of Both Worlds, Cloud to Ground: A Siebel/Oracle RightNow Integration Story [CON3929]  Thursday, Oct 2, 11:30 AM – 12:15 PM – Moscone West – 2001A
  4. Oracle Service Cloud Platform Overview and Roadmap[CON8910]  Thursday, Oct 2, 2:00 PM – 2:45 PM – Moscone West – 3001A

The theme of this release resonates with the best practices eVerge Group will be speaking at in our session with Christopher Patterson at Open World. In 2014 there has been a push to transform and modernize customer service and I think this first image summarizes that initiative very well.

modern

Key enhancements to the product in this release span Web Customer Service, Cross Channel, Policy Automation and Platform. Although it isn’t as packed with new features as May was there are some really exciting features.

webcsWeb Customer Service

Experience Routing (Chat)

In May the ability to use experience routing within chat allowed for fewer rules, simplified queue management, routing based on products, categories, language and more to the most skilled agents and the ability to strategically priority level of service. All of these added a tremendous value to the product allowing organizations to increase CSAT, Retention and Acquisition through more modern approaches to a channel that has been around and matured with all of us. This feature has brought Chat back in style like big phones and bellbottoms.

In August we see a new iteration of capabilities in experience routing that offer an organization the ability to optimize the utilization of chat agents as well monitor trends in queue performance, traffic and workload. The key benefits of this include improved responsiveness by load balancing work assigned and an overall better understanding of queue/agent performance. This is important for forecasting need in peak times as well as maintaining the desired level of service for the channel.

ERprodcatlang

crossCross Channel Contact Center

Collaboration

This is a feature that I have anticipated for quite a while.  In the past year I have observed a renewed interest from organizations that desire to empower agents and to improve knowledge. Part of this movement has involved the adoption of KCS or knowledge centered support. If you are not familiar with this methodology you can learn more on this site: http://www.serviceinnovation.org/kcs/

In the August release this feature centers on collaboration within the context of an incident transaction in the agent desktop. An agent can now access experts from their organization without getting up from their desk, transferring the call or escalating the incident. Collaboration is enabled for the traditional client as well as the mobile agent app allowing access to another level of knowledge anywhere, anytime.

Agents are alerted about important collaborative posts using enhanced “toast” notifications keeping them up to speed in real-time. Organizations who take advantage of this will be getting a fully functioning internal social network that can be used by their staff to increase quality, productivity and efficiency. In terms of key performance indicators (KPIs) this translates to increased customer satisfaction (CSAT), decreased handle time (AHT/MTTR) and increased first contact resolution (FCR). As I mentioned above this also enables organizations to adopt some of the aspects of KCS. They will be able to start capturing previously undocumented, tribal knowledge and with the proper workflow implemented convert these interactions into knowledge articles that can be pushed out through web self-service. This adds another KPI to the mix, with more relevant knowledge available to customers there will be an increase in call deflection and a decrease in creation of incidents that positively affects return on investment (ROI).

collaborate

 

paPolicy Automation (PA)

In August we have more changes in policy automation within interview experience, modeling and deployment. If you are not sure what you would use PA  for think about process you walk through like determining benefit eligibility, comparing car insurance rates or upgrading your phone.

Interview Experience

The layout of the interview experience can now be enhanced with embedded images, controls that can be displayed side-by-side and sections that can dynamically show or hide. A streamlined audit process that allows the viewing of decision reports within Service Cloud’s agent desktop or any other application that it is connected to has been introduced. Finally you can also capture evidence by uploading any document and viewing it in the agent desktop.

 layout

 

Modeling Productivity

There is now the ability to work collaboratively on multiple people on the same project while keeping track of what was changed and why. Also new sample projects have been added for industries like Retail, Travel & Transportation, Licensing they can be used to create new interviews or enhance existing ones.

Deployment Efficiency

In August a new, cleaner more simplified user interface has been added that allows you to audit changes made to projects and deployments separately providing a more robust history. The web service connector will allow you to securely integrate to Service cloud and other applications in a standard way that makes mapping to a data model easier.

deployment

 

PlatformPlatform

Within the Service Cloud Platform support has been added for both ODBC and JDBC drivers. These are cloud agnostic drivers that will work even in a PCI cloud without firewall configuration and allow quick, easy access to common data management, ETL, and analytics tools.

Roadmap

In the next year the key features I am most looking forward to are Browser Based Agent UI, Oracle BI integration, Advance knowledge and last but not least REST APIs. See below for an overview however understand that Oracle always caveats these roadmaps with the disclaimer that features may change at any time especially in the “Next 12 Months” bucket.

augrm

 

 Rhianna Blue BlazerHeadshot2About the author: Rhianna Albert (Just Rhianna) has an extensive background in customer support systems and processes, is an active member of the CX community and has been implementing and integrating RightNow solutions for seven years.

 

For more information on the August 2014 version including release notes, manuals, webcasts, tutorials and community posts. Please review at the official RightNow documentation overview page.

If you are interested in learning more or have questions feel free to reach out to me at cx@evergegroup.com

eVerge Group is an Oracle Platinum Partner with extensive experience. For more information about Oracle RightNow CX and our other business solutions, contact us through our website: http://www.evergegroup.com/contact.php

First things first

Remember in my last post when I said we would start reworking the multiline widget to display different content than it does out of the box?

I have a confession to make.

I lied.

Before we can look into extending a view to do something new and interesting, we should first look into widget extension itself, and how the wizard works. While it is still possible to create a new widget without using the wizard, in the vast majority of cases, you will want to use this. It will create the scaffolding correctly for you, stub out methods for easy overriding and create the yui file for you. If you later decide you have to add more functionality to the widget (I actually needed to extend the logic file…or I need an AJAX endpoint in my controller) then you have two options, you can either update the other files and edit the yml file manually (later post), or you can back up the work you’ve done, delete your widget, create a new one, and replace the code you’ve already developed. In most cases, I would recommend this as constructing your own logic or controller extension file is something of a pain.

So, what should we expect from the widget wizard? Well, first you have to figure out if you’re going from scratch or extending a current widget.

Step 1

It all starts here

If you’re old school, this is a pretty easy decision to understand. If you would go in and copy the Sample widget, rename it and then start creating your own view, logic and controller code, you’re going to want to select Create a New Widget. If, instead, you were going to go copy a widget to custom, rename it and then start tweaking, you’re going to want to select extend the widget. Details for creating a new widget may come in a future post, but for today, in order to get our feet wet with updating an existing widget, we’re going to select extend a widget.

Clicking this presents us with three input boxes, the first asks what widget we are extending. Just start typing the widget you want to use in, then select it from the drop down. Simple. Next, we are asked what we want to call our custom widget. There is code in the wizard that makes sure your widget name doesn’t already exist in the path you specify (more on that in the third field) and, should you accidentally be creating a duplicate widget, the system will save you from yourself and not let you create the widget. Finally, you’re asked what path you want to put the widget in. This is something of a change from the old file scheme, and generally a welcome one. All widgets must be nested in a folder, you can no longer create a widget at the root /custom/ level. This forces us to categorize our widgets. In the case of custom ones, this is generally pretty easy. In most cases, you will use the same subfolder in custom that you copied from in standard.

Major Decisions Here

Major Decisions here

Next up we get to define the components of our new widget. As we are extending from another widget (in this case a ProductCategorySearchFilter widget) we have to tell the wizard what parts we want to extend. For anything server side, such as form submission, retrieving data from the database, writing data TO the database (usually db writes will happen as part of an AJAX based form submission), new data components being exposed to the view, or other server side actions, such as working with a session variable and data manipulation, we need to extend the controller. If you’re going to add new communication between front end and back end, such as looking something up from the DB based upon user interaction on the page, you will need to both extend the controller and select yes for the controller doing its own AJAX handling, which brings us into the second radio button. Spending a bit more time on the first though, the effect of selecting yes to the widget having its own controller is to cause the system to generate a controller file with a baseline constructor which pulls in all the code of its parent, and stubs for all of the methods of the controller allowing you to either add to, or override those methods. If you decide to override a method, bear in mind that future updates to that widget that touch those methods might impact your widget. RNT/Oracle will generally communicate in the patch notes if these updates are likely to impact custom code. If so, you can choose on a per widget basis not to go to the new widget version until you have sanity checked that your own widget does not break.

Selecting yes to the widget doing its own AJAX handling will do three things. First, it will create a stub method in your controller to handle the AJAX request, secondly, it will automatically select yes for you on the Does this widget have its own JavaScript question and thirdly, it will stub out a JS endpoint for your AJAX request. As mentioned above, this is necessary if you are going to need to have any front end/back end interactions between your custom widget. This can also be used if you want to alter how the AJAX interaction of the parent widget operates.

Next you need to select if your widget modifies the parent view. This is probably the most common type of edit you would do to a widget (outside of basic CSS restyling), though getting used to extending a view can take some effort. The recommended option is to extend the view. This allows you to add content to the widget between the block tags that exist within the parent widget. In cases of view code contained between block declarations in the view, this allows you to override that section of HTML/PHP. This takes some getting used to as some view code is not contained between blocks and has to, in my experience be duplicated within a block and then the original removed from the DOM using the logic file, but this allows you to more cleanly edit the view without erasing the content already there. Short upshot of view extending, if you’re just adding content, you’re golden no matter what. If you’re changing content in the parent view, and that content exists between an opening and closing block tag, you can override it (more on this in the extending the view tutorial), and if it exists outside of an opening and closing block tag, you create your own DOM elements either before or after the element in question and then use JS to remove the original element from the DOM.

Your other option with a view modification is to override it. Use this option sparingly. There are two reasons for this. First, it obviously breaks the entire view for later inheritance. More importantly, however, it breaks the link to the logic file, forcing you to construct your own. This is likely due to the tight interaction between the DOM, generally presented by the view and the JS logic that acts on it with subscriptions, events, etc. For this reason, overriding the view will, in nearly all circumstances, cause functionality to fail and should generally be avoided.

View also asks you if you want to include the parent CSS. In most cases, you will want to do this (I don’t know why this isn’t defaulted to yes) as you will want to start from the basic look and feel and then potentially tweak the css from there. If you leave it set to no, the widget will not have its parent css applied and you will have to create your own styling from scratch.

The final heading to deal with here is the JavaScript heading. First you determine if the widget has its own JavaScript. This will create a logic.js stub for you to add your own methods to, modify the constructor and override existing methods, much like extending the controller. If you are adding new YUI components to the widget (such as adding autocomplete to the keyword widget) then you will specify these on the next line where it says Add module. This link will give you a dialog that allows you to begin typing a YUI module for inclusion into the widget. If you miss a module post-creation, not to worry, a simple edit of the YML file, which is created with all widgets, can get it added.

Also in the JavaScript heading is if you want to include the JS templates. These are typically used when the page does an AJAX refresh, such as with the Multiline widget. When a new search happens and data comes back, it uses this JS template to define the ‘new’ view.

Step-3

New Attributes

Old school CP developers will remember attributes living in the Controller file. These days they exist in the YML file and can be manually added and edited there, however the widget allows you a user friendly mode of adding new attributes, for use by the controller, view or logic files. These populate to the ci/admin page for your widget and allow for easy reference of what attributes the widget has.

Step-4

Description

This final piece might not seem important at first, but two years later when you’re doing a code audit, you’ll be kicking yourself if you don’t pay special attention to the Additional Details drop down. This allows you to add a Widget description to the reference page. Here is where you are going to want to outline exactly what your widget does, and how it differs from the baseline widget. This will make it easy for you to go in on a code review and bring that widget up to standard as you will know where in the widget to look. Please don’t ever ignore this.

Step-5

Success!

Finally, you will be presented with the following page showing you all the files you have created with the widget generator. Feel free to drop the widget onto your page now..it should be fully functional as-is…but it will be a clone of its parent. From here you can go into the view, the controller or the logic files (if you created them) and begin editing. Next up, we go in and look at one of those view extension files and talk about how we can modify the view of the widget we’re working with.