Salesforce Omni-Channel

This post provides a technical view on the Salesforce Omni-Channel feature-set added in the Summer ’15 (beta) and Winter ’16 (GA) releases.

In functional terms Omni-Channel enables use-cases where work items are proactively pushed to specific agents based on defined rules in relation to priority, capacity and availability. The model extends the traditional Queue approach through routing configurations that define how work items (Cases, Leads etc.) are sized, prioritised and the required routing logic (least active agent or most available). Agent capacity and availability is configurable per work item type, or service channel in Omni-Channel terminology. Queue membership controls the applicability of a given agent for a given work item. As such queues are defined to represent the work item assignment structure (skills, regions, teams, products, knowledge etc.) – as would typically be the case outside of Omni-Channel. Once a work item is assigned to an Omni-Channel enabled queue automated routing to an available queue member takes place. Where automated assignment fails, pending work-items are held on the queue and routing attempts made each time agent availability changes. Agent work load is represented by ownership of the records represented by work items.

From an agent perspective Omni-Channel interactions are handled via an Omni-Channel Widget in the Salesforce Console. The widget supports accept/decline behaviour and manual presence status setting. “Away for Lunch”, “Available for Cases” being illustrative examples. The work item display in the widget is controlled via the primary compact layout for the object the work item represents.

Omni-Channel Console Widget

Omni-Channel integrates seamlessly with Live Agent, enabling a standardised approach to routing and agent capacity across channels. Seamless in this context relates to the end-result, there are configuration changes required to transition from standalone Live Agent to an Omni-Channel integrated state. The objects supported by Omni-Channel are limited to those objects supported by Queues i.e. Cases, Chats, SOS video calls, Social posts, Orders, Leads, Custom objects.

Hopefully the preceding paragraphs sufficiently set the scene for the technical aspects covered below.

Data Model

Omni-Channel Data Model

As the model above shows Omni-Channel is underpinned by a significant number of standard objects. The majority of the objects support queryable, createable and updateable access levels which provides extensibility where standard features require augmentation. The one notable exception to this is the UserPresenceStatus object which records the current presence status for agents, this object is read-only. This limitation will prevent custom solutions (or more likely 3rd party AppExchange solutions) from programmatically manipulating the agent presence; this could be significant where solutions wish to share state with Omni-Channel at the application level.

Extension Points

Beyond the ability to extend Omni-Channel through direct data-level interactions (Apex or API) there are additional extension points to consider.

1. Custom Fields. The UserServicePresence (aka User Presence) and AgentWork objects support the addition of custom fields.

2. Apex Triggers / Validation Rules. The UserServicePresence object supports both Apex Triggers and Validation Rules. In the former case custom logic could be introduced to take action when specific presences are set. In the latter case conditional logic could be applied to prevent presence changes, although the console widget behaves erratically in response to validation rule failures.

3. Custom Console Footer Components. For each Service Channel (Lead, Case etc.) a footer component can be specified to open when a work item of the service channel type is opened. The customisation potential here is considerable.

4. Omni-Channel SOAP API Objects. Full set of objects exposed via the standard SOAP API.

5. Omni-Channel Objects for the Salesforce Console Integration Toolkit. Extensions to the standard console JavaScript API to support manipulation of Omni-Channel objects. Straightforward enough. A key point here to note is that unlike Apex or API transactions, the JavaScript API does support update of agent presence.

sforce.console.presence.setServicePresenceStatus(statusId, function(result) { ..}

6. Pre-assignment. Omni-Channel routing is applied when a work item is assigned to a Queue via record ownership. Automated routing logic then assigns the work item to a user based on priority, availability and capacity rules. Granular control of the user-assignment is not provided. Use cases that require one agent to be preferred over another based on logic such as last customer contact are not supported. Finer grained routing of this type should be addressed in the pre-assignment step, i.e. before the queue assignment. Agent presence and capacity are accessible via code and could therefore be queried as part of a custom user-level routing process. The AgentWork object is also createable suggesting that a record representing a pre-assignment could be added to ensure visibility of the work item to Omni-Channel.

References
Omni-Channel for Administrators
Omni-Channel Developer’s Guide

Update – 10th March

With Omni-Channel current agent workload is determined by work item records open in the Salesforce console not record ownership. Closing the tab for a Lead record has the effect of setting the related AgentWork record status to closed.

Salesforce Live Agent

Live Agent – What is it?
Live Agent enables real-time, online chat between an organisation and its customers, prospects etc. The chat sessions can be initiated via clicking a button or link on a web page, or via automated invitation based on page access metrics etc. For the end user, it can be very convenient to resolve a query through chat, avoiding the usual frustrations of calling a support line – although the end-user experience is still very dependent on the skill and knowledge of the receiving agent. For the organisation, there’s huge potential for call deflection – an expert team efficiently managing multiple concurrent chats (routed by skill) can hugely impact on the call volume. The handling cost of a chat session is generally perceived to be 1 third of the cost of a phone call.

Theoretically therefore we have a win-win situation, online chat should be good for all parties. The double digit percentage increase in the use of chat year-on-year (according to Analysts) is evidence of this. Analysts are also predicting strong growth in live video chat for customer service, with B2C chat options such as Amazon’s Mayday button, becoming mainstream.

Salesforce Live Agent was introduced onto the platform in the Spring 12 release following the acquisition of Activa Live Chat in September 2010.

Key Implementation Concepts
Configuration of Live Agent is more complicated than most functional areas and not something to embark upon without reading the implementation guide. It is possible to deliver a usable solution using the declarative approach, however a fully branded or custom experience will require technical expertise with Visualforce and standard web technologies such as HTML, CSS and JavaScript.

1. Configuration
A Configuration defines the behaviour and presentation of Live Agent with a Salesforce console. Configurations define the number of maximum active chats, the welcome greeting, sound notifications on various events, supervisor monitoring settings and skills-based chat transfer options. Configurations are assigned to Users and/or User Profiles and are typically defined with separate configurations for for standard chat users and for supervisors.

2. Deployment
A Deployment defines the behaviour and presentation of Live Agent to the end-user, i.e. customer or prospect. Deployments control the look and feel of the Chat windows displayed, plus options for the saving of transcripts. Multiple deployments may be configured across product lines or host web sites.

Note – each deployment generates a snippet of HTML which should be inserted once into the host page. The referenced endpoint is unique to the Live Agent org and is generated (and displayed) when Live Agent is enabled.

<script type='text/javascript' src='https://c.______.salesforceliveagent.com/content/g/js/31.0/deployment.js'></script>
<script type='text/javascript'>
liveagent.init('https://d.______.salesforceliveagent.com/chat', '___g00000008OMv', '___g0000003MCJN');
</script>

3. Skill
Skills play a key role in routing incoming chats to appropriate agents. In short, multiple skills can be defined (“General Enquiry”, “Product A Enquiry” etc.) and assigned to Users and/or User Profiles. Every inbound chat is related (via the button) to one or more skill.

4. Chat Button
A Chat Button defines the entry point for a chat and also key information relating to routing such as skills required, queuing options and routing type. The routing type can be set to Least Active, Most Available or Choice. Buttons can be fully customised and branded and be set to display pre-chat forms or post-chat pages.

Note – each Chat Button generates a snippet of HTML which should be inserted into the host page.

<a id="liveagent_button_online____g00000008OT8" href="javascript://Chat" style="display: none;" onclick="liveagent.startChat('___g00000008OT8')">
<!-- Online Chat Content -->
</a>
<div id="liveagent_button_offline____g00000008OT8" style="display: none;">
<!-- Offline Chat Content -->
</div>

<script type="text/javascript">
if (!window._laq) { window._laq = []; }
window._laq.push(function(){liveagent.showWhenOnline('___g00000008OT8', document.getElementById('liveagent_button_online_vg00000008OT8'));
liveagent.showWhenOffline('___g00000008OT8', document.getElementById('liveagent_button_offline____g00000008OT8'));
});
</script>

5. Automated Invitation
In principle Automated Invitations work the same way as a Chat Button, however the chat session initiation occurs via a proactive invitation based on defined sending rules (Seconds on Page, Seconds on Site, Page Views, Url Match, Custom Variable).

6. Quick Text
Live Agent appears as a Channel for predefined Quick Text messages. Such message can be easily inserted into the Chat conversation, for agent convenience and standardisation of messaging. To do the character sequence ;; must entered into the chat text input, this will trigger a list of most recently used messages to appear, alternatively additional characters after the ;; will result in a filtered view. Not an ideal user experience as the agent must be familiar with the message naming. The now retired, standalone version of Live Agent console (flash based) had stronger functionality in this area – enabling messages to found by category.

Extension Points
1. Deployment API
The deployment API enables JavaScript to written that can customise the chat window, launch a chat session or specify back-end functionality such as record searching and creation. This API also enabled Direct to Agent Chat Routing, where routing rules are ignored and all chat invitations can be routed directly to one or more specific agents.

2. Pre-Chat Forms / Pre-Chat API
Introduce a pre-chat data capture that could be used for routing, mapping and auto-query. Mapping relates to mapping page inputs to record attributes in Salesforce. Auto-query relates to records automatically opening when a chat is accepted e.g. the contact record for the customer – or perhaps a transactional record such as an invoice, purchase, booking etc. In addition to record search, record creation is also supported e.g. create a contact record if no match exists. Information entered into the pre-chat form can be viewed by the agent before and during the chat session.

3. Customised Chat Window
Standard Live Agent Visualforce components can be used to build completely custom chat windows.

4. Post Chat Page
Finish the chat session with a page displaying a summary, useful links etc.

5. Live Agent REST API
REST resources that enable a custom chat experience to be developed using any programming language or technology capable of addressing a RESTful web service. Exemplar use cases for this API are custom mobile application development and integration of chat functionality into an existing application.

Note, each org enabled for Live Agent exposes a unique Live Agent API endpoint.

e.g. https://d.__2__cs.salesforceliveagent.com/chat/rest/

POST https://{org unique endpoint}/chat/rest/Chasitor/ChasitorTyping
POST https://{org unique endpoint}/chat/rest/Chasitor/ChatMessage
POST https://{org unique endpoint}/chat/rest/Chasitor/ChatEnd

Functionality – Agent View
Live Agent in the Salesforce Console

Live Agent - Console View

Key Features –
Manage multiple concurrent chats within the console
Find and open existing records related to chats
Create new records based on incoming chats
Choose records or pages to open as sub tabs of each chat session
New Case, Lead, Account, Contact, VF page (1-5)
Include Suggested Articles from Salesforce Knowledge in Live Agent
Attach a file to the chat session
Supervisor tab for monitoring

Functionality – Customer View

Live Agent - Chat Window View

Key Features –
Initiate and end a chat session via button or link
Initiate and end a chat session via invitation acceptance
Save transcript

Salesforce Knowledge Integration
A chat answer field can be added to article types (field name must be specifically Chat_Answer__c – Long Text), clicking the Share link for an the article will result in the Chat Answer text being pasted into the chat window. A nice convenience for agents

There is also a Suggested Articles from Chat feature in the Salesforce Console configuration which I assumed would search Salesforce Knowledge based on the Chat text – it seems that all this does is add Knowledge to the Live Agent sidebar.

Licensing
Performance Edition – included.
Enterprise and Unlimited Edition – feature license cost

Note – Live Agent is also available in Developer Edition.

References
Implementation Guide
Developers Guide
REST API Guide