Salesforce Integration
You can connect multiple Salesforce instances to a single Salted CX account and mix data in Salesforce with other data sources.
Supported Features in Salesforce
Salted CX relies on Salesforce Omni-Channel to be enabled. Salesforce Omni-Channel manages work assignments to agents including handling of customers. This makes it easier to understand agent performance in a contact center.
Salted CX supports the following features in Salesforce:
- Reporting on Salesforce AgentWork that tracks what time agents spent handling customers and working on other tasks that are distributed using Salesforce Omni-Channel.
- Reporting on Salesforce Service Presence agent statuses to understand when the agents are ready to handle customer conversations and whether they adhere to their schedule.
- Reporting on responded customer surveys.
- Turns in the customer journey for individual engagements.
Salesforce Omni-Channel Overview
Salesforce Omni-Channel is a feature that enables agents to fork on pieces of work called AgentWork. Salesforce Omni-Channel routes individual AgentWork items to agents based on settings that can customized directly in Salesforce.
AgentWork carries any kind of work an agent can accept and spend time on. Commonly this is a communication with a customer but it can also be an administration task.
Customer Journey
Salted CX roughly translated the following entities in Salesforce to corresponding items in the customer journey. It is useful to learn about Customer Journey Structure to better understand how Salesforce objects translate to Salted CX concepts.
Salted CX enables merging traffic from multiple platforms into a single storage. Each supported platform has a different vocabulary and concepts. Salted CX introduces its own concepts unified across supported platforms that strive to balance ease of use and flexibility.
Check Logical Model and Customer Journey Structure to understand key concepts in Salted CX. Depending on the quality of data available in individual supported platforms there are platform-specific exceptions and limitations that we cover in articles dedicated to individual platforms
| Concept in Salted | Objects in Salesforce |
|---|---|
| Customer | Contact. Currently Salted CX treats a single Salesforce Contact as a customer. |
| Contact | Contact. Salesforce Contact is used for both unique contact and the customer attribute that groups multiple contacts together. |
| Conversation | Case. Other objects in Salesforce point towards which cases they are related to. If this relationship can be traced back to the case the engagements are |
| Engagement | Salesforce Omni-Channel Salesforce AgentWork represents a unit of work for agents to work on. Salesforce Omni-Channel creates an AgentWork in case it requires an agent to handle a customer. This AgentWork is then routed to a queue and waits for an agent to start working on it. One Salesforce AgentWork work typically leads to creating a queue engagement that represents the customer waiting in the queue and an agent engagement that represents the actual contact between the customer and the agent. Salesforce may create multiple AgentWork items for a single case in Salesforce in case an agent finishes handling the customer but the customer requires additional attention. Salesforce Tasks Salesforce Task is translated to one agent engagement. Ad-Hoc Engagements Salesforce EmailMessage objects that cannot be associated with an OmniChannel AgentWork or a Task produce individual engagements associated with the conversation. Even when the same agent sends multiple email messages consecutively this will lead to multiple engagements each with one turn. |
| Turn | Chat Engagements Content from Salesforce LiveChatTranscript objects for chat conversations. Individual messages are extracted from the complete chat transcript. Email Engagements Content from individual Salesforce EmailMessage objects. Call Engagement Call engagements from Salesforce do not have turns. |
| Review | Individual Salesforce SurveyResponseResult items. |
Engagements
Engagements represent customers’ engagements with individual agents and other services (like a queue). If an agent is handled by multiple agents an engagement is created for every single engagement.
| Engagement Type | Description |
|---|---|
| Agent | Created for every Salesforce AgentWork that an agent accepted to work on. It can be a conversation on any channel that uses Salesforce Omni-Channel. These types of engagements are those you will typically be reporting for agent performance. |
| Invitation | Created for situations when an agent is asked to join a conversation by accepting Salesforce AgentWork. Invitation engagements are created only for situations when an agent misses or rejects the Salesforce AgentWork. This type of engagement enables you to find situations when agents are overloaded, conversations are offered to them even when they are supposed to work on something else, or they can point to a behavior issue. |
| Queue | Created for every Salesforce AgentWork that is in the Queue regardless of whether an agent accepts it or not. This represents a customer (or a task) waiting for an agent to be handled. |
Typical handled Salesforce AgentWork creates at least 2 engagements. One engagement has Engagement Type = Queue and the other has Engagement Type = Agent. When you create metrics or just count engagements make sure you focus on the right type and do not double count in some cases.
The general rule of thumb for creating metrics on top of the Engagement data set is that unless you have a specific use case you should filter for engagement type specific for your use case.
Turns
Salesforce has multiple ways how agents can communicate with customers. Depending on the method the turns are created differently.
Emails
Individual email messages associated with a case, lead, or opportunity create individual turns. If the message is not part of an Omni-Channel AgentWork each outgoing message also produces a separate agent engagement.
Live Chats
Salesforce Live Chat content is stored as pure text without internal structure. Salted CX analyzes the text content of live chats to create individual turns and associate them with the corresponding agents.
Customer Surveys
Individual responses to Salesforce Customer Surveys are represented as individual Reviews in Salted CX. Each customer survey may contain multiple questions. Responses to these individual questions produce multiple Reviews.
Customer Surveys in Salesforce are by default associated with the Salesforce Contact object which is equivalent to a Customer in Salted CX. Salted CX requires items in the Review data set to be linked to a specific Engagement. Salted CX uses heuristics to determine to which engagement the review is linked.
Salted CX uses heuristics to attribute the customer surveys to the engagement that immediately precedes the invitation to customer journey (based on Salesforce Survey Invitation creation time). If there is no engagement with the customer the survey results are not stored in the current implementation.
If a customer changes their answer in a customer survey only the most recent response will be stored in reviews.
Be mindful when acting on customer surveys. The survey results are attributed to engagements immediately preceding the invitations to customers to provide feedback. However, customer perception might be influenced by events that happened in previous engagements and even events that happened after the engagement it is attributed to. Drill down to the customer journey to better understand the complete customer experience. We recommend using surveys as a discovery tool for potential issues rather than using the review score average for decision-making without reviewing the customer journey first.
Metrics Overview
This section covers base metrics. These metrics are further used in calculations.
| Metric | Description |
|---|---|
| Agent Engagements | Counts the number of Salesforce AgentWork in which the agent talked with a customer. Any Salesforce AgentWork that was canceled before an agent accepted the work is NOT listed in this. Counts the number of tasks that are associated with the agent. |
| Available Time | The time an agent spent in Salesforce UserServicePresence status that has Salesforce attribute IsAway set to false. |
| Engagement Time | Salesforce Omni-Channel The time between the moment when an agent accepts a Salesforce AgentWork and the moment the agent switches to wrap up (AfterConversation phase) or completes the AgentWork (when the status is closed in Salesforce). In case the Salesforce AgentWork is completed but not accepted by the agent we fallback for the start of the engagement to the time when the Salesforce AgentWork was offered to the agent. This is the closest approximation we get and may lead to inflated Engagement Time depending on your environment. |
| Engagements within Service Level | Number of engagements that have attribute Service Level set to value Within SLA. This attribute is now set based on the time between the time when the Salesforce AgentWork is created and the time when the AgentWork is accepted by an agent. Currently, the threshold is set to constant 60 seconds for any agent work. Can be changed on request. |
| Focus Time | The time agent actively worked on the Salesforce AgentWork. Tracks when the AgentWork item is opened by an agent and in focus in Salesforce. If the Wrap Up phase is enabled in Salesforce it also counts the Wrap Up Time. Focus Time is available only for Salesforce AgentWork that is routed using the tab-based capacity model in Salesforce. |
| Invitation Time | Time it took the agent to accept, decline or miss the request to handle the AgentWork item. |
| Invitations | Counts Salesforce AgentWork that was either missed or declined by an agent. Invitations are NOT created for Salesforce AgentWork that is accepted by an agent. |
| Missed Invitations | Number of Salesforce AgentWork records missed by agents. |
| Rejected Invitations | Number of Salesforce AgentWork records rejected by agents. |
| Queue Engagements | All Salesforce AgentWork that was placed in a queue including Salesforce AgentWork. This includes Salesforce AgentWork which no agent worked on. This metric is useful to understand actual traffic in the contact center. |
| Wrap Up Time | The total time an agent spends in the phase called After Conversation Time in Salesforce is associated with AgentWork. This is the total time including all extensions. Wrap Up Time is not available for engagements that are not handled via Salesforce Omni-Channel. |
There are a lot of other metrics built on top of the metrics above. See Metrics Reference for more information.
Metric Calculation Formulas
Calculation of basic metrics using objects and fields in Salesforce.
| Metric | Engagements Matching Conditions | Value from Salesforce |
|---|---|---|
| Activity Time | Engagement ⏵ Type = Agent Status | = SUM ((UserServicePresence ⏵ StatusEndDate) - (UserServicePresence ⏵ StatusEndDate)) BY IntervalTime Salted CX breaks activity into 15-minute time intervals. So the actual formula is more complex for individual intervals. If a single user presence status crosses multiple 15-minute intervals, it gets sliced. Also, all activities of the same agent status in the same 15-minute window get summed. |
| Engagement Time | Engagement ⏵ Type = Agent | = (AgentWork ⏵ HandleTime) - (AgentWork ⏵ AfterConversationActualTime) |
| Focus Time | Engagement ⏵ Type = Agent | = AgentWork ⏵ ActivityTime Focus Time is available only for Salesforce AgentWork that is routed using the tab-based capacity model in Salesforce. |
| Invitation Time | Engagement ⏵ Type = Agent | = AgentWork ⏵ SpeedToAnswer |
| Invitation Time | Engagement ⏵ Type = InvitationAgentWork ⏵ Status IN ( Declined, DeclinedOnPushTimeout) | = (AgentWork ⏵ DeclineDateTime) - (AgentWork ⏵ CreatedDate) |
| Wait Time | Engagement ⏵ Type = Agent | = (AgentWork ⏵ AcceptDateTime) - (AgentWork ⏵ CreatedDate) |
| Wait Time | Engagement ⏵ Type = Queue | = (AgentWork ⏵ AcceptDateTime) - (AgentWork ⏵ CreatedDate) |
| Wrap Up Time | Engagement ⏵ Type = Agent | = AgentWork ⏵ AfterConversationActualTime |
Historical Data
Before Salted CX is enabled the data in Salesforce might not provide the same level of granularity and accuracy as after Salted CX is enabled. Salesforce does not store all the details that are necessary to restore data to the same detail as with the regular 15-minute loads.
The following data may be inaccurate for the time before using Salted CX:
- Engagement attribution to organization hierarchy including teams, departments, and locations. Salesforce stores the latest association between the user and their teams, departments, and other organization units. Salesforce does not provide past assignments to organization units so Salted CX attributes all engagements before the time it is enabled to the organization units the agent was assigned at the moment when Salted CX got enabled.
We recommend connecting Salesforce to Salted CX as soon as possible. This enables Salted CX to retrieve data granularity that would get lost as data gets updated.
Data Quality Issues
This section highlights cases in which the Salesforce data may not be accurate and Salted CX uses heuristics and other methods to process them to the best possible result.
Live Chat Transcripts
Salesforce Live Chat transcripts are a single unstructured text field. Salted CX makes the best effort to parse the transcript and attribute individual messages to agents and customers. Some scenarios are impossible to interpret accurately.
Known scenarios when the attribution of turns is not accurate:
- A participant copies and pastes the history of the chat to the conversation. Because the past conversation has the same pattern it is hard to identify whether the pasted content is regular turns or they are part of another turn. In this case, the pasted text content produces new turns and Salted CX does not recognize they are pasted content.
Overlapping Agent Statuses
Due to rounding and race conditions in Salesforce, the agent activity statuses reported from Salesforce sometimes overlap by a few seconds. This may lead to misleading metrics that could show that an agent spent in an agent status more time than possible.
Salted CX expects that the agent statuses do not overlap so during the data transformation it cuts the agent status activity if there is a new activity that starts while the previous one is not yet finished. This may lead to a few-second differences in reported activity time.
Additional Resources
The following articles cover Salesforce integration in additional detail: