Routing

CCAI Platform offers multiple features that let you automate call and chat routing between agents and end-users. Routing can decrease end-user wait times and increase agent efficiency.

Multicast and deltacast

Multicast is the default routing configuration for all sessions. A session is a communication between an agent and an end-user. Multicast routes sessions to all agents who are assigned to a specified queue. All agents have an equal opportunity to answer, and the quickest to respond will get the call or chat.

Deltacast is an intelligent routing system unique to CCAI Platform that uses logic to disperse calls to individual agents rather than giving all agents in the queue the same opportunity to answer.

Deltacast: Call

If enabled, deltacast extends to the following:

• Transfers
• Scheduled calls
• Calls routed using Direct Access Points (DAPs)
• Queues with cascade groups enabled
• Queues with percent allocation groups

This section outlines deltacast routing logic and describes how to enable this feature.

Missed Call status

The Missed Call agent status is used for sessions with deltacast enabled. Missed calls are deltacast calls that are routed to an agent and not answered within the Deltacast Timeout time threshold. Missed multicast calls don't put an agent in Missed Call status.

If an agent is placed in Missed Call status, they will not be able to receive new calls until either they or an Admin manually change their status back to Available. Admins can see a count of agents in Missed Call status in the Call Dashboard, Agent page, and in reporting. Agent status and activity information is also available using the API. To be placed in Missed Call status, the agent must have been in Available status. If they are in any other status, Missed Call will still show in reporting but not in the agent adapter.

Missed Call status is independent of the Missed Chat threshold. Calls are not projected to agents in Missed Call status; they are only routed to agents in Available or In-chat status.

Deltacast routing logic

1. An incoming call is routed to the agent in status Available with the longest duration since they last ended a call.

2. If the agent does not answer within the time set in the deltacast timeout setting:

   • If there are remaining deltacast attempt counts for the call, the call is routed to an available agent with the next longest duration.

   • If the deltacast attempt count has run out, the call is routed using multicast to the rest of the agents assigned to that queue menu option.

If cascade groups are also being used

1. If a deltacast call is routed to an agent and the agent does not answer within the time set in the deltacast timeout setting:

   1. If there are remaining deltacast attempt counts for the call, the call is routed to an available agent with the next longest duration.

   2. If the deltacast attempt count has run out, the call will be offered using multicast to all agents assigned to Cascade Group 1.

2. If the multicast call to Cascade Group 1 remains unanswered in the set amount of seconds, the call is offered using multicast to all of the agents assigned to Cascade Group 1 and Cascade Group 2.

3. If the multicast call being offered to Groups 1 & 2 is still unanswered in the set amount of seconds, the call is offered using multicast to all agents assigned to Cascade Group 1, Group 2, and Group 3.

4. Multicast continues to offer the call to successive cascade groups until an agent accepts the call.

If Auto-Answer is also being used

An incoming call is routed, using deltacast, to the agent in Available status with the longest duration since they last ended a call. Auto-Answer immediately connects the call to the agent. The agent is notified with a tone and their call adapter begins the 3-2-1 countdown.

The following diagram shows the deltacast routing flow:

Enable deltacast globally

Note: You are not required to enable Deltacast globally to configure it for individual queues.

Multicast is enabled by default. This section shows you how to enable deltacast routing globally. These settings are inherited by all eligible queues unless you change them at the queue level.

1. Go to Settings > Operation Management and then go to the Routing pane.

2. At Call Routing, select Deltacast. The following configuration settings appear:

   • Deltacast Attempt Count: The number of times deltacast should offer an incoming call to a single, eligible agent before switching to multicast.
   • Deltacast Timeout for calls: The amount of time, in seconds, that an has to pick up a call before it is offered to the next agent or queue. You can configure different time thresholds for agents working at a computer and agents using twinning to answer calls on a mobile phone. Agents answering on a mobile phone might need more time to answer than agents working at a computer.
   • Missed Call Threshold: The number of deltacast calls an agent can miss (not pick up in the set timeout threshold) before being automatically set to Missed Call status.
   • Unresponsive Threshold: If CCAI Platform cannot reach the agent adapter to send a chat to the agent, this threshold determines when to place the agent in Unresponsive status.
   • Cascade Timer selection: Select this checkbox to skip the cascade group timer if no agents are available in the cascade group.

3. Configure your deltacast settings and then click Save routing.

Enable deltacast at the queue level

Deltacast settings for queues are automatically inherited from the global settings unless you change them for individual queues. You don't need to enable Deltacast globally to configure it for specific queues.

1. Go to Settings > Queues > {Web, Mobile, or IVR channel} > {QUEUE_NAME}.

2. Scroll to the Routing* section. If you have global Deltacast settings enabled, a small global tag will appear here. All queues automatically inherit global Deltacast settings unless you change them at the queue level.

3. Click Configure, then click Deltacast to enable it for this queue.

4. Set your Deltacast configuration values, then click Save to apply.

(Optional) Skip cascade group timer

The skip cascade group timer functionality allows you to bypass the cascade timer settings and route a call or chat to the next available agent, regardless of your cascade group. With this feature enabled, the call will be routed to agents immediately if they are available in the next cascade group.

When disabled, the platform will adhere to the cascade timer settings and wait for the specified time before proceeding to the next group.

1. Go to Operation Management > Routing.

2. Under Cascade Timer selection, select the Skip Cascade Group Timer check box. By default, this checkbox is unchecked.

3. Click Save Routing.

Monitoring and reporting

Admins and managers can see agents in Missed Call status in the Logged in agent section of the call dashboard. Agents in Missed Call status are also visible on the Settings > Agents > Agent page. You can click the Filter Settings menu on this page to filter on agent status.

View deltacast and multicast call data

All notifications offered, pickup attempts, and successfully answered calls are logged and can be viewed in reports and reporting APIs. The following reports are available:

• Agent Activity - Summary Report
• Agent Activity - Timeline Report

To download a report, follow these steps:

1. Go to Reports > Agents & Teams.

2. Choose an agent or team for which you want to see data.

3. Under Select Session Type, select Calls.

4. Under Select Reports Desired, select the report type(s) that you want.

5. Select the Timeframe and Timezone.

6. Click Download. Deltacast metrics are labeled in the downloaded report.

Deltacast: Chat

If enabled, deltacast extends to every channel and every queue that uses chat. It applies to all chat types and the following chat flows:

• Transfers
• Chats routed through Direct Access Points (DAPs)
• Queues with cascade groups enabled
• Queues with percent allocation groups enabled

Eligible agents

To receive a deltacast call, an agent must fulfill one of following requirements:

• Status is set to Available.

• Status is In-chat and the agent has not reached the chat concurrency threshold.

  • Chat concurrency is configured globally in Settings > Chat and individually in Settings > Users & Teams > Edit a user (pencil icon).
  • If the agent is assigned to both chat and call sessions, a call counts as one chat toward the chat threshold.

Missed Chat status

The agent status Missed Chat is used for sessions with Deltacast enabled. Missed chats are defined as Deltacast chats routed to an agent and not answered within the Deltacast Timeout time threshold. Missed Multicast chats don't count toward Missed Chat.

If an agent is placed in Missed Chat status, they will not be able to receive new chats until either they or an Admin manually change their status back to Available. Admins can see a count of agents in Missed Chat status in the Chat Dashboard, Agent page, and in reporting. Agent status and activity information is also available using the API. To be placed in Missed Chat status, the agent must have been in Available status. If they are in any other status, Missed Chat still shows in reporting but not in the agent adapter.

Missed Chat status is independent of the Missed Call threshold. Chats are not projected to agents in Missed Chat status; they are only routed to agents in Available or In-chat status.

Deltacast routing logic

Basic routing

1. When a chat enters the queue, the chat is offered to a single, eligible agent (status Available or In-Chat), according to these rules:

   • If multiple agents are in Available status, the chat is routed to the agent with the longest period of time since they were last in In-Chat status.

   • If all assigned agents are In-call or In-chat, the agent who has the fewest number of concurrent chats will get the next chat.

   • If an agent is on a call, the call counts as [X] concurrent chats as configured in Settings > Operation Management.

   • If multiple agents have the same number of concurrent chats, the agent with the longest period of time since receiving a chat will get the next chat.

2. If the agent who is offered a chat does not pick up the chat within the time set in the deltacast timeout setting, the chat is offered using Multicast. Multicast sends the chat to every agent in the queue, including the agent who didn't answer the chat in time.

Routing with cascade groups

1. The chat is offered to an eligible agent in Cascade Group A for the duration of the Deltacast Timeout for Chats timer. If it isn't answered:

   1. If there are remaining deltacast attempt counts for the chat, the chat is routed to an eligible agent with the next longest duration.

   2. If the deltacast attempt count has run out, then the chat is offered using multicast to all agents in Cascade Group A, both in Available and In-chat statuses, including the original agent routed the chat (if they did not reach the Missed Chat threshold).

2. If no agents pick up the chat and the cascade group timer expires: The chat is offered using multicast to all agents in Cascade Group A in either Available and In-Chat status, including the original agent routed the chat.

3. If no agents pick up the chat and the cascade group timer expires: The chat is offered using multicast to all eligible agents in Cascade Group B, and continues to offer the chat using multicast to all eligible agents in Cascade Group A.

4. If the cascade group timer expires, and Group B is the last group: The chat continues to be routed using multicast until the unanswered chat expiration timer expires, as set in Settings > Chat.

Routing with Auto Answer enabled

1. The incoming chat will be routed using Deltacast to an eligible agent based on the routing logic described previously. Auto Answer initiates the chat conversation in the Agent Adapter. The agent will hear an audible tone, and the New Chat tab will flash red.

Enable deltacast globally

Note: You are not required to enable Deltacast globally to configure it for individual queues.

Multicast is enabled by default. This section shows you how to enable deltacast routing globally. These settings are inherited by all eligible queues unless you change them at the queue level.

1. Go to Settings > Operation Management, and then go to the Routing pane.

2. At Chat Routing, select Deltacast. The following configuration settings appear:

   • Deltacast Attempt Count: The number of times deltacast should offer an incoming chat to a single, eligible agent before switching to Multicast.
   • Deltacast Routing Logic: This setting affects the eligible agent calculation. This setting only applies to agents who are assigned to a queue configured for both chat and call channels.
   • Deltacast Timeout for chats: This is the time duration, in seconds, before the chat is offered to the next agent or queue.
     • The suggested value is 10 seconds, which ensures that the chat has enough time to connect in most network connection scenarios.
     • Make sure that percent allocation and cascade group time threshold settings are higher than the deltacast Timeout value. If they are the same or lower, you won't be able to enable deltacast. Group settings are located in the General section of the Operation Management page.
   • Missed Chat Threshold: The number of deltacast chats an agent can miss (not pick up in the set timeout threshold) before being automatically set to Missed Chat status.
   • Unresponsive Threshold: If CCAI Platform cannot reach the Agent Adapter to send a chat to the agent, this threshold determines when to place the agent in Unresponsive status.
   • Cascade Timer selection: Select this checkbox to skip the cascade group timer if no agents are available in the cascade group.

3. Configure your deltacast settings, and then click Save routing.

Enable Deltacast at the queue level

Deltacast settings for queues are automatically inherited from the global settings unless you change them for individual queues. You don't need to enable Deltacast globally to configure it for specific queues.

1. Go to Settings > Queues > {Web or Mobile channel} > {QUEUE_NAME}.

2. Go to the Routing section. If you have global deltacast settings enabled, a Global tag appears. All queues automatically inherit global deltacast settings unless you change them at the queue level.

3. Click Configure, and then click Deltacast to enable it for this queue.

4. Set your deltacast configuration values, and then click Save. For more information about deltacast configuration settings, see Enable deltacast globally.

Monitoring and reporting

Admins and managers can see agents in Missed Chat status in the LOGGED IN AGENT section of the Chat Dashboard. Agents in Missed Chat status are also visible on the Settings > Agents > Agent page. You can click the Filter Settings menu at the top of this page to filter on agent status.

View Deltacast and Multicast chat data

All notifications offered, pickup attempts, and successfully answered chats are logged and can be viewed in reports and reporting APIs. The following reports are available:

• Agent Activity - Summary Report
• Agent Activity - Timeline Report

To download a report, follow these steps:

1. Go to Reports > Agents & Teams.

2. Choose an agent or team for which you want to see data.

3. Under Select Session Type, select Chats.

4. Under Select Reports Desired, select the report type(s) that you want.

5. Select the Timeframe and Timezone.

6. Click Download. Deltacast metrics are labeled in the downloaded report.

Direct access points (DAPs): Call

Direct access points let you direct voice calls to specific queues in your queue structure. Using DAPs makes the call process faster for end-users by routing them directly to specific queues rather than forcing them to navigate a lengthy queue tree. For example, you can configure a DAP to route new end-users to a dedicated onboarding queue.

There are multiple ways to set up DAPs, either using an API or your CRM (or both). This section outlines the configuration options for DAPs.

Note: DAPs are available for Web, Mobile, and IVR channels.

DAP types

You can configure the system to create a DAP with one of the following access point types, depending on which channel you're using. The multiple types use different information to detect a match and route an end-user call.

DAP type	IVR	Mobile	Web
User Segment DAP: Matches and routes end-users according to end-user account data key and value pairs from your CRM.	X	X	X
General DAP: An access point that is placed in your app or SDK setup by your developers. When this access point is reached by an end-user, they are routed to a specific queue.	X	X	X
Support Phone Number DAP: Routes end-users to specific queues according to the support phone number they call to reach your call center.	X
API Response DAP: Matches and routes end-users to specific queues according API response key and value pairs.	X
Mobile App DAP: Routes end-users to specific queues according to mobile application. Only available for environments with the Multiple mobile app feature enabled.		X

DAP matching order and interactions

Matching order

When you use multiple DAP types, CCAI Platform checks for matches, first based on DAP type, then the order in which the DAPs were created. DAP order is different if you're using one or more mobile apps with your environment. If two DAP criteria are met within a specific DAP type, CCAI Platform routes the call based on the first one created.

IVR channel

Standard IVR DAP types and order

1. Mobile PSTN fallback (if using a mobile SDK)

   • Match= Route to that queue
   • No match= Move to next

2. Phone number DAP

   • Match= Route to that queue
   • No match= Move to next

3. General DAP

   • Match= Route to that queue
   • No match= Move to next

4. API DAP

   • Match= Route to that queue
   • No match= Move to next

5. User segment SAP

   • Match= Route to that queue
   • No Match = Route to the very top of the queue

Alternate IVR DAP order: For access, contact Support

1. General DAP

   • Match= Route to that queue
   • No match= Move to next

2. API DAP

   • Match= Route to that queue
   • No match= Move to next

3. Mobile PSTN fallback (if using a mobile SDK)

   • Match= Route to that queue
   • No match= Move to next

4. Phone number DAP

   • Match= Route to that queue
   • No match= Move to next

5. User segment DAP

   • Match= Route to that queue
   • No Match = Route to the very top of the queue

Mobile channel

Mobile channel DAP types and order

1. General DAP

   • Match= Route to that queue
   • No match= Move to next

2. User segment DAP

   • Match= Route to that queue
   • No match= Move to next

3. Mobile App DAP

   • Match= Route to that queue
   • No Match = Route to the very top of the queue

Alternate DAP order: For access, contact Support.

1. User segment DAP

   • Match= Route to that queue
   • No match= Move to next

2. General DAP

   • Match= Route to that queue
   • No match= Move to next

3. Mobile App DAP

   • Match= Route to that queue
   • No Match = Route to the very top of the queue

Web channel

Web DAP types and order

1. General DAP

   • Match= Route to that queue
   • No match= Move to next

2. User segment DAP

   • Match= Route to that queue
   • No match= Move to next

Alternate DAP order: For access, contact Support

1. User segment DAP

   • Match= Route to that queue
   • No match= Move to next

2. General DAP

   • Match= Route to that queue
   • No match= Move to next

User segment DAPs

All CRM software has contact objects (named Contact, People, Customer, or similar). CCAI Platform automatically looks at contact objects whenever an end-user reaches out using IVR or SDK and compares them to the key and value pairs that you used to configure the DAP. If the system detects a match, the end-user is immediately routed to the specified queue. You can configure your CRM to include fields that you want to use for end-user routing, such as including a VIP field.

Example:

You want to know if an end-user has multiple open support cases so they can be automatically routed to an escalation queue. In your CRM, create a calculated field that counts open support cases. You can create a DAP to look for a specific value in that calculated field that indicates multiple support cases are open. If the DAP detects a match, the end-user is routed directly to a specified escalation queue and the case details are passed to the agent.

Prerequisites

1. You must set up user segments in your CRM. See Priority User Segments for instructions.

2. Enable CRM access

   1. Go to Settings > Operation Management.

   2. Under CRM Access, mark the checkbox to Allow CRM Access for user segment information.

   3. Click Save General to save.

3. See the create a DAP section to set up a user segment DAP.

Support phone number DAPs

Support phone number DAPs route end-users into dedicated queues according to the phone number they're calling in to. Phone numbers can be any number managed by CCAI Platform. There is no limit to the number of phone numbers you can use, and phone number DAPs can be set up for multiple languages and locales.

Examples:

• An end-user suspects credit card fraud and calls the number listed on the back of the card. That phone number is associated with a DAP that is configured to route the caller into a dedicated fraud prevention queue.

• You can give out different phone numbers to specific groups of people, such as VIPs or employees. When an end-user calls in, the DAP recognizes the phone number and automatically routes them to the VIP queue or employee menu.

Supported Formats:

• E164 formatted numbers: +(country_code)(phone_number)
• SIP phone numbers in the incoming sip address format: sip:[number]@[domain].

Prerequisites

1. Make sure that the phone number you want to use is provisioned for your CCAI Platform environment.

2. See the create up a DAP section to set up a support phone number DAP.

API DAPs

You can configure API DAPs to capture conditions that exist inside or outside of your CRM. This is the only DAP where multiple conditions can be evaluated in order to route sessions (for example, both a phone number and a key and value pair). When an end-user calls in, the contact data is compared to the API data and routed to a specific point in the queue structure.

The request is processed using JSON. POST and GET HTTP request methods are supported. Unlike other DAP options, you can also use AND logic with multiple key and value pairs. When a key and value pair match is detected, CCAI Platform immediately routes the call according to your configuration.

Example:

You have an API with data that shows the end-user is a Super-user, the product type is International, and that they meet other specific criteria. A DAP configured to recognize specific key and value pairs routes them into a specific queue.

Prerequisites

Required elements:

• API URL: A URL endpoint that is able to receive a phone number request and return a JSON response.

• Test phone number: After the DAP is set up, you must use a test phone number to ensure that the configuration correctly returns results (typically in JSON format).

• API credentials: Basic authentication is required for a non-Salesforce endpoint.

  OR

• Salesforce Configuration: See the Salesforce documentation for initial setup in Salesforce.

Configure an API DAP

To configure an API DAP, do the following:

1. Click Menu, and then click Settings > Developer settings.

2. Go to the API request direct access point pane.

3. In the Post request URL field, enter the API endpoint for the DAP. Only one endpoint can be used per environment.

4. In the Authentication method area, select one of the following authentication methods:

   • Basic authentication. If you select this option, enter your username and password.

   • OAuth. OAuth is only available when using Salesforce. For more information, see API Direct Access Point - Salesforce REST API.

   • Custom header: Uses HTTP headers for authentication. If you select this option, do the following:

     1. Click Add field. The Add field dialog displays.

     2. In the Field key field, enter the authentication header name.

     3. In the Field value field, enter the authentication header value.

     4. Optional: Add additional headers.

     5. Click Save.

5. In the API request timeout area, click Expand more to select the API request timeout value in seconds. To determine the optimal timeout time, consider the following:

   • The optimal API request timeout time depends in part on your server response time. A tool such as Postman can help you determine your server response time.

   • An API request timeout time should be long enough to accommodate the expected API response time, but short enough to keep the end-user's wait time reasonably short.

   • If the API request times out and there is no match for the first DAP type, the next DAP type is checked for a match. If there is no match for any DAP type, the call is sent to the top of the queue. For more information, see DAP matching order and interactions.

   • If you have multiple languages enabled, a language-selection message is played for the caller.

6. In the API request method area, depending on the type of request you're making, select Post or Get.

7. In the Phone number format area, click Expand more to select the phone number format that you use to store phone numbers on your server.

8. In the Request parameter field, enter the name of the phone number request parameter. The value can be any string and is case sensitive. If the request parameter doesn't match the corresponding parameter on your server, routing fails. Here is an example API request URL for a GET method:

   https://example.com/api_dap?PARAMETER_NAME=[phone]
   

   Replace the following:

   • PARAMETER_NAME: The name of the phone number parameter.

9. Optional: To pass data from the headers of incoming Session Initiation Protocol (SIP) calls to your Interactive Voice Response (IVR) queues, do the following:

   1. Click the Pass data parameters toggle to the on position.

   2. In the Data parameters area, add the parameters that are required to pass the data. For more information, see Pass data parameters to Virtual Agents and Virtual Task Assistants.

   3. In the Data records area, make a checkbox selection to include data parameters in metadata files, to include data parameters in CRM records, or both.

10. In the Push API response data to CRM area, make a checkbox selection to format the API response data as a key-value pair to leave the API response in its original JSON format or both.

11. Click Save.

Test your configuration

CCAI Platform lets you quickly verify that your connection has been properly configured. You need a phone number that's linked to a contact that you know will return the value you're looking for from the queried server.

1. Go to Setting > Developer Settings > API Request Direct Access Point.

2. Enter the test phone number in the Test Connection field and click Test this connection.

3. View the JSON response from the API.

4. If null or no results, check the following:

   • Is the connection pointed to a database with the correct data?

   • Is the phone number associated with a contact?

   • Is the phone number format correct?

   • Does the response header match exactly?

   • If the response is timing out, increase the timeout value in the settings above the test section. If the timeout becomes so long that it will lengthen wait times, investigate how to optimize your server response time.

API DAP logic details

CCAI Platform uses set logic to route calls (see DAP matching order and interactions). API DAPs have the additional complication that they can include multiple conditions to be evaluated in order to route calls. Because of this, the specific order in which you create API DAPs is extremely important. If you have existing API DAPs and they have any overlap with new API DAPs you are creating, you might need to recreate your existing DAPs in a new order to achieve your required routing.

Each condition can be either a compound set of key and value pairs or a single key and value pair. After a condition is met, CCAI Platform stops checking for matches and immediately routes the call. For this reason, it's important to create the most complex conditions before the least complex. This ensures that the more complex conditions are checked first.

Correct example: Complex conditions first

CCAI Platform will match 1 first, then 2, then 3.

1. "brand = Generico" AND "Customer type = lead" AND "product = retail"

2. "brand = Generico" AND "Customer type = lead"

3. "brand = Generico"

Incorrect example: Simple conditions first

CCAI Platform will match 1 first, then 2, then 3. If API DAPs are created in this order, conditions 2 and 3 will never be reached because all requests will meet the first condition.

1. "brand = Generico"

2. "brand = Generico" AND "Customer type = lead"

3. "brand = Generico" AND "Customer type = lead" AND "product = retail"

Create a DAP

1. Make sure that you have completed any prerequisites required for your DAP type. See the API DAP, support phone number DAP, or user segment DAP sections for instructions.

2. Go to Settings > Queue.

3. Choose your channel (IVR, Web, or Mobile) and click Edit / Add.

4. Select the queue you want to add the direct access point to. In the Settings panel, scroll to Access Point and click + Create direct access point.

5. Choose the access point type and enter a name in Access Point Name. Depending on your channel and access type, enter the following information:

   1. Support phone number

      • Support Phone Number: Enter a phone number that has been provisioned to your account by CCAI Platform, including the country code if international. Format is e164 (+[country_code][phone_number]) or SIP (sip:[number]@[domain]).
      • Greeting Message: Enter a message for end-users in the text box to be read by Cloud Text-to-Speech, or upload your own audio file. To skip the greeting message, either enter a "." in the text box or upload a blank file.

   2. User segment

      • CRM Custom User Segment Field: Name of user segment field in your CRM. Example: "Tier"
      • CRM Custom User Segment Value: User segment value to be directed to this queue. Example. "Gold Tier"
      • Greeting Message: Enter a message for end-users in the text box to be read by Cloud Text-to-Speech, or upload your own audio file. To skip the greeting message, either enter a "." in the text box or upload a blank file.

   3. API Response

      • API Response: Click Add Key & Value. Enter the key and value pairs as they gave been set up in the API. Repeat for each set of key and value pairs required for the DAP.
      • (Optional) Support Phone Number: A CCAI Platform- provisioned phone number that end-users call to reach your call center. This number will be required for matching in addition to the API response key and value pairs.
      • Greeting Message: Enter a message for end-users in the text box to be read by Cloud Text-to-Speech, or upload your own audio file. To skip the greeting message, either enter a "." in the text box or upload a blank file.

   4. General

      • General Access Point Label: A recognizable label for developers to use within your app or SDK.

   5. Mobile App

      • Mobile App: Choose your mobile app from the drop-down menu.

6. Click Create.

Test call routing

1. Call the channel using a phone number or end-user account with parameters that you know should trigger the DAP.

2. Confirm the call is routed to the correct queue and any entered greeting is played.

Twinning: Call

Twinning allows a primary extension (web desktop adapter) and a secondary extension (for example, mobile phone number) to operate as a single phone. Twinning is ideal for support agents who are frequently on the go, since it allows them to forward support calls to their preferred phone number in addition to handling calls at their desk using the web adapter. Another example is a front desk phone set up as the office's primary extension; you can use Twinning to forward those calls to a mobile phone.

Twinning supports international phone numbers.

Main benefits:

• Full flexibility: When an agent chooses to forward calls in the Agent Adapter, the call is sent to the phone number but the agent will continue to receive call notifications in their web adapter. They are still able to answer the call there if needed. Agents are able to receive all call types using this method.

• Supports routing using DID. Twinning is able to route calls using a unique identifier known as a Direct Inward Dialing (DID) number. A DID number is a telephone number that is used to directly connect to a specific extension or department within an organization.

• CRM ticket generation: Twinned calls handled through an extension on a mobile phone still generate a CRM ticket.

• Reporting and monitoring: Twinned calls will be displayed in reporting and on all monitoring pages. The record appears as a regular call and does not identify whether it was answered through an extension.

• No internet connection required: The call is made over PSTN.

• Compatible with Multicast and Deltacast. If certain agents in a queue are able to use twinning while others are not, all agents will still receive the call.

Configuration

• Agents will receive twinned calls from the number set as the Global default outbound phone number. Agents should add this phone number to their contacts to avoid having the call marked as spam.

• When you select Forward calls to phone number in the Agent Adapter, all incoming calls for the agent will now be routed to the phone number entered in their user profile.

• If agents have the web adapter actively open at the same time, they should turn off Auto Answer.

• Because twinned calls are not using the Agent Adapter, the following adapter features are not accessible when Twinning is enabled: Transfers, SmartActions, Hang up and Call back.

Grant mobile calls permissions

By default, the Agent role does not allow agents to forward calls to their phones. To allow this capability, you must create a new Mobile Calls permission and assign it to any users you want to be able to forward calls. The new role must include the Mobile Calls permission only in order to apply it to existing agents.

1. Go to Settings > Users & Teams. Select the Roles & Permissions tab at the top of the page.

2. Click + Add Roles.

3. Scroll to User Profile - My Profile and click the carrot on the right to expand the menu.

4. Check the box next to Mobile Calls.

5. Scroll back to the top to give the new role a Role name, Label name, and Description.

6. Click Save to create the new role.

7. Click the Manage Users & Teams tab at the top of the page to navigate back to the teams page, then click the edit button (pencil icon) next to the user you want to assign the Mobile Calls role to.

8. Under Roles, select Mobile Calls from the drop-down menu. Click Update to assign the role.

For more detail about roles and permissions, see the roles and permissions documentation.

Enable agents to receive calls on their mobile

1. Go to Settings > Operation Management > Agent Status.

2. Under Availability Preferences select Allow agents to receive calls on their mobile phone.

3. Instruct the agent(s) you assigned the Mobile Calls role to to log out of CCAI Platform and then log back in again. If they don't, the new mobile calling fields and features will not appear.

(Optional) Increase deltacast timeout for mobile agents

Agents who are on-the-go might require more time to pick up a call than agents sitting at a desktop. If you are using Deltacast, you can increase the amount of time agents have to pick up calls. To change Deltacast timeout:

1. Go to Settings > Operation Management > Deltacast.

2. Set the Deltacast timeout value. The default value is 5 seconds.

Instructions for agents: set up call forwarding

Agents must take the following steps in order to enable call forwarding. Make sure that the agents have logged out of CCAI Platform and logged back in again after you assigned them the Mobile Calls role and enabled the twinning feature, otherwise required fields and menu items won't appear.

Set your mobile number

1. In the main CCAI Platform menu, select My Profile.

2. In the Mobile Calls > Phone Number field, enter the phone number you want to receive calls on.

Enable call forwarding in the Agent Adapter

Agents should now be able to see the Availability Preferences feature in the Change status drop-down menu in their Call Adapter.

The default setting is Only Web Agent Adapter (Desktop). Even when set to Forward calls to phone number, the agent will continue to receive call notifications in their web adapter and are still able to answer the call there if needed.

1. Open the Availability Preferences menu in the Change status drop- down.

2. Select Forward calls to phone number.

3. Click Save. Any incoming calls for the agent will now be sent to the phone number specified in their user profile.

View an agent's phone number

You are able to see an agent's mobile phone number, but are not able to change it.

1. Go to Settings > Users & Teams.

2. Select the edit button (pencil icon) next to an agent to view the phone number.

Percent allocation groups

Percent allocation groups allow you to specify the percent of calls or chats that each group assigned to a queue will receive.

For example, a support operation might have multiple contact centers or teams that have varying levels of expertise. You can specify that Team receives 60% of incoming calls, while Team 2 gets 40% of calls from that queue.

Percent allocation groups can help direct a contractually-mandated amount of traffic to a third-party support team or BPO.

CCAI Platform Portal setup

Percent allocation is set on a per-queue basis.

• Go to **Settings > Queue ** and select the channel to edit by clicking Edit / Add.

• Select a queue.

• Click click Assign agents and then toggle to Percent Allocation Group.

• Add groups by clicking Add New Allocation Group.

• Assign agents by searching for specific agent names or team names.

• Assign the percentage of calls to each group. The total of allocations across all groups must equal 100%

• Click Save.

Operation Management settings configuration

• Go to Settings > Operation Managementand scroll to Group Settings

• % Allocation Group: Configure if the call should move to the next group if the first doesn't pick up the call in the set threshold:

  Mark the checkbox for calls/chats to also be offered to the other groups set up for the queue menu options if not picked up by the selected group after a defined length of time.

  Leave this unselected if you do not want calls or chats to go to another % allocation group. Ex. You need 50% of all of your calls to go to one team and never offer those same calls to another team or group.

Routing details

Call routing rules apply to groups first based on percentages that you set.

Example: Two groups are set up for a queue, Group 1 (60%) and Group 2 (40%)

• 60% of calls will be routed to Group 1

• 40% of calls will be routed to Group 2

Percent allocation is the first leg of the call routing journey. After a group is chosen based on the percent, then calls are routed using the Deltacast and Multicast settings you have configured.

Depending on your call routing settings, the following might take place after the initial percent allocation of incoming traffic occurs:

Example 1: Deltacast Timeout is before the Percent Allocation timeout

• The call gets routed to the longest-idle agent in the chosen group (Deltacast)

• If the agent does not pick up the call before the assigned Deltacast timeout the call will stay in the Deltacast queue and broadcast to the rest of the selected group for the duration of the percent allocation timer.

• If none of the agents from the selected group pick up the call and the setting is enabled, the call will then be Multicast to all groups.

Example 2: Deltacast Timeout is after the Percent Allocation timeout

• The call gets routed to the longest-idle agent in the chosen group (Deltacast).

• If the agent does not pick up the call before the assigned Deltacast timeout set in Operation Management it will stay in the Deltacast queue and broadcast to the longest idle agent of each group assigned to the queue for the duration of the Deltacast timer.

• If none of the Deltacast agents from the assigned groups pick up the call, the call will be Multicast to all members of all groups.

Example 3: Deltacast is not enabled

• The call will be Multicast to all agents assigned to the selected group.

• If none of the agents pick up the call before the configured timeout, the call is then broadcast to all members of all assigned groups.

Example 4: Percent Allocation > Routing Options is not enabled

• The call gets Deltacast or Multicast as configured within the assigned group.

• The call is not broadcast to any other groups assigned to the queue.

Note: If an agent is assigned to multiple groups in the same queue, they will receive calls based on the highest priority group they are a member of.

Cascade groups

Cascade groups allow multiple sets of teams or agents to answer calls for a specific queue. It also allows for tiered routing by notifying Group 1 first, then including the next group(s) sequentially. This means if your call isn't answered by one agent or group of agents, you can set up a custom routing configuration to make sure it's taken care of by the right agents. Cascade groups operate the same way with both human and virtual agents.

Cascade group behavior

• Groups are notified in numerical order. Group 1 will be notified first, then Group 2, then Group 3. Each group in the process will be notified along with previous groups after the time limit selected in Operation Management > Group Settings. The setting affects the entire environment (all queues and channels).

• If a call has moved to the next group but an agent from a higher level group becomes available, the call will always go to the agent in the highest level group.

• If no agents are available in the first group, the first group is skipped and the call is offered to the second group.

• If there are no agents assigned to the first group, the group will be skipped until CCAI Platform finds a queue with agents assigned.

• Groups of agents receiving notifications will continue to receive them after more groups are notified until the call is answered.

• Estimated Wait Time (EWT) is calculated based on all assigned cascade group agents.

• When Scheduled Calls are enabled for a queue with cascade groups, the first available agent from any cascade group will be offered the call if no agents are available to assign a call to.

• When used with Deltacast:

  • The deltacast timer and the cascade group timer start at the same time.

  • The call will only be routed using deltacast for the first attempt and will subsequently alert all agents using multicast until the call is answered.

Create groups and assign agents

1. Go to Settings > Queue.

2. Under IVR, click Edit / View.

3. Select the queue you want to add a cascade group to. Only leaf queues with no sub-queues can use cascade groups. Parent queues cannot use cascade groups.

4. In the Settings panel that appears, scroll to Channel Settings and click either Assign Virtual Agent or Assign Human Agent. Cascade groups operate the same way for both human and virtual agents.

5. Click Add New Cascade Group to create a cascade group. Each time you create a new group, it is added in sequential order. Enter the names of agents or teams to add them to the group.

6. Click Save.

Cascade group settings

• Go to Settings > Operation Management > Group Settings.

• Set the duration the system should wait for before notifying the next cascade group.

• Click Set General to save changes.

Queue priority

The queue priority feature lets you assign priority values to selected queues. Call or chat sessions from higher priority queues will then be routed to available agents first. A session is one single communication stream between an end-user and a human or virtual agent using either call or chat. Sessions typically have multiple interactions.

You can also enable prioritization by wait time, in which case the priority of a given session will automatically increase based on wait time until the session has reached the highest available priority.

Queue priority details

• When an agent is assigned to multiple queues, sessions will be routed to the agent based on queue priority order. Queue priority is calculated first by session type and then by any queue priority values assigned to the queue.

  • Session type: Three session types automatically assign a higher priority to the queue than regular inbound sessions: Sessions from priority users, scheduled calls, and transferred sessions.

  • Queue priority values: Queue priority values range from +10 to -5. The default is 0.

• You can only assign queue priority values to queues with no sub-queues (leaf queues). If a queue has a leaf queue nested within it, you cannot assign a priority value.

• The priority of calls or chats can be automatically increased based on wait time. You can configure these automatic increases to be call- and chat channel-specific. Wait time prioritization can increase priority of lower value (regular inbound) session types only.

Example routing

Example 1:

An agent is assigned to 2 queues, queue A (priority 1) and queue B (priority 2). If a transferred call arrives in queue B, and an inbound call arrives in queue A, the agent will receive the call from queue B first. The type of call (transfer in this case) is considered before any priority values assigned to the queues.

Transferred calls always have a higher priority compared to inbound calls within the same queue. If there are multiple transfers into a given queue, the call transferred from a queue with a higher priority value assigned will retain the higher priority among transferred calls in the destination queue.

Example 2:

Continuing the previous example, an agent is assigned to 2 queues, queue A (priority 1) and queue B (priority 2). If a regular inbound call arrives in queue A and a regular inbound call arrives in queue B, the agent will receive the call from queue A first. Both calls are the same type and therefore have the same priority, so the priority value assigned to the queues determines call routing.

Enable queue priority

• Go to Settings > Operation Management.

• Scroll to Queue Priority and toggle Enable Queue Priority to On.

• Optional: Click Enable Wait Time Prioritization for Calls or Enable Wait Time Prioritization for Chats if you want to increase the priority of that session type by one level for each interval of time that you set in this section. These settings ensure that a lower priority (regular inbound) sessions won't get continuously pushed back in the queue if other high priority sessions keep coming in. You can set any value above 10 and below 3600 seconds.

• Click Set Queue Priority to save.

Set queue priority level

Queue priority level is always set individually for queue.

• Go to Settings > Queue.

• Choose a channel and click Edit/View to go to the editing section for queue menus within that channel. This feature is available for the IVR, SMS, Web, Mobile, and Social (WhatsApp) channels.

• Select a leaf queue and toggle Queue Priority to On.

• Slide the call priority slider left or right to lower or raise priority level for sessions in this queue.

• Click Save Queue Priority.

Automatic redirection

Automatic redirection lets you automatically route end-users through specified workflows based on your needs.

Note: This feature is available for the IVR, Web, and Mobile channels only.

Example use cases

• There's a natural disaster in your region. You can configure the system to automatically play a message stating that your support operation is unavailable.

• You want to use your regular menu flow, but give end-users an option that takes them outside of CCAI Platform. You can automatically provide them with a phone number.

• You can give the end-user the option to go straight to voicemail and leave a message. The end-user would then be contacted when the correct agent is available (available for IVR queues only).

• You can present your end-users with product offerings based specific to their locations by directing them to a specialized web page based on user ID (available for Mobile and Web queues only).

Automated features by channel

The following table outlines the automated features available for each channel. If a cell is blank in the channel's column, that option is not available for the channel.

	IVR	Mobile	Web
Message	The message is read to the end-user using Cloud Text-to-Speech.	Message text is displayed to the end-user.	Message text is displayed to the end-user.
Phone Number	Routes the caller to another number.	Routes the caller to another number.
Queue	Redirects the end-user to another queue. You have the option to set a message specific to calls being redirected to that queue.
Voicemail	Routes the end-user to a voicemail queue. You can optionally customize the voicemail greeting for the queue.
Website		Enter a mobile-friendly URL to display a web page, insert a mobile app identifier, or insert a User ID.	Enter a mobile-friendly URL to display a web page, insert a mobile app identifier, or insert a User ID.
Outbound SIP Header	Automatically redirects the end-user to any platform that can handle SIP calls.

Formats:

• Message: Up to 600 characters. To add a hyperlink to the message, use the following format: {​{https://www.ujet.co \| Visit our website}​}
• Phone Number: Enter a number with + and the country code. For example, the United States number [phone] should be formatted as: [phone]. Numbers with extensions are not accepted.
• Website: URL must be to a mobile-friendly website. For more information on dynamic includes see the queue and menu setup documentation.
• Outbound SIP Header: Enter the Destination SIP URI in sip: +ccNumber@fqdn format. This is the endpoint to which calls to this queue should be redirected. For more information about SIP headers, see the data parameters documentation

Configure automatic redirection

• From the CCAI Platform Portal, go to Settings > Queue.

• Choose a channel, then click Edit / View to see the editing section for queue menus in that channel.

• Select a queue to edit. The Settings panel appears. Toggle Automatic Redirection to Show.

• Select your automatic redirection options and configure them according to the previous section.

• Click Set Redirection.

Auto-answer

Auto Answer connects calls and chats to agents without agents needing to click to pick up. This feature applies to inbound sessions and transfers. Deltacast must be enabled in order to use auto-answer.

If enabled, auto-answer uses Deltacast to route the session to the longest idle agent in the first group. You must enable auto-answer at a global level in order to use the feature. You also have the option of configuring auto-answer at the queue level.

Enable auto-answer globally

1. Make sure deltacast is enabled for calls or chats.

2. Go to Settings > Call or Settings > Chat.

3. Toggle Auto Answer to On.

Set auto-answer at the queue level

Queues that already exist when you enable auto-answer globally will default to auto-answer being Off. All new queues created after you're enabled auto-answer globally will default to On

1. Go to Settings > Queue.

2. Select your channel and click Edit / Add, then click your desired queue.

3. In the Settings panel, scroll to Call Auto Answer or Chat Auto Answer and slide the toggle Off or On.

Set default agent status

To prevent agents from getting auto-answer sessions before they're ready, you can preset a default status for agents who have just logged in.

1. Go to Settings > Operation Management > Agent Status.

2. Under Agent Status on Login, Choose whether to use the last agent status before logout, or to set a default status.

(Call only) Caller messages and announcement settings

Call whisper and/or call countdown alerts the agent to the connecting call. We recommend that you enable these features when you use auto-answer for calls. See Agent Call Messages & Notifications for details and recommendations.

Agent experience: Call

When the call is assigned and is about three seconds from being connected:

1. A browser notification displays Call Auto Answered plus the call type and queue name of the call. When clicked, the notification brings the agent to the appropriate screen and the call is auto-answered regardless of whether the agent is on the screen with the call adapter. A tab will load with the agent widget and the ticket loaded in the background.

2. (Optional) The agent will hear an audio message with the call information "{Call Type} from {Queue Name} starting in 3, 2, 1...".

Agent experience: Chat

1. When the chat is assigned to an agent and is approximately three seconds from being connected, the agent receives a browser notification: New Chat Picked Up.

2. When the agent clicks on the notification, they are taken to the Chat Adapter. The newest chat is always at the top of the chat list. Newly- assigned chats are marked by a red indicator.

Auto-answer behavior with additional features and settings

Deltacast: Auto-answers for the agent receiving the Deltacast session.

Deltacast for cascade groups/percent allocation: Auto-answers for the assigned agent according to routing logic.

Transferred sessions: If a session is transferred to a queue, it will follow the queue's auto-answer settings.

Call only:

Scheduled calls (Mobile and Web channels): When the call is auto-answered and whisper is enabled, an audio message will announce that the call is a scheduled call.

Calls with user segmentation applied: When the call is auto-answered and whisper is enabled, an audio message will announce that the call is a high-priority user segment call.

Monitoring and reporting

You can monitor auto-answerd and manually picked up calls in real-time on the Call Monitoring page.

To view auto-answer call data, go to Reports > Agents & Teams. You can specify all agents or enter individual agents or teams, then choose either call or chat data. Under Aggregate Metrics, select Total Auto Answered Calls or Total Auto Answered Chats to view this information in the downloaded report.

Calls only: Due to the call whisper and call countdown, the minimum wait duration for auto-answered is 12 seconds unless the whisper read-out speed is reduced.

API

You can use the CCAI Platform API to retrieve the session answer type (auto or manual) from the /chats or /calls endpoint.

• Field: answer_type
• Type: string
• Required: Yes
• Values:
  • auto
  • manual