Initial State Visibility

• Agents begin in an idle state, with the telephony channel state prominently displayed on the desktop.
• Other channel states (chat, email, social) are also visible, and hovering over each state reveals the current status and duration for all four channel types.
• The system uses timers and codes (for example, "lunch" as an idle state) to track how long an agent has been in a particular state per channel.

Set Availability

• Agents can set themselves to available across all channels simultaneously, which resets the timers for each channel.
• Alternatively, agents can set availability on specific channels only, for example, being available solely on telephony while remaining idle or at lunch on chat, email, and social channels.
• This selective availability ensures agents receive contacts only on the channels they are prepared to handle.

Manage channel-specific availability

You can now manage your availability for specific channels independently, at a granular level, rather than applying a single global state to all media types.

• All—Use this toggle to become available or unavailable on all assigned channels at once.
• Voice—Toggle to receive or block incoming phone calls.
• Chat, Email, Social—Toggle these switches to manage your presence for specific digital media. For example, you can be available for Chat and Email while remaining unavailable for Voice calls.
• State Status: Each channel displays its current state (example, "State: Default"). This refers to the state configured by the administrator for that specific channel. When you toggle channel to ON, you receive requests for that specific media type based on the configured default routing.

Click Apply to activate your changes. This ensures you do not accidentally toggle your state while handling an interaction.

Handling Calls and Interactions

• When a call is connecting on the telephony channel, the agent’s state changes to reserved. Once it offers or gets connected, stated changes to engaged.
• During telephony engagement, the agent remains available on other channels, allowing concurrent handling of chat, email, or social interactions.
• After call completion, the agent enters a wrap-up state specific to telephony, during which they finalize the interaction.
• Once wrap-up is complete and a wrap code is selected, the agent returns to available status on telephony, with timers reflecting the time spent in each state.

Handling multiple chat channels

Agents can manage multiple chat sessions concurrently, with clear state transitions reflecting engagement and wrap-up phases. For example, consider an agent having a multimedia profile allowing three concurrent chat channels. This configuration enables the agent to engage with multiple chat customers simultaneously. Upon accepting the first chat, the agent’s chat channel state changes to engaged, and the system indicates that one of the three available chat sessions is in use. When a second chat request arrives and is accepted, the agent is now handling two chats concurrently, with the chat channel showing engagement and utilization of two out of three chat sessions.

• After completing chat interactions, the agent enters a wrap state on the channel where the interaction occurred. The wrap state indicates the agent is performing post-chat tasks such as logging notes or updating records.
• The system displays the predominant or rolled-up state as wrap when no other active interactions exist.
• A timer shows how long the agent has been in the wrap state, providing supervisors and agents with visibility into post-interaction processing time.

Pending Idle States and Transitions

• Agents can set themselves to pending idle states (for example, pending lunch) while still engaged or in wrap-up on a channel.
• This pending status signals the agent’s intention to move to idle after completing the current interaction.
• The agent will not receive new contacts on any channel once idle but remains visible as working on the current channel until wrap-up finishes.
• Hovering over the state shows the pending status and the elapsed time since the idle intention was set.

WebRTC and Browser-Based Desktop

• The WXCC agent desktop is browser-based and WebRTC-enabled, supporting real-time communication across channels.
• Supported browsers include Chrome, Firefox, and Edge, ensuring broad compatibility.
• WebRTC architecture facilitates direct communication and media handling, enhancing call quality and desktop responsiveness.

RONA (Ring No Answer) Behavior Optimization

RONA occurs when you don't accept a voice call, chat, email, or social messaging conversation request within the time frame specified by your administrator. When RONA occurs, the contact request is returned to the queue, and the agent status automatically changes from Available to Idle.

RONA handling is optimized by isolating the effect to the specific channel where the no-answer occurred. For example, if an agent misses a telephony call without setting themselves idle, only the telephony channel state changes to idle. The agent remains available on other channels such as chat or email, minimizing disruption and maintaining workload balance. This channel-specific RONA behavior enhances agent efficiency and supervisor visibility.

In addition to these manually selectable idle reasons, the system may automatically set your state to Idle with specific reasons (Idle Aux Codes) due to various conditions, including non-acceptance of contacts, device issues, or system errors (example, 'Invalid_Number' or 'Channel_Failure'). For a comprehensive list of these system-assigned states and the actions you can take, refer to the System-Assigned Agent States and Error Conditions (Idle Aux Codes) section later in this article.

While interacting with a customer, you can select an idle state reason. For example, you can select this option during a chat session with the customer or when responding to an email message. To learn more about which idle state reason to use, contact your supervisor.

Your administrator configures the maximum time available to accept an incoming request from any channel. If the configured maximum time is lapsed, RONA occurs, and the request is returned to the queue if you don't accept it within the specified time.

When RONA occurs, a popover appears with the following options:

• Go To Idle —When you click this, your state changes to the default idle reason configured by your administrator.

• Go To Available —When you click this, your state changes accordingly. The available state indicates that you are ready to accept and respond to contact requests routed to you.

System-assigned Agent States and Error Conditions (Idle Aux Codes)

Beyond the manually selectable 'Available' and administrator-configured 'Idle' states, the system can automatically assign specific 'Idle' states, often referred to as Idle Auxiliary Codes (Aux Codes). These states are crucial for understanding why contacts may not have been delivered to you, including various error conditions, system issues (such as network failures or invalid configurations), or situations where you did not accept a contact. The table below provides a comprehensive list of these system-assigned states, their descriptions, and the immediate actions you can take to manage your availability or address the underlying issue. This section directly addresses scenarios like a Webex Calling outage affecting agent state, ensuring you know what state you're in and what steps to take.

Some of the other available states are summarized in the table below:

If you select an Idle status while currently Engaged or in Wrap-Up, the system places you in a "Pending Idle" mode. The system then stops routing new interactions to that specific channel immediately. Once you conclude your final interaction and finish any Wrap-Up work, the system automatically transitions you to your chosen Idle state. However, for non-voice channels (Chat, Email, and Social), you can directly set your state to Not Ready even if you still have active interactions in that media type.

State timers

The state timer is displayed in the availability state field, and it tells how long you've been in the current state. These timers are set to run for these instances: available, RONA, and any idle states configured by your administrator.

Idle states

If you're in the idle state and switch to another idle state, the timer displays the time you're in the current idle state and the overall time you were in the idle states. For example, if you're in the idle state for 10 minutes and then take a Lunch Break (configured idle state) for 20 minutes, the timer then displays as 20:00/30:00.

Connected timers

When you accept a request for a phone, chat, email, or social messaging interaction, a timer appears in the task list window next to the request.

Along with the connected timer, the interaction control pane displays another timer dependent on the system's state and how you proceed with your discussion. For example, when you place a call on hold, the timer displays the hold time next to the Consult on Hold condition.

The agent interaction history pane shows the total duration of your connection with the customer, encompassing the time from the start of the contact until the communication concludes. For example, if you engage in a conversation with a customer and consult with another agent before ending the interaction, the connected time accounts for both the duration of your connection with the customer and the time spent consulting with the other agent.