Genesys Cloud - Main

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Hi John,

it is part of the usual drill to ask for network and console logs. I know, that this is a painful process, because the console ist not very stable and tends to crash after a while. But it is essential for the support to gather that informations together with call recordings. The console delivers a detailed information what happend in Genesys. Network errors, errors in Genesys etc. But usually network and console logs for a handful of affected calls should be enogh.

If your agentes are to busy, you could reproduce the error on a test queue by yourself. 

My second thought about this problem is of a different kind. In my company a call takes a long way through differend layers:

1. call coming in from the telephone provider our company is using
2. session border controller
3. in some cases numbers are treated in our old Alcatel telephone system
4. call routed to Cloud Voice
5. call treated in Genesys Cloud

Is it possible for you to check other layers of tec in your company to make shure, that the error is not happening there? Last big issues I had in my company had nothing to do with Genesys but with the SBC and the old Alcatel.

Logs are helping to identify this issues, too. They show, where the disconnection happend.

Best
Christoph

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Thanks, Christopher. You are always helpful.

Does capturing the network logs or console logs after the issue has occurred really capture the problem when users are logged into Genesys?

I had some users who experienced no issues for days, and then suddenly, they would encounter problems like disconnects. So, I am not sure how long they can keep the browser open and leave it open once I enable the network logs. I cannot reproduce this issue on demand, as there are around 100 employees or more on Genesys handling calls at one time.

I can try one or more users to do this, and I did capture the HAR logs and sent it to Genesys but was of no use. I have opened a call with Genesys again and hoping that they would look into this, as this seems to be an ongoing issue.

Thanks

John

Hi John,

it is part of the usual drill to ask for network and console logs. I know, that this is a painful process, because the console ist not very stable and tends to crash after a while. But it is essential for the support to gather that informations together with call recordings. The console delivers a detailed information what happend in Genesys. Network errors, errors in Genesys etc. But usually network and console logs for a handful of affected calls should be enogh.

If your agentes are to busy, you could reproduce the error on a test queue by yourself. 

My second thought about this problem is of a different kind. In my company a call takes a long way through differend layers:

1. call coming in from the telephone provider our company is using
2. session border controller
3. in some cases numbers are treated in our old Alcatel telephone system
4. call routed to Cloud Voice
5. call treated in Genesys Cloud

Is it possible for you to check other layers of tec in your company to make shure, that the error is not happening there? Last big issues I had in my company had nothing to do with Genesys but with the SBC and the old Alcatel.

Logs are helping to identify this issues, too. They show, where the disconnection happend.

Best
Christoph

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Hi John,

Are the agents clicking answer, but it doesn't answer? Are they being put in "Not Responding" when this occurs?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

No. the agent is not given the option to hit answer. the agent only notice that she is put into not responding when she gets an alert on one of her monitors telling her, she was scheduled to be on que but "not responding". 

------------------------------
John Francis
NA

Original Message:
Sent: 12-27-2024 07:40
From: Dawn Zielinski
Subject: Call Disconnects for agents

Hi John,

Are the agents clicking answer, but it doesn't answer? Are they being put in "Not Responding" when this occurs?

------------------------------
Dawn Zielinski

Original Message:
Sent: 12-26-2024 10:44
From: John Francis
Subject: Call Disconnects for agents

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

#SystemAdministration
#Telephony

------------------------------
John Francis
NA
------------------------------

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

You may need to use the functionality under Admin>Troubleshooting>Log Capture to turn on logging for agents who experience it the most, rather than their having to remember to capture logs all the time just in case...

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

I am not able to find Troubleshooting under Admin. Is it because of a different version we have or why is that?

You may need to use the functionality under Admin>Troubleshooting>Log Capture to turn on logging for agents who experience it the most, rather than their having to remember to capture logs all the time just in case...

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Your user probably does not have the necessary permissions assigned:

I am not able to find Troubleshooting under Admin. Is it because of a different version we have or why is that?

You may need to use the functionality under Admin>Troubleshooting>Log Capture to turn on logging for agents who experience it the most, rather than their having to remember to capture logs all the time just in case...

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

I am an admin

Your user probably does not have the necessary permissions assigned:

I am not able to find Troubleshooting under Admin. Is it because of a different version we have or why is that?

You may need to use the functionality under Admin>Troubleshooting>Log Capture to turn on logging for agents who experience it the most, rather than their having to remember to capture logs all the time just in case...

Sometimes my reps experience this and I think it is due to the browser running out of memory. I haven them hit ctrl+shift+del to clear the cache and then F5 to refresh and that usually clears the issue.

Are the calls actually getting transferred or are they just going to the next available agent?

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

For me, I start with the Agent Performance and show the Not Answering and Error columns.  If I see a large number of each, especially if they coincide, I know there is an issue with the agent's local connection or machine.  I then look for Telephony Events in the Operational Console.  Finally, if I need to find out exactly what errors are plaguing the agent, I filter the performance view for the station error types.  By then, I have 3 points to target the problem.  Hope this helps.  

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

We identified that agents experiencing slow ISP connections, or a poor persistent internet connection significantly contribute to this issue. All our agents are configured to auto-answer ACD interactions, ensuring that "alert-no answer" events should not occur. This configuration eliminates the ambiguity between an agent's choice not to answer and their inability to answer due to technical issues. When specific agents exhibit higher instances of "Alert - No Answer," we conduct a detailed investigation into those cases. Additionally, we utilize screen recording during interactions to identify problematic behaviors, such as agents operating with 20-30 browser tabs open or multiple concurrent Genesys sessions, which can degrade performance.

For me, I start with the Agent Performance and show the Not Answering and Error columns.  If I see a large number of each, especially if they coincide, I know there is an issue with the agent's local connection or machine.  I then look for Telephony Events in the Operational Console.  Finally, if I need to find out exactly what errors are plaguing the agent, I filter the performance view for the station error types.  By then, I have 3 points to target the problem.  Hope this helps.  

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Are you using Persistent Connection with these users?  I don't see how you could get a No Answer if you have Auto-answer on.  It should just connect the audio to the headset with persistent connection.  Besides, some firewalls will require some time to reallocate ports without it and that can cause issues with load balancers.  

We identified that agents experiencing slow ISP connections, or a poor persistent internet connection significantly contribute to this issue. All our agents are configured to auto-answer ACD interactions, ensuring that "alert-no answer" events should not occur. This configuration eliminates the ambiguity between an agent's choice not to answer and their inability to answer due to technical issues. When specific agents exhibit higher instances of "Alert - No Answer," we conduct a detailed investigation into those cases. Additionally, we utilize screen recording during interactions to identify problematic behaviors, such as agents operating with 20-30 browser tabs open or multiple concurrent Genesys sessions, which can degrade performance.

For me, I start with the Agent Performance and show the Not Answering and Error columns.  If I see a large number of each, especially if they coincide, I know there is an issue with the agent's local connection or machine.  I then look for Telephony Events in the Operational Console.  Finally, if I need to find out exactly what errors are plaguing the agent, I filter the performance view for the station error types.  By then, I have 3 points to target the problem.  Hope this helps.  

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

We are not using Auto-Answer as that was something that the management decided not to use it. I did enable Persistent connections now and I am monitoring it.

Are you using Persistent Connection with these users?  I don't see how you could get a No Answer if you have Auto-answer on.  It should just connect the audio to the headset with persistent connection.  Besides, some firewalls will require some time to reallocate ports without it and that can cause issues with load balancers.  

We identified that agents experiencing slow ISP connections, or a poor persistent internet connection significantly contribute to this issue. All our agents are configured to auto-answer ACD interactions, ensuring that "alert-no answer" events should not occur. This configuration eliminates the ambiguity between an agent's choice not to answer and their inability to answer due to technical issues. When specific agents exhibit higher instances of "Alert - No Answer," we conduct a detailed investigation into those cases. Additionally, we utilize screen recording during interactions to identify problematic behaviors, such as agents operating with 20-30 browser tabs open or multiple concurrent Genesys sessions, which can degrade performance.

For me, I start with the Agent Performance and show the Not Answering and Error columns.  If I see a large number of each, especially if they coincide, I know there is an issue with the agent's local connection or machine.  I then look for Telephony Events in the Operational Console.  Finally, if I need to find out exactly what errors are plaguing the agent, I filter the performance view for the station error types.  By then, I have 3 points to target the problem.  Hope this helps.  

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

Sorry got new glasses this morning.  Must have read that wrong!  Without Auto-Answer, the other things that can cause delays and the No Answer counts would be browser responsiveness.  I like to recommend running Genesys in its own browser window in perhaps another browser than their default and see how it performs.  

------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 01-02-2025 15:51
From: John Francis
Subject: Call Disconnects for agents

We are not using Auto-Answer as that was something that the management decided not to use it. I did enable Persistent connections now and I am monitoring it.

------------------------------
John Francis
NA

Original Message:
Sent: 01-02-2025 15:30
From: Robert Wakefield-Carl
Subject: Call Disconnects for agents

Are you using Persistent Connection with these users?  I don't see how you could get a No Answer if you have Auto-answer on.  It should just connect the audio to the headset with persistent connection.  Besides, some firewalls will require some time to reallocate ports without it and that can cause issues with load balancers.  

------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 01-02-2025 13:18
From: Garrett Gardner
Subject: Call Disconnects for agents

We identified that agents experiencing slow ISP connections, or a poor persistent internet connection significantly contribute to this issue. All our agents are configured to auto-answer ACD interactions, ensuring that "alert-no answer" events should not occur. This configuration eliminates the ambiguity between an agent's choice not to answer and their inability to answer due to technical issues. When specific agents exhibit higher instances of "Alert - No Answer," we conduct a detailed investigation into those cases. Additionally, we utilize screen recording during interactions to identify problematic behaviors, such as agents operating with 20-30 browser tabs open or multiple concurrent Genesys sessions, which can degrade performance.

------------------------------
Garrett Gardner

Original Message:
Sent: 12-31-2024 18:40
From: Robert Wakefield-Carl
Subject: Call Disconnects for agents

For me, I start with the Agent Performance and show the Not Answering and Error columns.  If I see a large number of each, especially if they coincide, I know there is an issue with the agent's local connection or machine.  I then look for Telephony Events in the Operational Console.  Finally, if I need to find out exactly what errors are plaguing the agent, I filter the performance view for the station error types.  By then, I have 3 points to target the problem.  Hope this helps.  

------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 12-31-2024 09:20
From: John Francis
Subject: Call Disconnects for agents

Thank you so much. You made my day! I have been fighting this issue myself for the last several months, trying everything, and I have been fed up. Every time, Genesys gets back to me saying to send the network and console logs. I cannot reproduce this issue at will, so how am I going to pinpoint when it happens? I still have the ticket open with Genesys and am working with them without any resolution.

Mainly, without knowing how the agents' network connections are-since most of them work from home and have either good, bad, or poor connections-it is hard to find the issue. Of course, they are connected to our VPN.

Hopefully, I will suggest to them what you have suggested and keep trying until there is a solution.

------------------------------
John Francis
NA

Original Message:
Sent: 12-30-2024 09:28
From: John Greer
Subject: Call Disconnects for agents

Hi John,

Our organization has experienced a lot of the same issues you have described regarding calls that cannot be picked up by agents and rolling over to other agents. I tried many different tests and configuration changes without much success for quite awhile. There are a couple of things we did do that made a noticeable difference including switching over to the agent desktop client from the web client mainly due to multiple browser issues involving memory management and cache issues delaying call connections. Our users also run many desktop and browser sessions at one time which taxes computer resources so agents that have a medium to high performance computer/laptop tend to fare better too. Setting up a persistent connection on your Genesys VOIP agent phone settings can also help. Another thing we found as a contributing factor was agents that are closing their Genesys session without properly logging off and then logging back in essentially causing a second session to run in the background. The symptom of that is usually the agent not being able to pick up an inbound call or a phone conversation that can be heard from only one party. Finally, I suggest opening a support ticket with Genesys and ask them to give you their advanced network assessment diagnostics and run that both on and off of your VPN if you are using VPN. Agents working remotely may have less than ideal ISP service on their end. Also, you may have some needed media ports blocked at your corporate firewall level especially if you are using Web_RTC phones. As you can see I have spent a lot of time trying to solve this issue and there can be multiple factors contributing intermittently to the problem. We have been running Cloud for over 2 years now and I still get some complaints I have to investigate. Good luck! I hope this helps a bit! I know firsthand how this issue can be very frustrating to agents, customers, and call center management especially with it's intermittent nature.

------------------------------
John Greer
Supervisor, Technical Support

Original Message:
Sent: 12-26-2024 10:44
From: John Francis
Subject: Call Disconnects for agents

We are getting a lot of complaint from the agents that by the time they could pick up the call the call disconnects. This has been an ongoing issue for the last 6 months. I opened calls with Genesys, but they ask me to send the Network Logs and Console logs after the incident has happened. How is this going to help in troubleshooting?

In one interaction, agent mentioned that the call transferred before she could pick it up, and she did not initiate the transfer.

"I had two calls that kicked me off Genesys today. I didn't do any transfers this morning but found two listed that way. 8:40 AM 207-310-9014 and I have another one as well."

This is becoming a significant problem, and we cannot explain to the agents why this is happening. When they miss calls or experience disconnects, their managers question them about why they did not answer the call. We need to find a resolution for this. Genesys cannot keep asking for network and console logs, as agents are busy and cannot interrupt their work to provide these logs. Obtaining these logs after the disconnects is not helpful. There should be a way to determine what is going on.

Any help from the community would be great!

#SystemAdministration
#Telephony

------------------------------
John Francis
NA
------------------------------