Agree with Paul on this.
What Genesys considers a skill does not work with what you are after. And to make the most of a solution you should try to use it as intended.
So maybe instead of
Tech 3
Tech 3 OR Tech 2
Tech 3 Or Tech 2 or Tech 1
For Tech 3 Q you could do something like
Tech Complex And Intermediate And Beginner
Tech Intermediate And Beginner
Tech Beginner
If you don't want Tech 3 people taking Intermediate and Beginner calls, and skill priority levels isn't enough for that, then in your Tech 2 queue, just include an extra skill that no one in Tech 3 has as a requirement.
However if you must,
And not sure how this will play with Bullseye routing since I don't use it myself, but in the InQ flow you can update the skills required for the call through the
Routing APIAnd from there you can develop your flow logic to determine what skills are required for the call.
------------------------------
Anton Vroon
KiwiBank
------------------------------
Original Message:
Sent: 11-19-2021 18:26
From: Paul Simpson
Subject: Reverse Bullseye Routing
Greg,
One of the problems we often face is that the approach Genesys Cloud (and it's sibling PureConnect) take towards ACD and Skills- Based routing is very different to that taken by some other products. Many new users / customers bring a different mindset, which can lead to misunderstanding.
Skills have two functions. Firstly, to restrict which agents, from a large pool, are suitable for a particular interaction and secondly to allow the best, suitably skilled agent, to be used for an interaction.
Let us assume we sell three products: A , B & C. Some of our agents are knowledgeable about a single product, some about 2 and some all three. Let us also assume we also sell these to all of North America, so deal with customers in English, Spanish and French. Again, we have some agents who speak one language, some 2 and some all 3.
So, we create three ACD skills (one each for the three products) and three Language skills (again, one each for the three languages) and assign the skills to the agents according to whether they have the appropriate product knowledge and speak the corresponding language.
Now, a call comes in and through the inbound call flow (IVR) we determine that the caller speaks Spanish and wants to discuss Product A. We therefore assign the Language Skill of Spanish and the Product Skill of Product A to the call and put it into the Sales queue, which contains all of our agents. Only Spanish-speaking agents who are knowledgeable about Product A will be considered. If more than one agent has both skills, then we can configure the system to select the one with the highest average proficiency. (In this way, we may have agents who are highly skilled in one product, but less skilled in another. Or who are native speakers of a language vs "get by".)
OK, so far, so good.
Now, let us assume that after 30 seconds, we would prefer to just get the call through to a Spanish speaking agent, regardless of product knowledge, since keeping the customer on hold is bad customer care. (Any agent is better than none!) we would set the Ring 1 timeout to 30 seconds and then remove the three product skills from the interaction as it moves into Ring 2. Now we are just looking for a Spanish speaking agent, regardless of product knowledge - more agents.
Taking this up a level, maybe we have licensing regulations which require our agents to be licensed to sell the product in a particular state. We simply create an ACD skill for each state requiring licensing, give the agents the skills for the states they are licensed in and require the corresponding skill when we put the call into queue. So in our example above, if the customer was in California, we would require an agent who speaks Spanish AND Knows Product A AND is licensed in California. After 30 seconds, we drop the product skill and now we just need an agent who speaks Spanish AND is licensed in California.
To finish off the discussion, another common requirement where bulls-eye routing is used is where we may have a Sales team that is split into regions. OK, so we have a queue for, say, the West region and we put all the Sales Agents for that region in Ring 1. We could put the Agents for the Central region in Ring 2 and the Agents for the Eastern region in Ring 3. When a call comes in, it will initially target just the agents for the region, but will gradually add more agents into consideration as the call is waiting for longer.
Whilst we can do both in a single configuration (add agents, remove skills) that leads to a lot of complexity that may not be desirable.
The purpose of the bullseye feature is to allow you to add agents in to consideration as a call is waiting in order to reduce wait times, even if that means we sacrifice selecting the "ideal" agent.
Given the above explanation, I hope you can appreciate that adding skills as the interaction waits would actually reduce the pool, which would be counter-productive. Also at no point would it make sense to look for an agent who speaks Spanish OR knows Product A OR is licensed in California.
I hope that explains the thinking, but please advise if you have further questions.
------------------------------
Paul Simpson
Senior Technical Instructor
Original Message:
Sent: 11-19-2021 13:29
From: Greg von dem Bach
Subject: Reverse Bullseye Routing
Hi Paul,
Thanks for the training reference. I'll definitely take a look.
Only having logical AND capability makes no sense to me nor does only being allowed to remove skills, not add skills to rings. Unnecessary restrictions that greatly reduce the functionality of the bullseye feature.
It reminds me of the illogical restriction of only being allowed to use the Equals operator in permission conditions. It greatly restricts the functionality of that feature and requires a lot of customization to work around it.
------------------------------
Greg von dem Bach
Alaska USA Federal Credit Union
Original Message:
Sent: 11-18-2021 11:34
From: Paul Simpson
Subject: Reverse Bullseye Routing
Greg,
Agents in Ring 1 will qualify for calls initially. After the Ring 1 timeout, it will move to Ring 2 where Agents in both Rings 1 and 2 will qualify, and so on.
Since an agent is only selected if they have all the skills associated (Logical AND not OR) you would actually be reducing the agent pool, not increasing it. This is why an alternative is to remove skills, since that will widen the agent pool as well.
I don't have an appropriate system spun up at the moment to take a screenshot, but I can do later. Alternatively, may I suggest you take the Administration training from Beyond where this process is discussed in detail?
HTH
------------------------------
Paul Simpson
Senior Technical Instructor
Original Message:
Sent: 11-18-2021 11:20
From: Greg von dem Bach
Subject: Reverse Bullseye Routing
Hi Paul,
Without using skills wouldn't every agent would qualify for every ring?
What we're looking for is an "OR" configuration.
Ring 1 skills: Tech 3
Ring 2 skills: Tech 3 OR Tech 2
Ring 3 skills: Tech 3 OR Tech 2 OR Tech 1
That increases the agent pool with each ring.
Can you post a screenshot to show how you would implement the scenario I gave?
------------------------------
Greg von dem Bach
Alaska USA Federal Credit Union
Original Message:
Sent: 11-17-2021 13:35
From: Paul Simpson
Subject: Reverse Bullseye Routing
Greg,
In this scenario, you don't need the skills at all, since the rings themselves will determine which agents are available.
The idea is that as the call waits longer, more agents are considered. In your example, you would be adding agents with the ring, but then also removing some by adding a skill. (So any Tech 1 agents that didn't have the Tech 2 skill would no longer be considered.) For the most part, more skills means fewer agents, not more. (An agent requires all skills, not any.)
HTH
------------------------------
Paul Simpson
Senior Technical Instructor
Original Message:
Sent: 11-16-2021 20:41
From: Greg von dem Bach
Subject: Reverse Bullseye Routing
Has anyone implemented "reverse" bullseye routing?
In Genesys, bullseye routing only allows you to remove skills as you move to the next ring. We want to add skills. For example:
- We have skills: Tech 1, Tech 2, Tech 3.
- We want Tech 3 agents to be in Ring 1. Skills: Tech 3
- If no Tech 3 is available, we want to add Tech 2 to increase the agent pool for Ring 2. Skills: Tech 3, Tech 2
- If no Tech 3 or 2 is available, we want to add Tech 1 to increase the agent pool for Ring 3. Skills: Tech 3, Tech 2, Tech 1
This would allow us to increase the pool of available agents as we move outward on bullseye rings.
How can we configure bullseye routing to add skills each ring instead of removing skills? Or, if that is not possible and this would need to be implemented in Architect, what would that call flow design look like?
#Routing(ACD/IVR)
------------------------------
Greg von dem Bach
Alaska USA Federal Credit Union
------------------------------