Tips for Implementing Salesforce Omni-Channel in Lightning
What is Salesforce Omni-Channel?
I’ve implemented the Salesforce Omni-Channel feature for a few clients now, and want to share some tips and lessons learned if you are considering implementing it. First, what is Omni-Channel? It is simply it workload monitoring and routing tool that can be used to assign records to an agent. Most commonly Omni-Channel is used to route Case records. The namesake is based off the concept that Cases can enter your CRM from a variety of channels such email, your website, telephone, and chat.
The Omni-Channel tool monitors agent availability and can route cases from any channel to your agent. It enables to prioritize different Cases coming from different channels. For example, “live channels” such as chats and phone calls can be prioritized ahead of non-immediate channels such as email and your website. However, if you are slammed with phone calls for the morning you might never get to any of the emails. Omni-Channel allows you to set up escalation rules where after a certain time period, or when volume from “live channels” slow down that Cases from non-immediate channels are put into the agent’s workflow, while not allowing the “live channels” queue to build too much.
The first step to setting up Omni-Channel is to enable it by checking a checkbox in the setup menu. The next step is to create the channels. This is where things get a little confusing. Salesforce equates a channel to an object. Meaning your Live Chat Transcript record represents a chat. This gets a little confusing when you consider the Case object. “Case” isn’t really a channel, and in fact, typically on the Case there is a channel field that will contain values like phone, chat, web, and email. Nonetheless, setup a “Case” channel.
The second step is create Omni-Channel statuses. When you create a status you have the option to assign a channel to it. That means whenever an agent is in that status the system will look for any of those pending records and route them to the agent. You can create statuses with multiple channels in them. Typically, a status like “Ready for Chat & Cases” is created with the channels of chat and Case selected. Because chat is a real-time channel you can prioritize it over Cases (more on that in the next step). You can also create statuses with just one channel assigned to it like “Ready for Chat”. Finally, you can create a status with no channels assigned to it such as “Break”.
The third step is to create the routing configuration. The routing configuration dictates how pending work items are routed relative to one another. For instance, if you both pending chats and Cases you would likely want the chats to be routed first because they are more time sensitive. In that case, you would create a routing configuration with a priority of 1 and assign it to the chat queue. You’d then create a second routing configuration with a priority of 2 and assign it to the case queue. Another part of the routing configuration is sizing the work item. You can do this in unit or percentage terms. Usually if you have an agent handling both chats and cases we recommend sizing all work as a unit size of 1, or 100%. The reason for this is because if an agent is chatting with a customer you don’t want them to be routed a Case that interrupts them while they are chatting, and may cause confusion about what they should be working on. In addition, it can caused skewed reporting because the handle time clock starts ticking when the work item is routed to the agent. This approach also enables agents to focus. For example, the agent may be working be available, and then routed a Case. They start working on a Case, and then a chat is queued. If the Case didn’t take up all of the agent’s capacity then they’d be routed that chat. This would cause a break in the agent’s workflow and focus. Instead the agent is able to respond and handle the Case, and then be routed the chat. As the final part of this step you need to go to each of the queues and assign the routing configuration you created to them.
The final step is to setup the presence configuration. The presence configuration represents the agent’s capacity. If you set all routing configurations to 100% in the third step this step is required still, but not material. After creating the presence configuration you need to assign your agents to it. You cannot do it directly from a user record.
The main items to ensure doing user setup is that the user is assigned to the queues. In addition, you need to ensure that the user has the presence statuses assigned to them. You can assign user presences either via their profile or via a permission set.
Lightning App Setup
Lastly you’ll need to ensure that Omni-Channel has been added to the utility bar of your Service Cloud application, so that agents can log in and begin receiving work!