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?

Thanks Phaneendra, I am erring towards raising a ticket, given the responses I'm a) pleased I'm not going crazy and b) there does seem to be something a little deeper going on

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?

Thanks for the update Kieran. Please do let us know what you find from the ticket investigation, would be very interested to hear the outcome.

Thanks Phaneendra, I am erring towards raising a ticket, given the responses I'm a) pleased I'm not going crazy and b) there does seem to be something a little deeper going on

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?

Heard back this morning and it does look to be a WebRTC Persistent Connection > Edge failure

"I see in the backend logs this conversation was not routed to *5 Star Agent* due to an error with their WebRTC phone.
In the logs we see the assignment service evaluated the available agents and would have assigned it to *5 Star Agent* but got the error: agentPersistentConnectionFailures"


Currently trying to get a successfully logged replication which is proving difficult!

Thanks for the update Kieran. Please do let us know what you find from the ticket investigation, would be very interested to hear the outcome.

Thanks Phaneendra, I am erring towards raising a ticket, given the responses I'm a) pleased I'm not going crazy and b) there does seem to be something a little deeper going on

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 Kieran,

Not sure if it will help you at all, but have you checked for any events in the Operational Console? (https://help.genesys.cloud/articles/troubleshoot-using-the-genesys-cloud-operational-console/)

I know that there are some events related to telephony/webRTC issues, so maybe you can find some events in there for the 5* star agent, which would confirm the suspicion.

That doesn't solve the issue, but could make it easier to identify when issues are happening (You can build some triggers to notify you when one of those events happen, for instance).

Heard back this morning and it does look to be a WebRTC Persistent Connection > Edge failure

"I see in the backend logs this conversation was not routed to *5 Star Agent* due to an error with their WebRTC phone.
In the logs we see the assignment service evaluated the available agents and would have assigned it to *5 Star Agent* but got the error: agentPersistentConnectionFailures"


Currently trying to get a successfully logged replication which is proving difficult!

Thanks for the update Kieran. Please do let us know what you find from the ticket investigation, would be very interested to hear the outcome.

Thanks Phaneendra, I am erring towards raising a ticket, given the responses I'm a) pleased I'm not going crazy and b) there does seem to be something a little deeper going on

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?

Marcello, this is an excellent suggestion and something I had no idea about until just now.

However, because I had no idea about it, looks like we don't have correct triggers in place for whatever happened as there's no related alerts at the time. I will definitely be digging deeper through this option for future referencing.

Hi Kieran,

Not sure if it will help you at all, but have you checked for any events in the Operational Console? (https://help.genesys.cloud/articles/troubleshoot-using-the-genesys-cloud-operational-console/)

I know that there are some events related to telephony/webRTC issues, so maybe you can find some events in there for the 5* star agent, which would confirm the suspicion.

That doesn't solve the issue, but could make it easier to identify when issues are happening (You can build some triggers to notify you when one of those events happen, for instance).

Heard back this morning and it does look to be a WebRTC Persistent Connection > Edge failure

"I see in the backend logs this conversation was not routed to *5 Star Agent* due to an error with their WebRTC phone.
In the logs we see the assignment service evaluated the available agents and would have assigned it to *5 Star Agent* but got the error: agentPersistentConnectionFailures"


Currently trying to get a successfully logged replication which is proving difficult!

Thanks for the update Kieran. Please do let us know what you find from the ticket investigation, would be very interested to hear the outcome.

Thanks Phaneendra, I am erring towards raising a ticket, given the responses I'm a) pleased I'm not going crazy and b) there does seem to be something a little deeper going on

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?

Hey Arthur, thanks for your reply!

The queues involved only have ~20 agents with barely half of those online at any one time.

Interaction came into the queue at 09:08:49.

This is agent 5 star's day with a previous interaction around 7am. Their next voice interaction is this interaction being transferred to them from a 2 star colleague.

This is the 2 star colleague's day. Last interaction was 8:40am before being first to be offered this one.

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?