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. 

When conversations are imported into the Conversation Explorer Search Engine platform matching occurs. This page provides an overview of the rules and processes used to identify and match Agents to conversations.

Prerequisites

In order 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: 

• Call Center ID: agentId
  
• Email: mailid
  
• Phone extension: phoneExtension
  

If an agent uses multiple phone numbers, only one phone number can be used to pair the agent with the interaction. At this time, multiple extensions are not supported – Eleveo can not ensure that the same number is used every time. 

If the user importer imports multiple phone numbers, or a user defines multiple numbers, only the first number is used. (This behavior is known from the CUCM importer.)

Identification of Calling and Called Parties in Conversations

We rely on the direction of the conversation from the first couple/segment imported into our system to determine called/calling parties. The system then attempts to match the calling or called party with an agent within the system. See General matching criteria.

If the call direction is:

1. Outbound – we expect that the calling party is an agent (and then attempt to identify the agent based on the rules in the section General matching criteria) and the called party is marked as a customer (no identification of that party occurs).
2. Inbound  – then we expect that the calling party is a customer and the called party is an agent (and then attempt to identify the agent based on the rules in the section General matching criteria).
3. Internal – then we expect that both parties are agents and the system attempts to identify both of them based on the rules in the section General matching criteria.
4. Unknown – the system attempts to identify an agent from both calling and called directions based on the rules in the section General matching criteria.

General Matching Criteria

Agents are imported with various statuses, such as ACTIVE or INACTIVE. Deleted agents are not considered at all.

Agents are matched based on various fields depending on how the conversation is imported. If the conversation participant type is Unknown the system also attempts to match agents to the conversation.

Calls from Call Recording

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

1. Agents with matching Call Center ID
   and then
2. Agents with matching phone extension
   and then
3. Disabled/deleted agents with matching Call Center ID 
   and then
4. Disabled/deleted agents with matching phone extension

NOTE

For centers using an autodialer. The Conversation Explorer displays such calls with the properly assigned initiating agent and with an outbound call direction.

Matching - Calls

Data from Call Recording is not copied over to the Conversation Explorer storage, so the agent lookup, in this case, is repeated when the conversation is changed or even just shown in the search results. If a conversation is ever modified, the result of the current agent lookup will be indexed for search, including the current agent's group.

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 persists 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 there are multiple agents 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.

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 Call Center ID 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 Call Center ID. If multiple agents are sharing a phone extension, ensure that the agents have distinct Call Center ID's.

What to do if the same call center ID is/was used by two agents and media is re-imported

What happens if the same call center ID is used by two different agents at or around the same time (for example, one agent leaves the company and a new agent is given the same ID) and media is reimported?

• Eleveo does not record historical data related to which agent works at a given time. The current agent registered to a specific ID at the moment of import is shown as the agent for all media (calls) linked to that ID(even those calls performed by a previous agent assigned the same ID). This means that old calls may be associated and displayed with the incorrect agent!

What to do if media is paired to the wrong user

If media (calls, for example) are incorrectly paired it is necessary to perform the following steps:

1. User pairing must first be corrected in User Management - for agent identification or the contact(s). It is necessary that the Attributes phoneExtension and agentId be correctly set in User Management.
2. Refresh or Reload the Internal User list
3. Media (call) must be marked as 'dirty' in the Call Recording database

4. Media must be re-imported

   Click here to expand...

   Re-import media in order to ensure that duplicated or miss-matched content is removed from the search results in Quality Management. The re-import solves a known issue with duplicated conversations and corresponding erroneous behavior in the specific upgrade path, such as an inability to review duplicated conversations or play older reviews.

   Steps to re-import conversations:

   1. Delete the files `/opt/zoomint/data/encourage-scheduler/reports/enc-scheduler-report-zoomcr-calls-historical.json` and `/opt/zoomint/data/encourage-scheduler/reports/enc-scheduler-report-zoomcr-calls.json`

   2. Restart the service from the command line to enable the changes!

      CODE

      kubectl rollout restart deployment encourage-scheduler

   3. Open /opt/zoomint/data/encourage-scheduler/reports/enc-scheduler-report-zoomcr-calls-historical.json
Look for a line that says "complete". The process is finished when it says "true".

      An example of this is visible in the report file for zoomcr-calls-historical:

      CODE

      {
        "taskId" : "zoomcr-calls-historical",
        "timestamp" : "2019-01-30T10:00:52.623268Z",
        "complete" : true,
        "errors" : [ ],
        "size" : 95913,
        "from" : {
          "lastUpdated" : "1970-01-01T00:00:00Z"
        },
        "to" : {
          "externalId" : "1",
          "lastUpdated" : "2016-12-05T20:28:46.753Z"
        }
      }

      The notable fields are:

      • timestamp: indicates the time this file was generated
      • complete: indicates the status of the process
      • errors: indicates any error during the process
        
      • size: indicates number of rows displayed within the QM Conversation Explorer before the process occurred (one row in the Conversation Explorer may contain multiple calls or events)

Conversation Explorer Representation

What is displayed on the Conversation Explorer screen as a result of the pairing process (various scenarios):

Participant IS NOT matched:

Participant IS matched: