This document is a technical solution description of CIM providing brief details on the product features and architecture with all necessary solution prerequisites

Introduction

Customer Interaction Manager (CIM) acts as a single repository to store customer interactions. It receives and retains all interactions of a customer with the call center for tracking a 360-degree view of a customer journey. It provides interfaces to capture real-time and historical information for callers/customers. Administrators can define and extend the contents of the customer and request objects, attaching fields and information to them as per their requirements.

Business Features

Customer Profile & Screen Popup

In CIM, a person approaching the contact center for a query through any channel is a Customer. The schema of the Customer object is extendable so in addition to some predefined attributes, an administrator can also add more custom attributes based on their business needs. This helps to define what data each company would like to store for its customers. Customer attributes with the following data types can be defined:

Text: This could be any string up to 1000 characters long.
Phone: This is to store any additional phone numbers of the customer
Email: This stores the Email ID
Date: This could be any data of type Date.
DateTime: This could be any data of type DateTime.
URL: This could be any data of type URL.
Bool: This could be any data of type Bool. This can correspond to any flag which is either set to 'true' or 'false'.

Authorized users can upload and manage customer profiles. Customer profiles can also be imported in bulk using CSV files.

When a customer call lands on Cisco Finesse, the CIM application automatically looks up the customer profile based on the ANI and pops up the right profile in front of the agent (if the customer already exists). If it does not find any matching record, it provides the agent with the interface to create a new profile itself for the customer on call.

CIM also exposes APIs for third-party applications to read and push data from/to CIM. So the agents can avoid switching screens between the CRM and Finesse desktop to view the complete customer profile while dealing with the customer call.

All customer records are listed on the Customers List page with filtering, sorting, searching capabilities.

With the Customer list, you can:

Drag n drop columns to reorganize the list view. Each column here represents one attribute in Customer schema.
Sort the customer list (ascending/descending) based on any column by clicking on the ascending/descending arrow icons. By default, the list is sorted based on the creation date of the record in descending order; i.e. the latest created being on the top.
Page-wise navigation with the page index of the current page
Resize columns, change the width according to the view preferences
Column search. Search based on multiple columns is not yet available.

At a time, 100,000 customer records can be imported via CSV.
The bulk import operation should only be performed in off-peak hours.
CIM currently only supports up to 50 custom attributes
Two customers with the same ANI/phone cannot exist. Each customer in CIM is supposed to have a unique Phone number. A phone number can be duplicated among all phone numbers of a single customer but cannot be duplicated across different customers.
If a new customer record with a different name but with the same existing phone number is created, the existing customer profile will be overwritten/replaced with the new customer profile.

Interactions

CIM stores customer's interactions as they interact with the Cisco call center. This includes both IVR, agent-based voice interactions.

Therefore, each time when the customer calls in, the CIM agent gadget is automatically loaded with the customer's profile and its previous interaction history. At the end of the active call, the call is automatically linked to the already popped up customer profile. However, agents also have the capability to change the association and link the call to another, most appropriate customer based on the conversation with the customer.

This way, while dealing with the customer, agents become fully aware of the customer's recent interactions and see why and how repeatedly, the customer had called in the past.

Each interaction is made up of smaller units, called Activities. A CIM activity could be:

An IVR leg in a parent call
An agent-transferred call leg (this includes IVR- Agent, Agent-Agent transfer)
Wrap-up added by agents to a call

On the Interaction History gadget, you can expand to view all activities tied together in an interaction.

The following details are available on the interaction history view:

Field	Description
Customer Profile	Lists the complete profile of the customer in a collapsible mode
DateTime	This shows the date when the call was received while individual times in each activity shows the start time of the activity.
ANI	The phone number of the customer from/to which the call was received/ initiated
Call Wrap up(s)	Finesse Wrap-ups provided by each agent in the call.
Duration	The duration of the interaction bar shows the total duration while the duration for each individual activity is also shown under the activity details
Call Type	Shows with an arrow if the call was INBOUND or OUTBOUND. The arrow direction is inward to show an inbound call and outward to show an outbound call.
Interaction Type	This shows, "Finesse" in case if the call includes all agent activities; i.e. if the call was transferred to an agent. Shows "IVR" if the call includes IVR activity only.
Agent ID	This shows the ID of the agent who handled the call.
Team Name	Shows the name of the team to which the agent belongs
Agent Extension	Shows the extension of the agent under details of the Agent Activity
Start Time	This shows the time when the call was landed on the Finesse desktop

CIM also exposes APIs for third-parties to push an interaction to CIM.

In the case of call transfer, the interaction context is not transferred yet. This also means that if the agent A has changed the link of the active interaction to a different customer based on his conversation with the customer, the Agent B to whom Agent A had transferred the call, won't be able to see the updated customer link.
If an agent applies multiple wrap-ups during a call, the most recently applied wrap-up will be recorded at the end of the call.
At the moment, the application does not store any barge in, consult and silent monitoring call legs or activities as part of the customer interaction. However, it stores call conference, call transfer activities as part of the interaction.

Click-to-dial call

Agents can manually initiate a call to a customer while viewing their profile.

Outbound calls are also stored as the customer's interaction history and available to the agent for subsequent interactions.

Manual Outbound calls are initiated through Finesse. So the user must have to be on Finesse to use this feature.
Screen popup does not happen in the case of dialing a call manually
Automatic Screen popups work in case of campaign outbound calls

Click-to-SMS

Agents can also manually initiate an SMS to a customer while viewing their profile.

Extend Customer Object Schema

Add custom attributes to the Customer object based on your business needs.

System administrators or users with an “Admin” role can extend the schema of the Customer. The user can add as many as 50 customized attributes to store information of their customers based on the needs of the business.

The attributes in the schema can also be re-ordered to change the order of the display. The order changes from here affect the order in which the fields are shown in the Customer Profile View.

Workflow

Customer call rings on Finesse Agent Desktop.
The application looks up the customer record based on the ANI.
If a matching record is found, the customer profile is popped up in front of the agent. The interaction automatically gets linked to the selected customer. To link the call with a different customer, choose the right profile from the Customer list sidebar on the Interaction History page and click the Link button.
If no existing record is found against the ANI, the application provides the options to choose an existing customer manually or create a new customer profile. To link the call with an existing customer, choose the right profile from the Customer list sidebar on the Interaction History page and click the Link button.

If the agent or supervisor does not accept the call (after the call has landed on the Finesse desktop), the call interaction is still stored in CIM, tagged with the agent name to whom it was routed.

Solution Architecture

CIM Profiles & Interactions mainly consist of the following objects:

Customers - Every contact approaching the system through any channel is identified as a customer
Interactions - An interaction stores information about the communication taken place through the respective channel.

All client applications including IVR, Finesse gadgets, and 3rd party applications access CIM via REST APIs to fetch and store information from, to CIM.

Deployment Models

Non-Redundant/ Simplex Deployment

For a non-redundant deployment, the application Docker images are deployed on a single server without with a single point of the application failure.

High Availability / Duplex Deployment

For high availability, the solution is configured on a three-node cluster. Primary and Secondary nodes have Docker images running while the Arbiter node does the load-balancing.

The two (primary, secondary) will have everything running as if the Secondary node is a replica of the Primary node. Each node of the cluster exposes a VIP (Virtual IP, using VRR protocol) which will route the service request to the active primary node at any point in time.

The two nodes are synchronized with KeepAlived enabled. As soon as the primary node is down, the secondary node resumes services and acts as primary. Thus, the failover from primary to secondary happens nearly seamlessly provided that KeepAlived is running.

The Arbiter node does not replicate the data. Its purpose is to participate in the election process while electing a primary node.

Elections occur when the primary becomes unavailable. The remaining nodes in the replica set, i.e. arbiter and secondary nodes call for an election to select a new primary so that the cluster resume normal operations. The failover from primary to secondary happens nearly seamlessly.

Fault Tolerance

This three-node cluster design ensures that the system is available if the primary or the secondary is unavailable. If the primary is unavailable, the Arbiter will elect the secondary to be primary.

However, if both the primary and the arbiter are down, the secondary will not be elected for the read/write operations.

Note:

Each Node represents a VM.
At any given point of time at-least two nodes should be up.
For the hardware resilience, these nodes/VMs should be on two physical servers. If all the VMs are deployed on the same physical server, it will provide only VM level resilience and fault tolerance.

Failover scenarios

When the Primary or Secondary node is down
The system will switch to the other active node.
Impact		All applications will continue to work after the seamless failover.
Recovery		NA

When Primary and Secondary nodes are down

Impact		All applications and services will not work.
Recovery		The manual intervention is required to recover the system.

When primary or secondary CIM datastore is down
The load-balancer (Arbiter) elects the datastore instance on the other node as primary.
Impact		All read/write operations on the CIM datastore will continue to function seamlessly.
Recovery		NA

When primary and secondary CIM datastores are down

Impact		All read/write operations on the datastore will fail.
Recovery		The manual intervention is required to resume the datastore operations.

When CIM primary data store and the Arbiter are down

Impact		All write operations on the primary datastore will fail. The read operation (if configured to be read from secondary DB) will continue to work normally.
Recovery		A manual intervention is required to resume the datastore write operations.

CIM secondary data store and the Arbiter are down

Impact		All write operations on the secondary data store will fail. The read operations will continue to work normally.
Recovery		A manual intervention is required to resume the datastore write operations.

The Arbiter is down

Impact		All read/write operations on the datastore will continue to function seamlessly.
Recovery		NA

Solution Security

Permissions-based User Access

ExpertFlow applications have a central authentication module that automatically synchronizes contact center supervisors and agents from CCX/E into the User Management module. This allows any contact center user to log into the application using the same Finesse credentials without the need to recreate the user credentials in the application again.

With the latest version, the application also allows administrators to create local user accounts for supervisors or/and agents with a user-defined password and username. Restricted permissions on the level of entities allow administrators to assign selective privileges to a particular group of users.

Note:

Currently, the permissions can only be granted on selective lists/entities. More granular permissions on the level of selective fields or certain data cannot be granted.
The password reset option is not available for local users. If a local user has forgotten his password, he needs to request the admin to create a new account to get logged in.

HTTPS Support

For HTTPS support, provide a valid certificate from a certified Certificate Authority (CA).

Solution Prerequisites

Hardware Sizing

The following lists the machine specifications for up to 100 concurrent agents deployment.

vCPU	vRAM	vDisk
2 cores	8 GB	1x100 GB

To support HA, the same specifications would be doubled for the two machines for a redundant deployment.

To get machine specifications for a larger agent volume and/or with other ExpertFlow products in a co-resident deployment, please check here.

Software Requirements

Port Utilization

The following ports should remain open on the Firewall. The local security policy and any antivirus should also allow open communication on the following ports.

Type	Source Host	Source Port	Destination Host	Destination Port
HTTP	Enterprise web user	any	CIM	80
HTTPS	Dashboards & Wallboards server	any	CIM	443
TCP	Enterprise web user		CIM	9242

System Access Requirements

Deployment Privileges

Administrative privileges (root) on the machine are required to follow the deployment steps.

Internet access must also be available on the Wallboard machine with inbound connections on port 9242 enabled.

Time Synchronization Requirements

If the system dates and times are not synchronized, the system can produce unpredictable results. Therefore, the EF applications and Cisco Contact Center should have their time zone and date/time properly configured, according to the geographic region and must be synchronized.

To configure the time zone, please see the instructions from the hardware or software manufacturer of the NTP server. The application servers should be synchronized. This synchronization should be maintained continuously and validated on a regular basis. For security reasons, the Network Time Protocol (NTP) V 4.1+ is recommended.

Solution Reference