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.

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:

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

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.  

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.  

1. Customer call rings on Finesse Agent Desktop.

2. The application looks up the customer record based on the ANI.

3. 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.

4. 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. 

CIM Profiles & Interactions mainly consist of the following objects:

1. Customers -  Every contact approaching the system through any channel is identified as a customer

2. 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.

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.

Failover scenarios

Permissions-based User Access

HTTPS Support

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

Hardware Sizing

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

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.

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.