Before the introduction of Skills-based routing, it was only possible to distribute work via Queues in Salesforce Service Cloud. Using Queues, it was – and still is of course – possible to put similar work in the same ‘bucket’. Support agents have access to Queues based on a specific skill. With Skills-based routing, you get more flexibility in organizing your support teams. So, how does Skills-based routing relate to Queue-based routing or routing via a communication platform?
Skills-based routing vs Queue-based routing
Queue-based routing is generally designed as one agent has one skill. An agent may be assigned access to different Queues, but one Work item may be assigned to one Queue only. In practice this means something like this:
- You create a Queue for English language
- You create a Queue for Technical questions
In this scenario you may assign the Work item to either the English language Queue or the Technical questions queue. The Work item can’t be assigned to both Queues. If you want to make these kind of combinations with Queue-based routing then you have to create a separate Queue for English Technical Questions, another one for French Technical Questions, and so on.
Also read
- Why skills-based routing?
A brief explanation of the need for skills-based routing in your organization- Configuring Skills-based routing in Salesforce
Steps to make an initial configuration of skills-based routing in Salesforce- Let the skills be with you
More in-depth explanation of concepts like work distribution, routing models, capacity management- Default Required Skills in Dynamic Skills-based Routing
Ensure that certain skills get never dropped as to ensure support agents always require a minimum skill to answer the incoming interaction
With Skills-based routing this is different. It looks at the skills that are required to complete a Work item and matches these data to the skills that are assigned to your support agents. Omnichannel routes the Work item to the first agent that has all requested skills and which is available to handle the Work item.
Skills-based routing may get applied to Custom Objects, and to the following out-of-the-box objects:
- Case
- Chat
- Lead
- Messaging
- Order
Skills may be freely chosen. For example you could create skills for languages (English, French, Dutch), for product knowledge (software or hardware), etc. You could also – optionally – assign a skill proficiency (1-10). Any agent may have a combination of skills and proficiency assigned. So when a new Work item comes in, the new items tries to match with the assigned skills of the available agents.
Voice vs non-voice channels
Larger support teams generally have an existing Telephony server (PABX), which is – obviously – used to answer incoming (and making outbound) calls. Such platform is often also used to handle incoming chat requests or e-mails.
But now, Salesforce also allows for flexible routing of non-voice interactions via skills-based routing. And with the introduction of Service Cloud Voice, your Omnichannel widget in Salesforce allows for answering incoming calls as well…
Although the incoming call will be visible in the Omnichannel widget, the routing of the incoming call will still happen (at the moment of writing 2020-01-23) on the Communication platform.
So, how would you decide which platform you should use for which channel?
Voice channel
Although Salesforce Service Cloud Voice allows answering (and making outbound calls) via the well-known Omnichannel button in the Console, the routing of the incoming call happens on the telephony platform (Amazon Connect).
The same applies if you don’t use Salesforce SCV for the voice channel. The routing of the incoming call happens on your communication platform. The most obvious difference will be in accepting the incoming call. This happens via a separate ‘Phone’ widget.
Non-voice channels
You implemented Salesforce Chat and/or Email-to-Case in Salesforce, and now you would like to start pushing these incoming to support agents. You also have a communication platform that allows to make these routings. Would you want to use the external platform, or would Salesforce Skills-based routing be better for you?
Let’s take the following example, where email-to-case gets implemented in Salesforce, but the routing should happen via an (external) communication platform:
- Email-to-Case creates a new Case,
- The Id of the Case is pushed to the communication platform, and
- There the decision is taken which is the best-placed agent to answer the question
- The communication platform also ensures that the Case is pushed to the agent
In such scenario, by accepting the incoming question via the AppExchange widget (provided by your Telephony platform provider), the agent immediately gets – for instance – the Case displayed on the screen and the agent is set to busy.
As you see, some integration will have to get build, retrieving (or pushing) the Case Id to the external platform. And then back to Salesforce to make the pop-up in the support agent’s Salesforce session.
Limitations of Skills-based routing in Salesforce
Although Salesforce makes a lot of effort to get the Voice channel fully integrated, it is not 100% the case today. Being able to answer the incoming call via the Omnichannel widget is a big advantage of course. But the routing of the incoming call still happens on Amazon Connect (with Salesforce SCV).
As such, Skills-based routing is not supported for external routing.
SOS Video chat and other out-of-the-box objects (except the objects mentioned above) can’t be used for skills-based routing.
Transfer from a skill directly to a user or button is not supported.
If a Work Item requires certain skills, but no available agents have these skills, then the work item is not routed.
Skills-based routing in Salesforce, and Salesforce Service Cloud Voice are evolving very fast. More integration will surely be added in the near future.
Are you interested in these functionalities? Would you like to get more information? Then schedule a call where we may discuss and demonstrate how this may work for your company!
7 Comments
Comments are closed.