Description:

• Currently, when an agent's machine goes to sleep, loses network connection, or resumes after a period of inactivity, the platform automatically places the agent into the "WORKING" state. This is a default system state, and cannot be removed or reconfigured, similar to NCX.

However, this behavior creates confusion for supervisors and admins monitoring real-time agent states. The “WORKING” label implies that the agent is actively engaged in tasks, even though they may have lost connectivity or walked away from their machine.

Feature Request:
• We propose introducing a more appropriate default system state for these specific conditions (e.g., system sleep, network timeout, or WebSocket disconnects):

🔄 Replace “WORKING” with a clearer status such as:

“Connection Lost”
“Disconnected”
“Session Timeout”
“Network Error”

This status should only be triggered during system-driven disconnections, not manual agent actions.

Why This Matters:

• Improves transparency in real-time dashboards and routing behavior.

• Helps admins and supervisors immediately identify connection issues vs. assuming the agent is working.

• Reduces missed or mishandled calls due to misinterpreted statuses.

• Supports accountability and follow-up (e.g., reaching out to the agent to check if they’re experiencing technical issues).

• Aligns agent state logic with actual backend session state and improves operational visibility in high-volume contact centers.

Reproducible Scenarios:

Agent is logged in and set to AVAILABLE.
Machine enters sleep mode.
Upon waking, session reconnects — agent is placed in “WORKING” despite no input.

OR

Agent places an outbound call to a disconnected number.
Call fails; agent transitions to “WORKING” without taking any further action.

Impact:
• Frequent confusion among admins.
• Incorrect routing behavior due to “active” status.
• Average of 4–5 agents per hour affected.
• Impacts SLA, productivity, and agent accountability metrics.

Suggested Implementation:
• Enhance session reconnection logic to check:

• If agent is not actively engaged with UI.

• If the reconnection was system-triggered (e.g., Layer 2 reconnect or socket timeout).

→ Place agent into a descriptive, non-selectable system state that reflects the disconnection reason.