Agent States and Login Sessions
Agent state data in Interaction Concentrator provides detailed information about agent activity, within the context of agent login sessions. This page describes how Interaction Concentrator (ICON) processes agent activity.
This page contains the following sections:
- Agent and Login Session Models
- Available Agent State and Login Session Data
- After-Call Work and Not-Ready Agent States
- Populating Agent Login Session Data
For information about ICON configuration and other Configuration Layer settings that make data about agent activity available in Interaction Database (IDB), see the Agent States and Logins tab on the Special Configuration Requirements page.
Agent and Login Session Models
This section introduces the terminology, elements (objects), and models that pertain to Interaction Concentrator (ICON) data about agent activities.
This section contains information about the following:
Agent and Login Session Objects
The following terms refer to the agent and login session objects and elements about which ICON stores reporting data:
- ACDQ—An Automatic Call Distribution (ACD) queue object (ACD device or ACD group).
- Agent state—The state that an agent may take in relation to the interactions that are associated with the agent. For voice interactions, it is also the state that an agent may take in relation to an ACDQ.
- ICON obtains information about agent state changes through agent state event reporting. ICON tracks agent states against different media types independently.
- Login session—The period of time during which the agent was logged in to an ACDQ or other endpoint on a particular switch.
- Media type—The communication medium applicable for the agent’s interactions (for example, e-mail or chat).
- Pending agent state—The agent state the agent will change to when the Busy state is ended. When the agent changes from any state to Busy, ICON keeps the pre-change state as the pending state.
- If ICON receives information about an agent state change while the agent state is Busy, ICON keeps the new state as the pending state.
- When the Busy state ends, ICON restores the agent’s state from the pending state.
- When the agent transitions from any state to Busy, ICON keeps the pre-transition state as the pending state.
- Reason—The reason for the agent state change. For voice calls, ICON obtains reasons for agent states from T-Server reporting, from any of the following sources:
- The workmode parameter.
- TEvent Attribute Extensions (known as hardware reasons), from the value of predefined ReasonCode keys.
- TEvent Attribute Reason (known as software reasons), from the values of one or more key-value pairs.
- For eServices or 3rd Party Media interactions, the Interaction Server multimedia reporting events may include attributes that contain information about the reason for the agent state change. ICON stores this reason code information in the same way that it stores hardware reasons. There can be only one reason for each agent state–related event that Interaction Server reports.
Agent State Model—Voice and Multimedia
Agent-Orientated Agent State Model—Interaction Concentrator supports an agent-orientated agent state model. In this model, the switching function maintains a single state for the agent for each media type (for example, voice, e-mail, or chat) within the agent login session, regardless of the number of endpoints or ACDQ objects with which the agent is associated. The agent can have a different state in relation to each media type.
The table below lists the agent states, described in relation to voice calls. The ACDQ is not applicable to multimedia, but the agent states for multimedia media types are equivalent. The table also provides the T-Server or Interaction Server (MM) reporting events that represent entry into each state.
Agent States and State Transition Events Table
|Agent State||Description/State Entry Event|
|Null|| The agent is not logged on to the ACDQ at a particular device. Logging on to the ACDQ causes a transition from this state. Similarly, logging off from the ACDQ causes a transition to this state.
|Login|| The agent is logged on to the ACDQ at a particular device and is ready to contribute to the activities of the ACD queue. The state does not indicate that the agent is ready to accept ACD calls (see Ready).
|NotReady|| The agent is logged on to the ACDQ at a particular device but is not ready to handle interactions distributed from the ACD queue. An agent in this state can receive calls that are not ACD calls.
|Ready|| The agent is logged on to the ACDQ at a particular device and is ready to handle ACD interactions, even though the agent might be involved in non-ACD calls.
|Busy|| The agent is logged on to the ACDQ at a particular device and is involved in an existing call at the device. The call may be on hold at the device.
|ACW|| The agent is no longer connected to a call but is still occupied with work related to the previous call (for example, the agent might be performing administrative duties, such as updating a business order form). In this state, the agent cannot receive ACD calls but may be able to receive non-ACD calls.|
Note: ICON cannot obtain call information from the T-Server event. ICON keeps information about the last call represented on the agent’s device before the transition from Busy state to any other state. In cases where the ACW state follows the Busy state, ICON assigns the last call on the agent’s device as related to the ACW state.
|Unknown||An agent’s login session exists, but ICON has no information about the agent state (for example, because of disconnection from T-Server).|
Agent State FSM
The figure below illustrates the finite state machine (FSM) for the agent state for voice calls, within a login session. Except for the AfterCallWork state and the names of the state transition events, the FSM for the agent state for multimedia is identical.
Agent State Restoration
On startup or reconnection, when ICON registers with T-Server to start monitoring agent states, the EventRegistered TEvent provides ICON with a snapshot of the current agent state for voice calls, as well as a list of the calls that were distributed by T-Server and presented on the agent’s desktop.
In an eServices solution, when ICON registers with Interaction Server to start monitoring agent states, the EventPlaceAgentState reporting event similarly provides ICON with a snapshot of the current agent states for the various media, as well as a list of the interactions that were distributed by Interaction Server and presented on the agent’s desktop.
Agent State Model—SIP Chat
ICON processes the chat media type in agent-state related events received from SIP Server. Data extracted from these events is stored in existing IDB tables. Within these tables, the media type is stored as an integer code in the GSYS_EXT_INT1 field.
Interaction Concentrator supports a simple agent model within each media type. An agent on a DN can have a different state for each media type (for example, the agent state can be Busy for voice but Ready for chat).
SIP Server does not provide information about the media type in the agent’s state–related events (EventAgentLogin, EventAgentReady, EventAgentNotReady, EventAgentLogout). As result, ICON cannot determine the media type from an agent’s state-related event and therefore processes information from received events as applicable to all media types associated with agent’s login session.
Party State Changes
Interaction Concentrator can determine the media type from the calls related to the call party. ICON will process party state changes against agent’s state created for this media type only. Agent’s state for any other media types is not affected by this party state change.
DND State Changes
SIP Server does not provide information about the media type in the EventDNDOn and EventDNDOff events. Interaction Concentrator processes and stores information about changes in DND states regardless of the media type. If more than one media type is configured on a DN, and the agent state is different for each media type, the agent state in the related record will be LoggedIn.
Interaction Concentrator processes and stores information about the ThisQueue attribute for voice media interactions. If the voice media type is disabled on a DN, this attribute will be processed for the chat media type instead.
Handling Stuck SIP Chat Interactions
Interaction Concentrator stores data about all interactions in the G_CALL and G_IR tables. Active voice interactions that were received from T-Server or SIP Server are also stored in the G_CALL_ACTIVE and G_IR_ACTIVE tables s long as they are active (not terminated).
When Interaction Concentrator is restarted, all interactions that are still stored in the G_CALL_ACTIVE and G_IR_ACTIVE tables will be marked as terminated in the G_CALL and G_IR tables.
Login Sessions Model
An agent’s login session starts when ICON receives the first EventAgentLogin event for that agent, either after a period of time during which the agent was not logged on to the switch at all, or after a configurable period of time during which information about the agent was not available (see the gls-max-inactivity configuration option).
If an agent is already logged on to the switch and then either logs on to additional ACDQ or Endpoint objects, or a media type is added or removed, ICON continues the existing login session.
An agent’s login session ends when the agent is no longer logged on to the ACDQ, or if there has been no agent-related activity within the configured maximum inactivity interval.
The following figure represents the login session FSM.
Available Agent State and Login Session Data
This section describes the kinds of agent state and login session data that ICON captures, provided that ICON has been configured to perform this role.
For a high-level summary of the IDB tables in which ICON stores data about agent states and login sessions, see Agent State and Login Session Tables. For more detailed information, see the Interaction Concentrator 8.1 Physical Data Model document for your particular RDBMS.
Agent State and Login Session Data
ICON stores both actual and historical data about login sessions and agent state changes, as well as the associations between agent states, login sessions, and endpoints. ICON tracks changes against different media types independently. The following data is available:
- Current and historical information about agent login sessions.
- Current and historical information about the associations between login sessions and endpoints.
- Note: Multimedia reporting events include information about the agent place, but not about agent endpoint DNs. Therefore, ICON records in the agent activity–related tables do not include meaningful endpoint information for multimedia interactions.
- Detailed information about agent state changes during the agent login session, including:
- Changes to the agent’s state, pending state, workmode, and hardware reason code.
- Time of the state change.
- Other party connections and disconnections.
- Detailed information about the hardware and software reason code changes during the agent login session.
- Note: If Multimedia reporting events include information about reason codes for agent state changes, ICON stores the reason code in the same way it stores hardware reason codes provided by T-Server reporting for voice. Hardware reason codes do not apply to multimedia.
- Detailed information about usage of the DND feature within the agent login session. For voice, DND can be activated and deactivated for individual DNs. For multimedia, DND can be activated and deactivated only for an entire place.
Precalculated Agent State Metrics
In addition to raw object data, ICON stores the following agent state–related statistics:
- Duration of agent state:
- DurationACW (not applicable to Multimedia)
- Duration of agent workmode (not applicable to Multimedia):
After-Call Work and Not-Ready Agent States
After-call work (ACW) is the work that is required of an agent immediately following an inbound call, such as entering data, or making internal calls to complete the transaction. The agent is considered unavailable to receive another inbound call while in this mode. This section describes the functionality of the after-call work and not-ready agent states in Interaction Concentrator.
Uninterrupted ACW or Not-Ready Duration
Interaction Concentrator provides the capability to continue the ACW or NotReady agent state without any interruption due to the agent placing or receiving calls during the after-call work or not-ready period. ICON recognizes completion of after-call work or the end of the NotReady agent state when any of the following occur:
- The agent logs out.
- The agent places himself/herself in Ready mode.
- The agent goes NotReady for any reason other than to perform after-call work. (This includes indirect work mode changes such as when the agent walks away from his desk for a period of time.)
To enable this uninterrupted ACW or NotReady agent state functionality, the gls-enable-acw-busy configuration option must be set to false on the Switch Annex tab.
Interrupted ACW or Not-Ready Duration
ICON also supports the capability to interrupt the after-call work or not-ready agent state when the agent places or receives calls during the ACW or NotReady period. By default, ICON interrupts ACW or NotReady agent states while an agent is handling another call. You can also set the gls-enable-acw-busy configuration option to true on the Switch Annex tab to enable this behavior.
Associating ACW with an Interaction
ICON can associate after-call work with the voice interaction that immediately precedes the start of the after-call work (the first voice interaction), or with the last interaction, which is the default behavior.
In the first case, subsequent voice interactions that occur during the period of after-call work are considered as related to ACW processing and do not interrupt measurement of ACW-related metrics.
To support this functionality, the gls-acw-first configuration option can be set either at the Switch level or on the ICON Application object. ICON uses the value set on the Application for all switches except the SIP switch. For SIP switches, the option must be specified on the Switch level.
Populating Agent Login Session Data
ICON instances that perform the gls role maintain a persistent cache for agent login session data. The agent-pstorage-name configuration option enables you to specify the name of this persistent cache. The default file name is apstorage.db.
When it receives data about login sessions, ICON writes the data from its in-memory queue to the persistent cache as well as to the persistent queue.
If the reported AgentSessionID does not already exist in IDB or the persistent cache, ICON writes the data from the persistent queue into the G_LOGIN_SESSION table in IDB.
If the reported AgentSessionID already exists in IDB or the persistent cache:
- In high availability (HA) deployments, the login session is considered to be a duplicate and is discarded.
- In non-HA deployments, the existing login session is marked as closed (for example, the reason is stuck), and a new session is created.
Data in the persistent cache survives a shutdown and restart of ICON.