Hi @Catherine DUPIRE
If all agents were going to Not Responding during the same period, across both on-site and remote workstations, I would investigate it from both sides: local environment and Genesys.
"Not Responding" usually means the interaction was offered to the agent, but it was not answered within the alerting timeout. If it happened to everyone, I would ask the local IT/network team to validate anything that could affect the alerting or answer process, such as firewall/proxy behavior, DNS, ISP issues, VPN, endpoint security, browser policies, WebRTC/station connectivity, and any changes applied that day.
It would also be useful to compare:
-
Agents using different networks
-
Remote vs on-site users
-
Browser console/network behavior during the issue
-
Station/phone registration status
-
Any local security or network events around 9:30 AM
Since the issue resolved the next day without any visible change, it may be difficult to identify only from the UI. If the local checks do not show anything clear, I would open a Genesys Customer Care case with sample conversation IDs, timestamps, affected queues, agent IDs, phone/station type, and any local findings.
I would not assume it was only a Genesys issue or only a customer-side issue. With this kind of symptom, I think the best path is to correlate local network/endpoint information with Genesys backend investigation.
------------------------------
Arthur Pereira Reinoldes
------------------------------