Since there is no API limit for the client-side dumping, the information associated with Call Activities are dumped on the client-side instead of the Server-side preferably. As a result, some important information that is only available after the call is over, such as Call Duration, was not being passed. It has been handled now. In Ameyo Application Server 4.81, the Professional Services Team has been enabled to perform the Server-side Dumping of the activities and parameters.

The Customer Information (including Customer ID, Customer Name, Customer Phone Number, and others) will be passed to the server. The Call Activities will be dumped on Server-side using the Post Processing Nodeflow. The objects attached to the call, such as a ticket or an account, will also be passed to the server so that it can be displayed in the CTI pop-up to the agent so that the agent is in more context of the customer.

If Client-side dumping is also allowed along with Server-side dumping, then there can be conflict because similar objects can be available at both client-side and server-side. By default, there will be client-side dumping. A toggle switch has been added in the interface of Administrator Console to enable or disable the server-side dumping in the Toolbar Integrations.

The Administrator has to enable the Server-side dumping using this option. As soon as the server-side dumping is enabled, then the client-side dumping will be disabled automatically and vice versa.

We recommend enabling the server-side dumping so that all relevant information is available.

The client-side dumping is enabled by default. However, the Ameyo Customer can enable the server-side dumping from the User interface.

APIs are available now for dumping the information to the server. As per the business requirements, the Professional Services Team can change the fields that have to be dumped on the server-side.

In case of Server-side dumping, API limits available in the associated account of the third-party CRM have to be taken care of. If the API limit is over, then the API request will fail.

Authorization

OAuth is used for Authorization in Ameyo Toolbar Integrations with Microsoft Dynamics, and Salesforce. OAuth is an open-standard authorization protocol or framework that provides applications the ability for "secure designated access". It allows the applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account.

Whereas token-based authorization is being used in Ameyo Toolbar Integrations with Freshsales and Freshdesk Mint, which requires an API key to enable the Server-side dumping, and it has to be provided by the Administrator on the interface itself. Token-based authentication is a web authentication protocol that allows users to verify their identity a single time and receive a uniquely-generated encrypted token in exchange. For a designated period time, this token is how users access protected pages or resources instead of having to re-enter their login credentials.

Debug the Server-side Dumping

There can be some cases in which the Server-side dumping will not work. In such cases, the debugging is required.

Enabled Server-Side Dumping in Microsoft Dynamics using Post Processing Nodeflow

By default, the client-side dumping will be enabled. The Administrator has to enable the Server-side dumping from the interface. OAuth is being used to authorize the Ameyo Toolbar Integration with Microsoft Dynamics. Once enabled, the phone call activity will be created from the server-side, which contains the following items.

• subject: It contains the generic information related to call activity like date, agent who has handled the call, and others.

• phonenumber: It contains the customer’s phone number used to make or receive the call.

• description: It contains the additional information/notes captured by the agent while on call.

• new_disposition: It contains the dispositions of the call activity.

• new_subdisposition: It contains the sub-dispositions of the call activity.

• new_recordinglink: It allows the Ameyo Application Server to record the calls and store their recordings.

• new_agent: It stores the agent name associated with the call activity.

• new_association: It mentions the object associated with the call activity.

• directioncode: The direction specifies whether the call is redirected from the agent to the customer (outbound) or or from the customer to the agent (inbound). "directioncode" would be "inbound" or "outbound".

The supported fields including Call Duration, Call Start time, and Call End Time will be dumped in the text format in "Description".

The following screenshot displays the Administrator's option to enable the server-side dumping for Microsoft Dynamics.

Important Information

In Toolbar Integration with Microsoft Dynamics, a feature from client-side dumping is being provided. That is, while disposing of, if the call is not attached to any customer and "unAttachDefaultRecordTypeCreationRequired" parameter is configured as "true", then the customer is created first and then activity is created.

However, if server-side dumping is enabled and client-side dumping is disabled, this feature will not work. As when agent dispose of the call from interface, and CRT removal and Creation of Customer on CRM will run parallelly and there can be a race between these two tasks. Sometimes the activity will be associated to newly created record and sometimes it will not be associated.

Enabled Server-Side Dumping in Salesforce using Post Processing Nodeflow

By default, the client-side dumping will be enabled. The Administrator has to enable the Server-side dumping from the interface. Once enabled, the task will be created from the server-side, which contains the following items.

• subject: It contains the subject of the ticket or object created for the call.

• disposition: It contains the disposition of the ticket or object created for the call.

• sub-disposition: It contains the sub-disposition of the ticket or object created for the call.

• Created date: It contains the date when the call activity is created.

• Description: It contains the additional information about the ticket.

• CRT_ID: It contains the CRT_ID for the call made or received.

• recording_URL: It contains the URL to the call recording stored in the Ameyo Application Server.

The supported fields including Call Duration, Call Start time, and Call End Time will be dumped in the text format in "Description". The Activity will be created for the Salesforce Lightning for customer found, created, or attached from the interface.

The following screenshot displays the Administrator's option to enable the server-side dumping for Salesforce.

Enabled Server-Side Dumping in Freshdesk Mint using Post Processing Nodeflow

By default, the client-side dumping will be enabled. The Administrator has to enable the Server-side dumping from the interface. Once enabled, the ticket will be created from the server-side, which contains the following items.

• phone: It contains the customer’s phone number using which the call is made or received.

• Description: It contains the additional information in the HTML format.

• Priority: It contains the priority of the ticket or object created for the call.

• Status: It contains the status of the ticket or object created for the call.

• Subject: It contains the subject of the ticket or object created for the call.

The supported fields including Call Duration, Call Start time, and Call End Time will be dumped in the text format in "Description".

Token-based Authorization will be used. The Administrator has to provide the API Key for authorization and enable server-side dumping. Refer to the following screenshot.

Enabled Server-Side Dumping in Freshsales using Post Processing Nodeflow

By default, the client-side dumping will be enabled. The Administrator has to enable the Server-side dumping from the interface. Once enabled, the manual call leg will be created from the server-side, which contains the following items.

• Direction: The direction specifies whether the call is redirected from the agent to the customer (outbound) or or from the customer to the agent (inbound).

• Description: It contains the additional information for the ticket in HTML format.

The supported fields including Call Duration, Call Start time, and Call End Time will be dumped in the text format in "Description".

Token-based Authorization will be used. The Administrator has to provide the API Key for authorization and enable server-side dumping. Refer to the following screenshot.

Enabled Server-Side Dumping in Zendesk using Post Processing Nodeflow

By default, the client-side dumping will be enabled. The Administrator has to enable the Server-side dumping from the Interface. OAuth is being used to authorize the Ameyo Toolbar Integration with Zendesk. Once enabled, the ticket will be created from server-side, which contains the following items.

• phone: It contains the customer's phone number for which the call is made or received.

• Description: It contains the additional information in the HTML format (if supported).

• Subject: It contains the subject of the ticket or object created for the call.

• Disposition: It contains the disposition.

• Sub-disposition: It contains the sub-disposition.

• Comments: It contains the comments, if any.

The supported fields including Call Duration, Call Start time, and Call End Time will be dumped in the text format in "Comments". The following custom fields can also be created.

• Call Type

• Talk Time

• Disposition Code

The Administrator has to authorize the Zendesk access and server-side dumping in the interface.

In the contact center industry, the two-level disposition is very common. The agents are selecting a category of the disposition (that is "Disposition Class") and then selecting a disposition (that is "Disposition Code"). If you take an example of an agent who is staffed to the marketing campaign of a banking process where the agent has to dispose of the conversation in two parts containing category (such as "Banking Account" or "Credit Card") at the first level and then result ("Interested" or "Not Interested") at the second level.

Almost every Ameyo Client is defining both Disposition Class and Disposition Codes. After the introduction of the configuration of two-level disposition and its tree-level structure, mostly the Ameyo Clients are switching to two-level disposition. Seeking this, two-level disposition has been made default in Ameyo 4.81 GA.

The User can still perform the backend configuration to enable the one-level disposition.

Refer to the following screenshot of the two-level disposition for a call.

Figure: Two-level Disposition for Call in Ameyo Toolbar Integration with Freshdesk Sales

In a contact center, the agent has to switch between the different campaigns as per the business requirement. Suppose a Contact Center has mapped each language to a campaign. For example, there is a campaign (say US1) for US English, and the second campaign (say UK2) is for UK English. Then the agent might be required to switch the campaigns whenever the call has to be made for the designated country.

In the case of Ameyo Toolbar Integration, earlier, there was a configuration, but that can be done only once during the logon. If the agent has selected multiple campaigns, then the agent has to select a default campaign between them during the logon. However, the agent can change the default one or change its selection of campaigns using "Change Campaign" option.

But there was no such configuration that allows the agent to select a campaign while making a manual dial outbound call in real-time as available in the Application Server.

Now, such a configuration named "isCampaignSelectionOnManualDialEnabled" is available that allows the agent to select a campaign in real-time while making a Manual Dial Outbound Call else the agent will be making the manual dials using the default campaign selected.

If this parameter is configured as "True", then a pop-up will be displayed while making a manual dial call in which the user can select the campaign to make the Manual Dial Outbound Call.

Refer to the following screenshot.

Figure: Select the campaign while making a manual dial call in Toolbar Integration

Custom Objects can be created in the Customization Settings of Microsoft Dynamics. After creating the custom object, the user can perform the backend configuration at the Server running Ameyo AppServer to use that custom object in Ameyo AppServer.

If you take an example of "cr757_developer" custom object created with cr757_name, cr757_company, cr757_developerid attributes, then you have to run the following query.

The changes in the following query are highlighted with yellow color.

			insert into integration_profile_settings(contact_center_id, integration_type, domain, integration_generic_settings) 
				values(1, 'MSD_CIF', 'https://dacx.crm8.dynamics.com', 
				'{"defaultRecordTypeToBeCreated":"cr757_developer",
				"searchRecordTypes": ["cr757_developer"],
				"recordTypesVsRecordSearchFields": {
					"contact":["telephone1"],"lead":["telephone1"],"cr757_developer":["cr757_phone"],"account":["telephone1"]
					},
				"ameyoFieldsVsRecordFields": {
						"contact":{"customer_phone":"telephone1","customer_phone1":"mobilephone"},"account":{"customer_phone":"telephone1"},"lead":{"customer_phone":"telephone1"},"cr757_developer":                              {"customer_phone":"cr757_phone","customer_name":"cr757_name"},"incident":{"customer_phone":"telephone1"}
					},
				"isAdditionalMappingRequired" : true, 
				"isDefaultRecordTypeCreationRequired" : true, 
				"unAttachDefaultRecordTypeCreationRequired" : true, 
				"unAttachDefaultRecordTypeToBeCreated" : "contact", 
				"attachNewRecordTypeCreationSet" : [
						"Account", "Contact", "Lead", "Opportunity","cr757_developer"
					],
				"attachNewRecordTypeAttributeMapping" :  {
						"lead" : {"phone" : "telephone1"}, "contact" : {"phone" : "telephone1"}, "account" : {"phone" : "telephone1"}, "cr757_developer" : {"phone" : "cr757_phone","name" : "cr757_name"}
					}, 
				"recordTypeVsRequiredAttributes" :  {
						"cr757_developer" : ["cr757_phone", "cr757_name","cr757_company"]
					},
				"recordTypeVsDefaultAttributeValues" :  {
						"cr757_developer" : {"cr757_name" : "Unknown" , "cr757_company" : "Ameyo"}
					},
				"recordTypeVsRecordData" :  {
						"cr757_developer" : { "displayText" : "cr757_name","name" : "cr757_name", "number" : "cr757_phone","pluralName" : "cr757_developers", "recordId" : "cr757_developerid"}
					}}');

		

If any object (contact, account, or lead) is created or opened on an agent's screen as a result of CTI (whenever a call is made), then the same object (contact, account, or lead) will be displayed during re-ACD, call conference, or call transfer in CTI Pop-up at the side of receiving agent. It means that the context of the call (that is the object) is also transferred automatically during the call transfer or call conference.

Earlier, the entries to configure Ameyo Toolbar Integration for Salesforce Lightning were being entered in in "server_preference_store" table. However, now these entries will have to be recorded in the "integration_profile_settings" table.

In the following query, the changes are highlighted with the yellow color. These changes will impact the selection of the default object that will be created or modified whenever a call is made to or received from a phone number.

INSERT INTO integration_profile_settings (contact_center_id, process_id, integration_type, domain, consumer_id, 
integration_generic_settings, integration_specific_settings)
	VALUES(1,NULL,"SALESFORCE_LIGHTNING","https://ap5.lightning.force.com",NULL,    
	'{ 
		"searchRecordTypes" : [ "Account", "Case", "Contact", "Lead", "Opportunity" ],
		"ameyoFieldsVsRecordFields" : 
			{ 	"Account" : 
					{  "customer_email" : "email", "customer_name" : "name", 
					"customer_phone" : "phone", "customer_mobile" : "mobile" },
				"Contact" : 
					{  "customer_email" : "email", "customer_name" : "name", 
					"customer_phone" : "phone", "customer_mobile" : "mobile" },  
				"Lead" : 
					{  "customer_email" : "email", "customer_name" : "name", 
					"customer_phone" : "phone", "customer_mobile" : "mobile" },  
				"Case" : 
					{  "customer_email" : "email", "customer_name" : "name", 
					"customer_phone" : "phone", "customer_mobile" : "mobile" },
				"Opportunity" :
					{  "customer_email" : "email", "customer_name" : "name", 
					"customer_phone" : "phone", "customer_mobile" : "mobile" }
			}, 
		"recordTypesVsRecordSearchFields" : 
			{ "Contact" : [ "phone" ], "Lead" : [ "phone" ], "Account" : [ "phone" ],
			"Opportunity" : [ "phone" ], "Case" : [ "phone" ] }, 
		"isAdditionalMappingRequired" : true, 
		"defaultRecordTypeToBeCreated" : "Account", 
		"isDefaultRecordTypeCreationRequired" : true,
		"unAttachDefaultRecordTypeCreationRequired" : true, 
		"unAttachDefaultRecordTypeToBeCreated" : "Account", 
		"attachNewRecordTypeCreationSet" : [ "Lead", "Case", "Contact", "Account", "Opportunity" ] 
	}',
	'{ 
		"showTwoLevelDisposition" : false, 
		"disposeInCurrentView" : false, 
		"opportunityStageName" : "Prospecting", 
		"defaultCompanyName" : "Default Company", 
		"caseCaseOrigin" : "phone", 
		"caseStatus" : "New"
	}');

			

Attributes added in "integration_profile_settings"

The newly added attributes of "integration_profile_settings" JSON structure are explained hereinbelow.

• isDefaultRecordTypeCreationRequired: This flag tells whether to create an object or not in case of a call and no object found in CRM for the call.

• defaultRecordTypeToBeCreated: This value used when no object found for incoming calls and by default this type object created and attached to this call. Following values are supported.

  • Contact

  • Account

  • Lead

  • Case

  • Opportunity

• unAttachDefaultRecordTypeCreationRequired: This flag tells in case of call dispose, if call object not attached with any object then, need to create an object and attach with the callObject or not.

• unAttachDefaultRecordTypeToBeCreated: This tells which particular object from the above list will be created in case of dispose button when call and callObject are not attached to any object and value of unAttachDefaultRecordTypeCreationRequired flag is set to true.

• attachNewRecordTypeCreationSet : This set of value shows in drop-down. In case of new object creation and attach to the current call.

• ameyoFieldsVsRecordFields: This contains a mapping of ameyo fields with the CRM fields for each recordType. Ameyo fields are received in recordData of crm_url's additionalData. This mapping is used for searching as well as creating a record in CRM.

• recordTypesVsRecordSearchFields: This tells for a Search recordType on which field search should be performed. When isAdditionalMappingRequired is true. When using additionalData of the CRM URL, a search will be performed on the fields defined here for the corresponding recordType. It can contain more than one value for each Search recordType. When isAdditionalMappingRequired is false, a global search is performed using phone no. for that searchRecordTypes. Following is a list of the supported search field values for recordTypes.

  • email

  • name

  • phone

Attributes added in "integration_specific_settings"

Following values can now be provided in "integration_specific_settings".

						'{ 
						"showTwoLevelDisposition" : false, 
						"disposeInCurrentView" : false, 
						"opportunityStageName" : "Prospecting", 
						"defaultCompanyName" : "Default Company", 
						"caseCaseOrigin" : "phone", 
						"caseStatus" : "New"
						}'
					

• disposeInCurrentView: Making this entry will always attach an activity to object open on Salesforce Lightning UI while disposing of. If the object is invalid, like when the list view is open, an unattached activity will be created.

• showTwoLevelDisposition : This flag tells to enable or disable two-level disposition.

Earlier, the entries to configure Ameyo Toolbar Integration for Zendesk were being entered in "server_preference_store" table. However, now these entries will have to be recorded in "integration_profile_settings" table.

In the following query, the changes are highlighted with the yellow color. These changes will impact the selection of the default object that will be created or modified whenever a call is made to or received from a phone number.

					insert into integration_profile_settings (contact_center_id,process_id,integration_type,domain,consumer_id,integration_generic_settings)
					VALUES(1,NULL,'ZENDESK','http://drishtisofthelp.zendesk.com',NULL, 
						'{ "searchRecordTypes" : [ "user"],
						"ameyoFieldsVsRecordFields" : { "user" : {  "customer_name" : "name", "customer_phone" : "phone" }, "ticket" : {} }, 
							"recordTypesVsRecordSearchFields" : { "user" : [ "phone" ]},"isAdditionalMappingRequired" : true}');
				

Following is the definition of configuration flags used in the above query.

• searchRecordTypes: It specifies the types of objects, which will be searchable.

• isAdditionalMappingRequired: It informs whether to use additional data provided in "crm_url" to perform the search on Zendesk Objects or not. It accepts the value in Boolean format, that is, true and false.

• ameyoFieldsVsRecordFields: It contains a mapping of ameyo fields with the Zendesk fields for each recordType. Ameyo fields are received in recordData of crm_url's additionalData. This mapping is used for searching and creating the record in Zendesk.

• recordTypesVsRecordSearchFields: It provides the Search recordType upon which the search will be performed only when "isAdditionalMappingRequired" is set as true. When using additionalData of crm_url, the search will be performed on the field defined here. If "isAdditionalMappingRequired" is set as false, the global search is performed using the phone number. Only the following fields are supported for search.

  • phone

  • name

The latest version of Zoho CRM APIs are available with enhanced functionalities such as increased API calls per day, Multi-DC support, better security, a new API dashboard, and others. Thus, it is recommended to move all our Zoho CRM Extensions listed in the marketplace and custom functions to Version APIs immediately, since the v1 APIs will stop working on January 1, 2020. After that, all codes written on the older version will stop working.

Refer to "Migration of Zoho CRM APIs and Functions to v2.0" post on Zoho Portal to know more.

Earlier, the entries to configure Ameyo Toolbar Integration for Zoho CRM were being entered in in "server_preference_store" table. However, now these entries will have to be recorded in "integration_profile_settings" table.

In the following query, the changes are highlighted with the yellow color. These changes will impact the selection of the default object that will be created or modified whenever a call is made to or received from a phone number.

					INSERT INTO integration_profile_settings                  (contact_center_id,process_id,integration_type,domain,consumer_id,integration_generic_settings,integration_specific_settings) VALUES(<cc_id> ,NULL,'ZOHO'<domain name>,<consumer_id>, '
					{ "ameyoFieldsVsRecordFields" : 
						{ "Accounts" : 
						{  "customer_email" : "email", "customer_phone" : "phone", "search_query" : "word"}, 
						"Contacts" : {  "customer_email" : "email", "customer_phone" : "phone", "search_query" : "word"},  
						Leads" : {  "customer_email" : "email", "customer_phone" : "phone", "search_query" : "word"} 
						},
						"recordTypesVsRecordSearchFields" : { "Contacts" : [ "phone" ], "Leads" : [ "phone" ], "Accounts" : [ "phone" ] }, 
						"isAdditionalMappingRequired" : false, 
						"defaultRecordTypeToBeCreated" : "Leads" }',
						'{ "showTwoLevelDisposition" : false, 
						"enableClientSideActivityCreation" : false, 
						"openRecordInNewTab" : true}');

				

Following is the definition of configuration flags used in the above query.

• defaultRecordTypeToBeCreated: It provides the default value, which is used when no object is found for incoming call, and the system creates this type of object by default and attach it to the current call.

• searchRecordTypes: It specifies the types of objects, which will be searchable.

• isAdditionalMappingRequired: It informs whether to use additional data provided in "crm_url" to perform the search on Zoho Desk Objects or not. It accepts the Boolean value, that is, true and false.

• ameyoFieldsVsRecordFields: It provides the mapping of Ameyo fields with the Zoho Desk fields for each recordType. Ameyo fields are received in recordData of crm_url's additionalData. This mapping is used for searching as well as creating record in Zoho Desk.

• recordTypesVsRecordSearchFields: It provides the Search recordType upon which the search will be performed only when "isAdditionalMappingRequired" is set as true. When using additionalData of crm_url, the search will be performed on the field defined here. If "isAdditionalMappingRequired" is set as false, the global search is performed using the phone number. Only the following fields are supported for search.

  • phone

  • email

  • word

• showTwoLevelDisposition: It specifies the value to enable or disable the two-level disposition.

• openRecordInNewTab: It specifies whether to open the record in a new tab or not.

• enableClientSideActivityCreation: It specifies the value to enable or disable the Activity creation at the client-side.

Till now, for any of the customization in the default flow of the toolbars, the customers need to raise the query to the product team. For such customizations, the product team had to provide the new build with those customizations. But for such customizations, the product team took more time, and hence the Turnaround Time for any customization was exceeded in many cases, which results in an increase in the workload and dependency on the product. But from now, these such customizations can be done either by the customers or by the Services Team.

A custom JS will be made for CTI iFrame. The toolbar flow remains as it is for all integrations- This will help services to do all integrations without dependency on the Product Development Team.

The functionalities in the product flow have no changes.

Default Plugins

The user can find the default plugins at the following location.

com_drishti_dacx_cc_webaccess_<build_tag>

Example Path: com_drishti_dacx_cc_webaccess_1.0.0.202001130425/

Where, build tag – is the tag of Ameyo’s build which is deployed on the customer's server. On the above location, all the plugins of toolbars (which are supported by Ameyo) are saved. The format of these plugins is in the format of ".JS" file.

Do not make any changes to these files. However, you can change and save these files on another provided location.

Customized Flow

Any changes done in the default flow of the toolbar is the customized flow. The user can create its own plugin, or have a reference of the plugins or change the existing plugins. After creating the plugins, save them at the following location.

/dacx/ameyo/com.drishti.dacx.server.product/plugins/com_drishti_dacx_cc_webaccess_/toolbar/js/CrmIntegrationModule/customCrm/crm

After changing the plugins, now, you have to enable the customization entry in the database. This entry of the database allows Ameyo to use the newly created plugin. Run the following query to check the integration type.

select * from integration_profile_settings;

Copy the integration_profile_setting_id from this query, as it will be used to update "is_custom" column.

After running the above query, update "is_custom" column. The default entry in this column is "false", you have to change it to "true". Run the following query to update the default value.

update integration_profile_settings set is_custom = 'false' where integration_profile_setting_is =<above_co pied_Id>

After updating the database entry, restart the server.

APIs

The following are the APIs that need to be used.

Save Plugin API

Run the following API to save the plugin.

<Server_Protocol>//:<Server_URL>:<Port_Number>/ameyorestapi/customCRMIntegration/registerCustomCRMIntegration

This API will save all the plugins present in "CutomCRMIntegration" folder.

Restore Plugin API

Use the following API to restore the previous version of the plugins which are being saved.

<Server_Protocol>//:<Server_URL>:<Port_Number>/ameyorestapi/customCRMIntegration/extractCustomIntegration

This API will restore the last saved plugin data.

If a problem occurs with this new integration, then use the above API to restore the plugin data to the previously saved state.

From the security and privacy point of view, the masking of Customer Number is required in the Contact Center Industry. Customer Number Masking is already available for Ameyo AppServer.

Customer Number Masking is now available in the Ameyo Toolbar Integrations. If the configuration for masking the customer's number is already done for Ameyo AppServer, then it will be done in Ameyo Toolbar Integrations also.

It is a licensable and configurable feature. After enabling the license, the configuration has to be performed to mask the customer numbers.

In case of Click to Dial in Ameyo Toolbar Integration, the relevant contextual object is displayed in the CTI Pop-up on the Agent's screen. The same object is displayed to the other agent in case of Call Transfer or Call Conference. It is available for Ameyo Toolbar Integrations with Salesforce Classic, Salesforce Lightning, Microsoft Dynamics with CIF, and Zendesk.

Earlier, most of the calculations for Toolbar Data Points were being performed at the client-side, that was, at the User interface because of which there was a slight delay in the display of expected results of these data points.

In Ameyo 4.5, the definition and calculation of the voice-related data points in Ameyo AppServer have been changed. From Ameyo 4.5 onwards, some cases were also observed where the value of one data point at Toolbar Integration was different from the same data point in Ameyo AppServer.

Now, the data points of Ameyo Toolbar Integrations have been made consistent with Ameyo AppServer and their calculations will be performed at the server-side.

Optimized Data Points

Following is a list of the optimized data points.

• Calls Handled: It is the total number of calls connected to the agent. It shows the total calls answered by the customers in a campaign.

• Callbacks: It shows the total number of callbacks in the campaign, including Queue Callback, Campaign Callback, Self Callback, and Preview Callback.

,

• Average Talk Time: It is equal to the total time (in seconds) spent by the agents while talking to the customers divided by the total number of answered customer calls in this campaign.

  

  Figure: Calculation of Avg Talk Time Duration

• Average ACW Duration: It is the average amount of time spent by all the agents in disposing the calls. It represents the average time taken by the Agents to dispose of the calls.

  

  Figure: Calculation of Average ACW Duration

• Average Handling Time: It is equal to the sum of Customer Talk Time, Customer Hold Time for, and Wrap Time of Connected Calls divided by the total connected calls. It includes only Customer Interactions, but Dial User (Internal Calls) are not included.

  

  Figure: Calculation of Average Handling Time

  AHT does not include the Average Wrap Time of an agent as the Average Wrap Time will also include the wrapping up of not connected calls.

• Average Hold Duration: It is equal to the total hold time divided by the count of customer calls with holds.

  

  Figure: Calculation of Average Hold Duration

• Break Count: It is the total count of times when Ameyo User has selected "Break" as its status.

• Total Break Duration: It is the total time duration taken by Ameyo User during the breaks.

• Total Login Duration: It is the total duration for which the agent is staffed into a campaign.

Data Collection Indications

The following data collection indications will also be displayed.

• Last Calculated Time: It is the time when the data points are updated last.

• Refresh after every 5 minutes: It shows that the data points are being refreshed after every five minutes.

• Stats Duration: It shows the duration of which data is being displayed on this screen.

• Stats Reset: It is the indication about the time before which the monitoring data was refreshed.

Other Data Points

The definition and calculation of the following two data points remain the same. They have been enabled from the backend to display for the Outbound Campaigns in the Toolbar Integrations.

The value of "isToolbarLeadStatsEnabled" flag has to be set as true using the following query in "server_preference_store" to show these data points.

insert into server_preference_store (context_type, context_id, key, value) values ('contactCenter', 1, 'isToolbarLeadStatsEnabled', true);

• Processed Leads: It is the equal to the number of "Resolved" categorized dispositions divided by total dispositions.

  

  Figure: Calculation of Processed Leads

  After settings "isToolbarLeadStatsEnabled" as true, run the following query to show this data point.

  insert into server_preference_store (context_type, context_id, key, value) values ('campaign', 1, 'webaccessResolvedDispositions', 'Echo,Sale,etc');

• Success: It is the equal to the number of "Success" categorized dispositions divided by total dispositions.

  

  Figure: Calculation of Success Leads

  After settings "isToolbarLeadStatsEnabled" as true, run the following query to show this data point.

  insert into server_preference_store (context_type, context_id, key, value) values ('campaign', 1, 'webaccessSuccessDispositions', 'Already hangup,Foreign Language,etc');

The name of Ameyo Users will now be displayed with the User IDs in the user list while initiating Call Conference and Call Transfer in Ameyo Toolbar Integrations.

A business may want its customers to provide the details such as account ID, registered number, order ID, and others on IVR. It would help the business to verify its customers and serve them in a better way. The backend configuration is required to link the identified records with the IVR, which will be searched in CRM.

After the customer has provided the input, Ameyo searches for the record in the third-party system and presents it to the user and reverts back. It saves a lot of time from the agent and identifies the right record for the customer. These inputs are captured by Ameyo Toolbar, which searches the CRM and shows the relevant object page in the CTI pop-up of the agent who receives the call. If the object is not found, then it can be also be configured to be created.

The conditions to perform the different actions based upon the different inputs are provided through a nodeflow created by the Services Team. If the customer input received on a call is found invalid or not found in the system, then the customer can be asked to re-enter the inputs. Moreover, the call can be managed to connect even if the provided input is not valid.

The backend configuration to create the new object, if the matching object is not found as per the inputs provided at IVR, is available in the configuration documents for Salesforce Lightning, Zendesk, and Zoho.

"Dispose and Dial" disposition is already available in the AppServer. Now, it will be available as a default feature in all Ameyo Toolbar Integrations. With this feature, the agent can dispose the call as "Dispose and Dial" to dial the customer's number again when

• the call gets disconnected abruptly, and the agent is required to make the call again

• the customer asks the agent to call on another phone number

The user can select "Dispose and Dial" as a disposition to disconnect the current call and initiate an outbound call on the same or alternate phone number of the customer.

The object displayed in CTI Pop-up for the previous call, which was disposed of using "Dispose and Dial", will be retained and displayed in CTI Pop-up for the new call that will be generated after selecting "Dispose and Dial".

Also, if no object has been created for the current call, which has been selected for dispose and dial, then no object will be created for the new call that will be made after selecting dispose and dial.

This feature is a Masked Privilege for the user. Therefore, the Administrator and Supervisor can enable or disable this feature for any user while creating or modifying that user.

It is a general IT security policy and the requirement of compliance (such as PCI DSS) that a user should re-authenticate its session after the inactivity for a duration. To address the same, Ameyo now introduces the "Inactivity Timeout" feature in the Toolbar Integration. This feature was earlier available in the AppServer.

It means if a user is inactive for the user-configured duration, then the user will be logged out from Ameyo. The user has to logon again once the user is active again.

If an Ameyo User is browsing the third-party CRM with Ameyo Toolbar in the multiple tabs of the Web Browser window, then the tab in which Dialer is opened to attend an incoming or outgoing call will be termed as "Primary Tab". Other tabs in the same window are termed as "Secondary Tabs".

The user inactivity is understood as the inactivity of the user actions on the Primary Tab. User Inactivity in other browser tabs is not considered.

By default, the Inactivity Timeout will remain disabled. It has to be configured in the backend using the following query. This will be defined at the CC level with a default value of 5 minutes.

insert into server_preference_store (context_type,context_id,key,value) values ('contactCenter','1','inactivityTimeout','1');

The minimum value of timeout is 1 minute, and the maximum value can be 60 minutes.

The agent will be logged out if the agent is not performing any action, including mouse movements, minimizing the window, or maximizing the window after the defined inactive timeout. In other words, any mouse activity, minimizing the window, or maximizing the window is considered as user activity.

If the break duration for an agent is more than the Inactivity Timeout and no activity is monitored, then the agent will be logged out.

The agent will not be logged out if the agent is on call, but no movement is observed, or if the agent is viewing the CRM after call hang-up and inactivity timeout is less than ACW Timeout.

If the agent is logged out because of inactivity timeout, then the agent will be redirected to the logon screen that will show a message that the agent has been logged out because of inactivity. In Reports, the logout reason in reports will be "inactivity_logout" in such cases.