Genesys Cloud - Main

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Joined the queue with a phone selected: check whether the agent joined the queue with a phone/device selected. There is a permission that allows an agent to join a queue without an associated phone; when that happens, they won't receive voice interactions.
https://help.genesys.cloud/faqs/how-can-i-make-sure-an-agent-goes-off-queue-if-they-deselect-their-phone/

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Thanks for the reply Phaneendra,

These are pretty simplistic flows. 1 number, 1 flow repeated 3 times. Couple of scheduled alternate behaviours in there but generally call comes in, call gets assigned skill, call gets answered.

Have checked anyway out of an abundance of caution and the DNIS is consistent per queue/skill, and from the interaction table, as well as participant data, all appears in order with the skill being associated to the call.

Even considering idle time, the agent who "should" have received the call last took a call 2 hours before this instance whereas the agent who did get the call was 20 minutes between calls.

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Interesting, if the skill is definitely present on the interaction and the 5-star agent had a significantly longer time since last ACD interaction, then I'd agree this sounds less like expected Best Available Skills behaviour and more like something else influencing eligibility/routing at the time.

A couple of additional things I'd probably validate at that point:

• Utilization/concurrency settings for the agents involved

• Whether the 5-star agents had any non-ACD interactions active at the time

• Any differences in media capabilities or queue memberships

• If there were any recent presence/on-queue state transitions around the interaction timing

• Whether "Routing Includes Agent Presence" is enabled at the org level

Based on the timings you shared (2 hours vs 20 minutes), I'd also be tempted to open a case with Genesys support and provide a few specific conversation IDs for deeper routing analysis, as on the surface that does seem counterintuitive for Best Available Skills.

I'm sure someone might add more to this.

Thanks for the reply Phaneendra,

These are pretty simplistic flows. 1 number, 1 flow repeated 3 times. Couple of scheduled alternate behaviours in there but generally call comes in, call gets assigned skill, call gets answered.

Have checked anyway out of an abundance of caution and the DNIS is consistent per queue/skill, and from the interaction table, as well as participant data, all appears in order with the skill being associated to the call.

Even considering idle time, the agent who "should" have received the call last took a call 2 hours before this instance whereas the agent who did get the call was 20 minutes between calls.

Hi Kieran,

From what you've described, I'd probably start by validating that every path into the queue is consistently attaching the skill before the interaction reaches ACD.

Best Available Skills should consider proficiency, however if some interactions are entering the queue without the skill attached, then all queue agents become eligible and routing will fall back more toward longest time since last ACD interaction / next available agent behaviour.

A few things I'd check:

• Alternate Architect paths into the queue

• Direct queue transfers from agents

• Requeue / overflow scenarios

• Whether the interaction still has the skill attached when it arrives at the queue

Also worth reviewing the org-level "Routing Includes Agent Presence" setting, as this can influence how routing scores are calculated based on agent presence/on-queue behaviour.

From your description, this sounds less like WebRTC/connectivity and more like either:

• inconsistent skill assignment on some interaction paths, or

• expected Best Available Skills behaviour combined with idle-time routing

Hope this helps.

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?

Hello, @Kieran Exley.

Another point.

How Best Available Skills Actually Works:

With Standard Routing + Best Available Skills, the system:

1. First, identify the 100 agents with the longest time since last interaction across all their queues
2. Then, from those 100 agents, filters for those who have all the required skills
3. Finally, calculates the average skill proficiency for each agent and routes to the agent with the highest average proficiency

The Key Factor: Time Since Last Interaction

This is likely why your 5-star agents aren't always getting the calls. The system prioritizes the longest-idle agents FIRST, then applies skill proficiency within that pool of 100 agents. If your 5-star agents have handled calls more recently than your 2-4 star agents, they won't be in that initial pool of 100 evaluated agents.

Here is an article that shows some scenarios:[

https://help.genesys.cloud/articles/acd-evaluation-routing-methods/

Hi All,

One of my Team Leads has approached me today saying that some, not all calls, are alerting "undesired" agents first. That is to say, lower skilled agents are receiving the call instead of the high skilled agents.

Queue configuration = Standard Routing and Best Available Skills. 

Skill is associated at point of Transfer to ACD action in Architect. There is a single skill associated.

They have 2 agents on 5 star skill, other agents between 2 and 4. The idea is if available, 5 star skillers will receive the call regardless of other agents' availability.

I can see at least 3 instances today where the call has gone to 2 or 4 star agents despite there being at least one 5 star agent available. This is across multiple queues and flows.

Checking the agent status, duration, timeline etc, the 5 stars were 100% on queue, and in 2 of the cases, had the call transferred to them by one of the other agents to deal with which puts me off thinking it's an issue with their connection to their webRTC phone.

Have I interpreted wrong that our configuration (Standard Routing and Best Available Skills) should hit the most skilful first regardless of anyone else's availability? Is there anywhere else you can suggest to take a look at to understand if there is a blocker on the agent being offered the call?