Agents Identification in Conversations

Quality Management Agent Identification

This page provides information about how agents are identified and then matched to conversations in the system. After reading this page, you should understand how the system links recordings with agents/users and what information is then shown on the Conversation Explorer screen in Quality Management. 

This page provides an overview of the rules and processes used to identify and match agents to conversations.

Important change in 9.4+
As of version 9.4 the backend architecture has changed. The system now relies on the Interaction Service and its agent pairing mechanism.
If the Interaction Service identifies a different agent than the one that Quality Management has in its historical data (because the call extension is assigned to different agent, for example) then the system will delete the previous agent-conversation match, and it will be rematched with the newly updated agent information.
If the Interaction Service is not able to identify any agent (this may happen if the administrator has configured the system to ignore older data, or if agents are misconfigured, no agent matches the call segment, or multiple agents match a segment), then Quality Management will also have no data and no agent will be matched with the conversation.

Multiple extensions and shared lines are now supported.

Prerequisites

To function as expected, the Agent importer must have been run previously. This ensures that at least one of the following identifiers will be saved to the database so that we can match calls with agents: 

For recorded conversations:

• Call Center ID: agentId

• Device ID: deviceId (default settings are described on the page Configuring Interaction service, refer to the value Calling Device External Metadata Key for User Identification)

• Phone extension: phoneExtension

For Emails and Chats:

• Email: user email

Identification of Calling and Called Parties in Conversations

In previous versions of Quality Management, we relied on the direction of the conversation from the first couple/segment imported into our system to determine called/calling parties. Starting with version 9.4, direction no longer has any effect on the identification of parties in conversations.

General Matching Criteria

Agents are imported with various statuses, such as ACTIVE or INACTIVE.

Depending on how the conversation is imported, agents are matched based on various fields.

Calls from Call Recording

Whenever calls are imported from Call Recording, the corresponding agents are matched in this order (case sensitive):

1. Agents with matching Agent ID
   and then

2. Agents with matching Device ID
   and then

3. Agents with matching phone extension
   and then

4. Disabled/deleted agents with matching Agent ID
   and then

5. Disabled/deleted agents with matching Device ID
   and then

6. Disabled/deleted agents with matching phone extension

Technical note -

• If successfully identified, the user identification process will never be performed again for the identified party (calling/called). As a result, changes to the identified user in User Management after this will not affect the saved information.

• If user identification for a particular party (calling/called) is not successful, user identification will be reattempted the next time the segment is accessed.

• Administrators can completely disable user identification for older segments via the "User Identification - Skip Before" configuration option for the Interaction Service in Rancher.

Emails and Chats

When new emails or chats are submitted via API, the corresponding agents are looked up in a similar fashion, but based on email addresses only:

1. Agents with matching email (case insensitive)

2. Deleted agents with matching email (case insensitive)

Matching - Emails and Chats

The results of this pairing persist in the Conversation Explorer storage, and the lookup process is NOT repeated later.

Ambiguity

For agent lookup to work correctly, the agent identifiers must be unique. If multiple active agents are matched during any step of the lookup, the result is considered ambiguous. This means that no agent will be selected at all, even if one of the next steps would potentially match just one agent. However, if multiple inactive agents are matched, then the match is ignored, and the next step is still attempted. The system will attempt to match calls to agents in the usual order. 

Each of the distinct searches is performed in order, if a match is found based on one of the above-listed criteria the search will stop attempting to find matches based on other criteria which follow! If a call matches based on the criteria Agents with matching deviceId then the system will not even attempt to match based on the phone extension!

Example: if there are two different agents with a matching phone extension, and one agent is ACTIVE, one INACTIVE then two agents will be found during lookup. The conversation will be paired to the active agent, and the process will stop. The system will not continue to process any other criteria!

Suggested Resolution: Check that all agents have unique Agent ID. If multiple agents are sharing a phone extension, ensure that the agents have distinct Agent ID's.