Agent Ready But Not "ICM Available"
Ensure all agents are logged out
- Using Search, find the ActivityID of an integrated agent's previously-completed chat activity.
- Note the ActivityID, then log out
- In the eGActiveDB's table egpl_casemgmt_activity, update this ActivityID's activity_status to 5000 and activity_sub_status to 5900
Agent logs in and is ready, but receives no emails or chats. From the ICM Script Editor we can see that the user is Logged In and Ready, but not ICM Available in both EIM and WIM skill groups.
ICM Available & MRD Interruptibility
ICM Available is defined in the ICM Schema Guide: "An agent is ICM available if s/he is Routable and Available for the MRD. This means that the agent can be routed a task by ICM software."
When a user is ready but not ICM Available in a skill group (i.e. email), this typically means that they are working on a non-interruptible task in another skill group (i.e. chat). Per the CIM SRND, Media Routing Domain (MRD) interruptibility should be configured as follows:
The first step would be to confirm the MRD interruptibility is all configured properly. If the email skill group is marked as non-interruptible, then agents will not be shown as ICM Available for chat when working on emails. We can see below that the Email MRD is marked correctly as Interruptible.
What does the Agent see? Are they overlooking something?
Sometimes an agent may not realize that they have a chat that has ended but not yet been completed sitting in their Chat Inbox. Confirm what the agent sees in both of their inboxes. In this case, the agent has 0 activities in the Chat Inbox and Main Inbox, and is ready for both Chat and Other Channels.
What has the Agent been doing lately?
We need to look at some recent activities handled by the agent and see if there is anything odd shown. To start, we need to know the eGAgentID - the agent's USER_ID in EIM/WIM.
SELECT * FROM egpl_user WHERE user_name = 'JDoe'
Our agent's USER_ID is 1002, so we can look for recently-handled activities by the agent - i.e., the last 50 activities.
select top(50)* from egpl_casemgmt_activity where assigned_to = 1002 order by WHEN_MODIFIED desc
We can see amid all of the completed activities with ACTIVITY_STATUS=9000 and ACTIVITY_SUB_STATUS=9100 that there is one activity with ACTIVITY_STATUS=5000 and ACTIVITY_SUB_STATUS=5900. Using the tables available in the 4.3 Troubleshooting Guide, we can break down ACTIVITY_ID=1113:
Activity 1113 is likely the cause of our agent not being ICM Available.
What Happened with Chat 1113?
Can we view the Audit Trail?
We can first search for the activity to check the audit trail. However, in this case, the chat is still "In Progress" so we won't find much more than we already know.
The rest of this investigation will have to be done in the database. Looking at the eglv_attendee table, we can see the attendees of a chat session.
SELECT * FROM eglv_attendee where activity_id = 1113
Using the 4.2 Schema Guide, we can translate the AGENT and STATUS columns.
- AGENT: This specifies whether the attendee is an agent or customer.
- 1: Agent
- 0: Customer
- For our activity, we see two ATTENDEE_ID's - 1 AGENT and 1 Customer.
- STATUS: This column stores the status of the attendee in the session. An attendee (customer or agent) can be participating in the session or have left it.
- 1: Session assigned
- 2: Session closed
- For our activity, we can see that both attendees have closed the session.
Let's Complete It!
Our investigation has concluded that this activity has already completed and should be marked as such. We can do a simple update query in the eGActiveDB to resolve this issue.
UPDATE egpl_casemgmt_activity SET activity_status = 9000, activity_sub_status = 9100 where activity_id = 1113
The agent must log out and log back in again for the change to be reflected. Once this is done, the ICM Script Editor's Real Time Monitor confirms that the completed chat resolved the ICM Availability issue.
Something went wrong when the activity was being completed and caused the egpl_casemgmt_activity columns ACTIVITY_STATUS and ACTIVITY_SUB_STATUS to not be updated to reflect the completion. This is commonly seen in scenarios where chat sessions were active when services were stopped or network connectivity was lost. Environments experiencing instability problems are more prone to this type of issue than others.