Agents Identification in Conversations

This page describes how agents are identified and matched to conversations in the system. It covers how the system links recordings with agents and what information appears on the Conversation Explorer screen in Quality Management. Multiple extensions and shared lines are supported.

As of version 9.4, the backend architecture 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 in Quality Management historical data (for example, because a call extension is assigned to a different agent), the system deletes the previous agent-conversation match and rematch it with the updated agent information.

If the Interaction Service cannot identify any agent — for example, because the administrator configured the system to ignore older data, agents are misconfigured, no agent matches the call segment, or multiple agents match a segment — Quality Management will also have no data, and no agent will be matched to the conversation.

For historical data already paired in Quality Management where the Interaction Service provides no pairing information, Quality Management may fall back and display whatever data is available (usually UserID or GroupID).

Prerequisites

The Agent importer must have been run previously. This ensures that at least one of the following identifiers is saved to the database so that the system can match calls with agents.

For recorded conversations:

• Call Center ID:agentId

• Device ID:deviceId - default settings are described on the Configuring Interaction Service page; refer to the values:

  • Calling Deviceld External Metadata Key for User Identification.

  • Called Deviceld 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, the system relied on the direction of the conversation from the first segment imported to determine calling or called parties. Direction no longer affects party identification.

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

When calls are imported from Call Recording, the system matches agents in this order. As of version 10, these parameters are case-insensitive:

1. Agents with matching agentId

2. Agents with matching deviceId

3. Agents with matching phoneExtension

4. Disabled or deleted agents with matching agentId

5. Disabled or deleted agents with matching deviceId

6. Disabled or deleted agents with matching phoneExtension

Emails and Chats

When new emails or chats are submitted via API, the system looks up agents based on email address 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. The lookup process does not repeat later.

Ambiguity

For agent lookup to work correctly, agent identifiers must be unique. If multiple active agents match during any step of the lookup, the result is ambiguous. In that case, the system selects no agent at all — even if a later step would match just one agent. If multiple inactive agents match, the system ignores that match and continues to the next step.

Each search runs in order. If a match is found based on one criterion, the search stops and does not attempt the remaining criteria. For example, if a call matches on deviceId, the system does not attempt to match on phoneExtension.

Example: Two agents share a phone extension — one ACTIVE, one INACTIVE. The system finds two agents during lookup. It pairs the conversation with the active agent and stops. It does not continue to evaluate other criteria.