Agent Capacity Rule
In Multimedia, a rule that specifies the maximum number of interactions of each media type that an agent can handle. Agent capacity rules are used in routing. If an agent is up to capacity for a given media type, the strategy still may send that agent additional interactions of other media types. An agent may have different settings for different media types; for example, a capacity rule may classify the agent as busy for chat interactions (he or she already is engaged in a chat), but not busy for e-mail interactions (he or she may be sent additional e-mail interactions).
Glossary
Customizing the Engagement Strategy
Contents
- 1 Customizing the Engagement Strategy
- 1.1 Main Interaction Process and Workflow
- 1.2 Engagement Policy (Decision Workflow)
- 1.3 Obtaining Data from the GWE Cassandra Database through REST Requests
- 1.4 Start Engagement as a Result of the Engagement Logic Strategy
- 1.5 Cancelling Engagement as a Result of the Engagement Logic Strategy
- 1.6 Cleaning Interaction Process
- 1.7 Propagating Data from Engagement Logic strategy into Chat Routing Strategy
- 1.8 Accessing Pacing Information from the Engagement Logic Strategy
When you create your Web Engagement application, Genesys Web Engagement also creates default Engagement Logic and Chat Routing SCXML strategies in the \apps\application_name\resources\_composer-projects\ folder. Orchestration Server (ORS) uses these strategies to decide whether and when to make a proactive offer and which channels to offer (chat or web callback).
The Engagement Logic strategy processes Genesys Web Engagement interactions, and consists of sub-workflows to handle: general processing, decision making, obtaining additional information from the Cassandra database through the REST API, and contacting the Web Engagement Server with instructions according to the engagement (or non-engagement) process.
You can modify the Engagement Logic SCXML by importing the Composer project into Composer. The project is located here: \apps\application name\resources\_composer-projects\WebEngagement_EngagementLogic\. Refer to the sections below for details about the Engagement Logic strategy and how it can be modified.
Main Interaction Process and Workflow
When Genesys Web Engagement creates an engagement attempt, the Web Engagement Server creates an Open Media interaction of type webengagement and places it into the interaction queue specified by the queueQualified option. By default, this option is set to the Webengagement_Qualified queue. Orchestration Server (ORS) monitors this queue and pulls the interaction to process it with the Engagement Logic strategy.
Passing Parameters into the Engagement Logic Strategy
When Genesys Web Engagement creates an engagement attempt, the Web Engagement Server creates an Open Media interaction of type webengagement and places it into the Interaction Queue specified by the queueQualified option. By default, this option is set to the Webengagement_Qualified queue. Orchestration Server (ORS) monitors this queue and pulls the interaction to process it with the Engagement Logic strategy.
Since ORS does not connect to the Web Engagement Server(s), certain parameters must be passed to the Engagement Logic strategy in order to provide ORS with the data it needs.
- The address where the SCXML strategy is located. Note: The default Engagement Logic and Chat Routing strategies are located as resources under the Web Engagement Server. Provisioning automatically specifies this address in the related Configuration Server objects when GWE is installed. Since you can host strategies in other places, you can manually update the parameters in the related objects.
- The address where the Web Engagement Server can be accessed (if a secure address is present, pass this as well). This information is used to issue REST requests to the GWE Cassandra database and to start or cancel the engagement procedure through the Web Engagement Server.
The parameters are passed to ORS through the Enhanced Routing script object Webengagement_Qualified.Routing that is associated with the Webengagement_Qualified Interaction Queue.
There are several parameters specified by default, as shown in the following image.
The first set of parameters, (1) serverURL and serverURLSecure correspond to the (2) BackendURL and BackendURLSecure parameters used in 8.1.2, which are still available, but are now deprecated. You can also set (3) the maximum number of engagement attempts and (4) the maximum number of simultaneous engagements.
In cases where you need a separate address for chat processing, use the mediaServerURL parameter. This parameter is similar to the serverURL parameter but is used to specify a separate URL to be used only for chat processing. This can be useful in situations where:
- Event traffic uses a non-secure server (as specified by the serverURL parameter), but you need a secure connection for your chat traffic (in which case mediaServerURL will specify an HTTPS endpoint)
- Event traffic is processed on one port, but chat traffic needs to be processed on a second port on the same host
The Engagement Logic strategy has two interaction processes:
- clean.ixnprocess — This process is explained in Cleaning Interaction Process
- queueBased.ixnprocess — This process features the major logic for the strategy.
In this section, we will consider the second one.
To access the above-mentioned parameters from within Composer, use the Composer Access Project Variables button shown in the following image. Note: In order to access Project Variables, your current tab in Composer must display Interaction Process (not Workflow).
This button opens a window containing the variables we are currently interested in:
Now let's take a look at queueBased.ixnprocess. Select it in the Package Explorer:
The entry point Interaction Queue (Webengagement_Qualified) is shown here:
And its properties are here:
After the interaction is taken into processing, it is placed into a set of workflows for processing. All workflows have notes related to specific blocks, however, this document highlights the most important items.
Preventing Interaction Termination into Sub-flows
For all workflows, you must make sure that the workflow is configured to not terminate the interaction upon exiting. If this step is not followed, the entire interaction process will not be able to finish due to termination of the interaction in one of the sub-flows.
Note: Out-of-the-box Engagement Logic strategies already have the correct specified value (0) for the system.TerminateIxnOnExit variable.
You must perform the following steps to turn off the termination of the interaction at the end of the sub-flow:
- Open the workflow diagram in Composer (note that in the images, it is shown as default.workflow).
- Select the Entry block.
- Open the properties of this block and access the Global Settings > Variables.
- Locate the variable system.TerminateIxnOnExit. In this case, we have filtered the variables so only those that contain the string Terminate are showing. Set the value to 0.
Accessing User Data from the webengagement Interaction and Passing it into Sub-flows
One of the most important features of the Engagement Logic is its ability to access User Data from webengagement interactions. This data is populated by the Web Engagement Server and includes, among other things, information provided by a pacing algorithm.
In previous releases of Genesys Web Engagement, this information was only available in JSON format and needed to be parsed by the strategy in order to be easily used. If you are using a strategy from release 8.1.2, you can still use access JSON data by specifying 8.1.2-compatible user data.
After data is parsed and assigned to variables, it can be propagated to sub-flows and used there. Sub-flows are also able to pass output data in a backward direction.
In the following example, we show the TakeEngagementDecision subroutine:
Then, you can see its parameters, which are displayed in a Composer window below the workflow diagram:
Let's consider the parameters we are passing into decision.workflow, including event_chatChannelCapacity and event_webcallbackChannelCapacity, as well as the parameters we are receiving from the workflow, including,cancelCode, cancelDescription and decision:
Attached Data in Web Engagement 8.5
As specified in the following tables, Genesys Web Engagement 8.5 supports key-value pair–based user data that is useable by Genesys Reporting, in addition to making 8.1.2-compatible data available.
8.1.2-Compatible Data
Previous releases of Genesys Web Engagement provided JSON-based user data. If you would like the Web Engagement Server to continue to attach 8.1.2-style data, set the attach812StyleUserData option in the [userData] section to true, which provides access to the following two fields:
| Key | Type | Description |
|---|---|---|
| ScheduledAt | UTC-based timestamp of "Now" | This parameter is used by Orchestration to pull interaction into cleaning strategies if for some reason it was not not processed by Engagement Logic strategy |
| jsonEvent | String, which contains JSON object | GWE 8.1.2-compatible field. Will be attached only if the attach812StyleUserData option is set to true. |
Mandatory Actionable Event Fields
| Key | Contents | Description |
|---|---|---|
| HotLead_eventID | UUID | eventID obtained from Actionable event |
| HotLead_eventName | String | Actionable event name. |
| HotLead_visitID | UUID | visitID obtained from Actionable event |
| HotLead_globalVisitID | UUID | globalVisitID obtained from Actionable event |
| HotLead_pageID | String | browserPageID obtained from Actionable event |
| HotLead_url | String | url obtained from Actionable event |
| HotLead_languageCode | String | languageCode obtained from Actionable event |
| HotLead_timestamp | long | timestamp obtained from Actionable event |
| HotLead_category | String | category obtained from Actionable event |
| HotLead_rule | String | rule obtained from Actionable event |
Web Engagement Server Data
| Key | Type | Description |
|---|---|---|
| HotLead_engagementID | UUID | ID of Engagement Profile associated with webengagement interaction |
| HotLead_engagementAttempts | int | Count of engagement attempts (accepted and rejected) that happened already on this visit |
| HotLead_engagementsInProgress | int | Count of currently active engagement attempts |
| pacing_chatCapacity | int | Actual capacity of chat channel, predicted by pacing |
| pacing_webcallbackCapacity | int | Actual capacity of webcallback channel, predicted by pacing |
| pacing | String | JSON object, which includes detailed group-based pacing information |
Optional Fields
| Key | Type | Description |
|---|---|---|
| HotLead_<customFieldName> | String | Field with name <customFieldName>, obtained from data object of actionable event. List of fields should be specified in the option eventType.ACTIONABLE ([userData] section) For example: 1) Actionable event has data fields "myCustomField" and "myAnotherCustomField": "data": {"myCustomField": "SomeValue", "myAnotherCustomField": "SomeAnotherValue"} 2) eventType.ACTIONABLE has value "myCustomField" GWE 8.5 will attach to the User Data only the following pair: "HotLead_myCustomField": "SomeValue" |
| VisitStarted_<customFieldName> | String | Field with name <customFieldName>, obtained from data object of VisitStarted event. List of fields should be specified in the option eventName.VisitStarted ([userData] section) The following keys are available: "userAgent", "screenResolution", "language", "timezoneOffset" In OOB template option eventName.VisitStarted has value "timezoneOffset" Correspondingly, GWE 8.5 will attach to the User Data the following pair: "VisitStarted_timezoneOffset": 25200000 (value will depend on visitor's timezone) |
| SignIn_<customFieldName> | String | Field with name <customFieldName>, obtained from data object of SignIn event. List of fields should be specified in the option eventName.SignIn ([userData] section) List of available keys depends on customer's workflow |
| UserInfo_<customFieldName> | String | Field with name <customFieldName>, obtained from data object of UserInfo event. List of fields should be specified in the option eventName.UserInfo ([userData] section) List of available keys depends on customer's workflow |
Engagement Policy (Decision Workflow)
Engagement policy is the other name of decision workflow.
Consider the most important points provided by the out-of-the box strategy:
Count of Engagement Attempts
Check the count of engagement attempts already proposed to the current visitor.
To see where this check is executed open decision.workflow:
Looking at the workflow, you can select the ApplyEngagementPolicy block:
In the properties for this block, select Branching > Conditions and open CorrespondsToPolicy:
CorrespondsToPolicy is an expression that uses application parameters from the Webengagement_Qualified.Routing script object to determine how many engagement attempts should be proposed for a particular visitor. Note: Engagement attempts in the current visit that were closed with a timeout disposition code will not be taken into account, as there is no guarantee whether the visitor has seen them. For example, the invitation may appear on a non-active browser tab or window.
Pacing Information
Check pacing information. This is executed inside of the CheckPacingEngagementChannel block:
Note: The out-of-the-box strategy operates only on general information obtained from the pacing algorithm: in particular, the event_chatChannelCapacity and event_callbackChannelCapacity variables, which are passed from default.workflow, contain the accumulated (by channel) count of interactions that can be triggered at a particular moment. You can also pass more detailed information provided by the pacing algorithm into the decision workflow and build a more sophisticated decision maker. The images below show the general idea: do not engage the visitor if the count of available "interactions to produce" is 0 for both channels:
Obtaining Data from the GWE Cassandra Database through REST Requests
Requesting data from Web Engagement Server through the REST
During the decision making process, it might be useful to access data from the Web Engagement Cassandra database. For example, to check additional parameters that are collected there.
The out-of-the-box Engagement Strategy provides an example of accessing the Cassandra database in order to get the TimezoneOffset of the visitor's browser, and correspondingly modify the greetings good evening, good morning, and so on. Note: the SCXML State block that is used to demonstrate these concepts is disabled by default in Web Engagement 8.5. It has only been retained as a sample, because the GWE 8.5 server provides related information as a part of the User Data in the webengagement open media interaction.
Consider how Engagement Strategy does this task.
- Use the SCXML State block in order to make the REST request with specified parameters.
Note: The ServerURL and visitID parameters are passed from the parent workflow into this sub-flow. - Parse response to the REST request. After the response is successfully obtained, it should be parsed in order to extract required data. In this example, the timezoneOffset parameter is obtained from the data of the VisitStarted event:
Note: Alternatively, instead of the SCXML State block, you can use a Web Request or Web Service block. In this case, Composer requires this logic to be hosted as a web application, which means the entire Composer project must be hosted outside of the Web Engagement application. With Composer, you can export the project as a web application in WAR format. This approach is not used in out-of-the-box strategies.
Configure Authentication in the out-of-the-box SCXML Strategy
Genesys Web Engagement 8.1.2 and higher provides basic access authentication on the base of providing username/password pairs.
Username and password parameters, used in the SCXML State block, are passed into getRESTInfo workflow from the parent workflow:
The username and password parameters are specified in variables of the Entry block in default.workflow:
You must check that these credentials are compliant with the credentials specified in the security section of the Web Engagement Cluster or Web Engagement Server options:
See Configuring Authentication for details.
Start Engagement as a Result of the Engagement Logic Strategy
Sending the "start engage" Request to the Web Engagement Server
The special workflow engage.workflow notifies the Web Engagement Server about the start engage command.
Notification of the Web Engagement Server is executed through the REST request using the SCXML State block:
Note: Authentication aspects shown here are the same in getRESTInfo.workflow.
Fulfilling IxnProfile for "start engage" Request
Take note of the IxnProfile structure, which is passed in REST request to the Web Engagement Server. This structure is fulfilled in the ECMA Script block called FulfillEngagementProfile.
The following object is sent to the Browser:
ixnProfile = {
'data': data
}Consider the structure of the data object:
var data = {
'profile': engageProfile,
'notification': notification_message
}As you can see, there are two fields:
- profile — represented by the variable engagementProfile.
- The content of this variable will be considered below. You can change the content of this variable if the SCXML strategy worked in the area of visitor identification.
- It is not recommended to change it if related items are not a part of your modified strategy.
- notification — represented by the variable notification_message.
The structure of the notification message is described in Chat Invitation Message and Callback Invitation Message.
Structure of the engagementProfile variable
| Field name | Field contents | Description |
|---|---|---|
| engagementID | UUID | Auto-generated field which identifies exactly one engagement attempt |
| visitID | UUID | visitID of current session (obtained from HotLeadActionableEvent) |
| globalVisitID | UUID | globalVisitID of current session (obtained from HotLeadActionableEvent) |
| webengagementInteractionID | String | ID of "webengagement" OM interaction associated with this Engagement Profile |
| pageID | String | PageID identified specific tab in browser (obtained from HotLeadActionableEvent) |
| category | String | List of categories specified in HotLeadActionableEvent |
| rule | String | Name of rule, which triggered this HotLeadActionableEvent |
| userID | String | String, which allows to identify authorized and recognized visitors For anonymous users it will be null |
| userState | String | State of current visit: Anonymous, Recognized or Authorized |
| firstName | String | First name of non-anonymous user |
| lastName | String | Last name of non-anonymous user |
| userData | String | JSON string which represents User Data, collected on webengagement OM interaction before submit and in the Engagement Logic strategy |
You can change the fields firstName, lastName and state in the case of additional work being executed in the visitor identification area. In this case, the Web Engagement Server applies passed values to the identity record of the specified engagementId.
Cancelling Engagement as a Result of the Engagement Logic Strategy
Sending "cancel engagement" to Web Engagement Server
This is similar to sending start engage, request cancel engagement; it also uses the SCXML State block to trigger a REST request to the Web Engagement Server:
Security (authentication) aspects are the same as described in the getRESTInfo.workflow.
Fulfilling "no engage" Data
no engage data is available in the script properties of the FulfillNoEngagementData block:
It contains six mandatory fields:
Cleaning Interaction Process
In GWE 8.1.2 the cleaning process was responsible for removing stuck webengagement interactions. An interaction can be stuck in one of the interaction queues for various reasons. For example:
- Visitor obtained engagement invitation. This means that the webengagement interaction was put into the Webengagement_Accepted queue.
- Power-off appeared on visitor's host, so the answer (Accept, Reject, or Timeout) was not delivered to Genesys Web Engagement.
In this case, you need to define the cleaning process, which is also built on the top of ORS strategies.
The cleaning interaction process in Web Engagement 8.5 also carries out some other important functions. It is responsible not only for cleaning stuck interactions, but also for the entire life cycle of webengagement Open Media interactions, including these functions:
- Detecting when an interaction should be moved into a specific Interaction Queue
- Moving an interaction through the Interaction Queues
- Detecting when an interaction should be terminated
- Terminating an interaction
The Cleaning process has 6 entry points:
- Webengagement_Engaged
- Webengagement_Accepted
- Webengagement_Missed (new in GWE 8.5)
- Webengagement_Rejected
- Webengagement_Failed
- Webengagement_Timeout
Note that the Webengagement_Qualified queue is no longer monitored by the Web Engagement 8.5 cleaning process. It is only used in the main process.
The cleaning process has two workflows:
- waitForDisposition.workflow
- clean.workflow
The waitForDisposition.workflow only works with the Webengagement_Engaged queue, while clean.workflow works with all other queues and is extremely simple, as it only stops the interaction.
The "Wait for disposition" flow
This new workflow is dedicated to listening for User Data changes in webengagement interactions and deciding which Interaction Queue the interaction should be moved to.
The interaction's disposition code (accept, reject, and so on) will be available in User Data as a key-value pair with a key of dispositionCode. As soon as the dispositionCode key-value pair is obtained, the result will be analyzed.
Here are the valid values for dispositionCode and the queues their interactions are placed in:
| Value | Description | Queue |
|---|---|---|
| accept | The visitor has accepted the engagement invite | Webengagement_Accepted |
| cancel | The visitor has cancelled the engagement invite | Webengagement_Rejected |
| timeout | The engagement invite has timed out | Webengagement_Timeout |
| pageExit | The visitor has exited the page | Webengagement_Failed |
Notes
- For all other disposition code values, the associated interaction will be placed in the Webengagement_Failed queue.
- If the disposition code is not defined, the strategy will wait for the next User Data change or for a timeout.
- Disposition codes values are case-sensitive. For example, on receiving a disposition code of Accept (instead of accept) Web Engagement will place the associated interaction in the Webengagement_Failed queue
- If a timeout occurs, the interaction will be placed in the Webengagement_Timeout queue.
The "Cleaning" flow
The cleaning flow is quite simple: it stops the interaction. It operates with 5 terminal Interaction Queues:
- Webengagement_Accepted
- Webengagement_Missed
- Webengagement_Rejected
- Webengagement_Failed
- Webengagement_Timeout
As soon as the interaction reaches one of these queues, it will be stopped by the strategy.
Propagating Data from Engagement Logic strategy into Chat Routing Strategy
Use Case Description
In the routing process, it often makes sense to use business data from events that are produced on the browser side. The Web Engagement Server automatically attaches this data to the User Data of the webengagement interaction, but you can also propagate it to the chat or web callback interactions.
For example:
- Business data produced on the page provides information about language.
- This information is passed as a User Data key into the webengagement interaction.
- During the Engagement Logic strategy, language information is re-attached and propagated to the chat interaction.
- The Chat Routing strategy reads language information from the User Data of the chat interaction and decides into which group to route the chat interaction.
The following are details of the described data propagation.
Attach UserData to the webengagement Interaction
All of the User Data contained in a webengagement Open Media interaction can be propagated into a media interaction created on the top of the webengagement interaction.
The propagated fields are controlled by the keysToPropagate option in the [userData] section.
Additionally, you can collect data in the Engagement Logic strategy and attach it to the webengagement interaction by using the User Data block, then you can add related fields into the keysToPropagate option.
Control Copying UserData from webengagement Interaction to the Chat (or web callback) Interaction
When a chat or web callback interaction is created, GWE attaches the UserData available in its parent Open Media webengagement interaction. You can control how this data is attached by using the keysToPropagate option in the [userData] section of the Web Engagement Server application. This option has three modes:
- Copy all UserData
- Do not copy UserData
- Copy only specific KV pairs from UserData
The following tables provide example values for the keysToPropagate option. In these examples, the Open Media webengagement interaction UserData contains the keys ORS Data, rule, strategy, some data.
| Value of keysToPropagate | Data in the engagement interaction |
|---|---|
| all | All keys are copied: ORS Data, rule, strategy, some data. |
| no | No keys are copied. |
| rule;strategy | The rule, strategy keys are copied. |
| blank or empty | If the value of keysToPropagate is absent or has an empty value, no keys are copied. |
| my_key1;ORS Data | The ORS Data key is copied. my_key1 is ignored because it is not part of the keys in the Open Media webengagement interaction UserData. |
Accessing Pacing Information from the Engagement Logic Strategy
In release 8.5, Web Engagement provides the Engagement Logic strategy with pacing data for the chat and web callback channels. You can access pacing information in two ways:
- Through the consolidated channel capacity (measured in the number of "allowed" interactions).
- Through detailed information for each channel, which contains capacity (measured in the number of "allowed" interactions) for each particular group in a channel.
Pacing information is added to webengagement open media interaction User Data by the Web Engagement Server. This information can then be read in the SCXML strategy — see Main Interaction Process and Workflow for an example. The information is located (among other specific data, such as the data provided in business events) in the User Data of the webengagement interaction, as described above in the section on Accessing User Data from the webengagement Interaction and Passing it into Sub-flows.
Understanding How the Pacing Algorithm Works
A dedicated pacing algorithm serves each particular group of agents, so if you have 2 chat-oriented and 1 web callback-oriented group of agents, there will be 3 instance of the pacing algorithm (1 for each group).
The agent availability on the specific channel is calculated taking into account the following:
- The agent state on the particular media (chat and web callback are different)
- Capacity rules.
For example, consider an agent who has a capacity rule for 2 chat interactions. In this scenario, the following statements are true:
- Agent is Ready and has no interactions in progress. In this case, the agent is treated as 2 Ready agents with a capacity rule of 1.
- Agent is Ready and has one interaction in progress. In this case, the agent is treated as 1 Ready agent with a capacity of 1.
- Agent is Ready and has two interactions in progress. In this case, the agent is treated as 0 Ready agents with a capacity of 1.
- Agent is Not Ready (count of interactions in progress does not matter). In this case, agent is treated as 0 Ready agents with a capacity of 1.
The agent availability on the specific channel is also handled differently in the two main pacing algorithm methods, SUPER_PROGRESSIVE and PREDICTIVE_B.
The SUPER_PROGRESSIVE method consumes the following major parameters:
- The number of Ready agents in the group.
- The number of pending (waiting for answer) interactions.
- HitRate - the percentage of accepted invitations compared to the general number of proposed engagement invitations.
Consider the following example: There are 7 Ready agents (each with a capacity rule of 1), the number of pending interactions is 5, and the HitRate is 0.05.
In this case, the pacing algorithm might predict the number of allowed interactions approximately as (7 / 0.05 - 5) = 135.
The PREDICTIVE_B method consumes the following major parameters:
- The number of logged in agents in the group.
- The Average handling time of interactions. For example, the average duration of a chat session with visitors.
- HitRate - the percentage of accepted invitations compared to the general number of proposed engagement invitations.
This algorithm is more complex than SUPER_PROGRESSIVE, but the general information described for SUPER_PROGRESSIVE also applies to PREDICTIVE_B: The number of 'allowed' interactions will significantly exceed the number of Logged In agents (depending, first of all, on the HitRate parameter).
Consolidated Pacing Information by Channel
Capacity for the chat channel is available in the pacing_chatCapacity field and capacity for the web callback channel is available in the pacing_webcallbackCapacity field.
For example:
pacing_chatCapacity:12
…
pacing_webcallbackCapacity:0
…Detailed Pacing Information
Detailed pacing information is available as a nested JSON object with the following structure:
pacing: {
channels :
[
{
name: <name of this channel>,
groups:
[
{
name: <name of this group>,
capacity: <count of allowed interactions for this group>,
reactiveTrafficRatio: <portion of inbound chat\webcallback traffic that should be 'left' in the system>
},
...
],
capacity: <count of allowed interactions for this channel>
},
...
]
}You can access detailed information in the Engagement Strategy SCXML as follows:
var pacingData = JSON.parse(_genesys.ixn.interactions[system.InteractionID].udata.pacing);
var currentChannel = undefined;
var channel = undefined;
var chatChannel = undefined;
for (channel in pacingData.channels) {
currentChannel = pacingData.channels[channel];
if (currentChannel.name=='chat') {
chatChannel = currentChannel;
break;
}
}
var englishChatGroupCapacity = undefined;
var group = undefined;
var currentGroup = undefined;
if (chatChannel != undefined) {
for (group in chatChannel.groups) {
currentGroup = chatChannel.groups[group];
if (currentGroup.name=='English Skill Group') {
englishChatGroupCapacity = currentGroup.capacity;
break;
}
}
}Example of Using Pacing Information
Agents
Consider the following scenario where there are four chat and voice groups with agents in each group:
- English Language Chat Group = Adam (logged in and ready) and Anna (logged in, not ready)
- Dutch Language Chat Group = Bart (NOT logged in) and Berta (NOT logged in)
- English Language Voice Group = Adam (logged in and ready) and Amanda (logged in and ready)
- Dutch Language Voice Group = Dan (logged in, ready)
The following group configuration options are set on the Web Engagement Cluster application:
- chatGroups = English Chat Group;Dutch Chat Group
- voiceGroups = English Voice Group;Dutch Voice Group
Customers
On the customer-facing website, two events are triggered simultaneously:
- Chris triggers a Hot Lead event on an English page.
- Merijn triggers a Hot Lead event on a Dutch page.
Pacing information
When events are triggered simultaneously, pacing information is the same. In this scenario, the SUPER_PROGRESSIVE algorithm is used and the following parameters were true at the moment the events were triggered:
- English Chat Ready agents: 1
- Dutch Chat Ready agents: 0
- English Voice Ready agents: 2
- Dutch Voice Ready agents: 1
- HitRate: 0.2
- Pending engagement invites: 0
- Reactive traffic is turned off
In this case, the results might look like this:
...
chatChannelCapacity : 5,
webcallbackChannelCapacity : 16,
pacing: {
channels :
[
{
name: "chat",
groups:
[
{
name: "English Language Chat Group",
capacity: 5,
reactiveTrafficRatio: 0
},
{
name: "Dutch Language Chat Group",
capacity: 0,
reactiveTrafficRatio: 0,
}
],
capacity: 5
},
{
name: "webcallback",
groups:
[
{
name: "English Language Voice Group",
reactiveTrafficRatio: 0,
capacity: 11
},
{
name: "Dutch Language Voice Group",
reactiveTrafficRatio: 0,
capacity: 5
}
],
capacity: 16
}
]
}Possible Engagement Logic SCXML flows
In this scenario, the following SCXML flows are possible for the two customers, Chris and Merijn:
- Chris
- We can extract the capacity for the "English Language Chat Group" (5) and "English Language Voice Group" (11) from the pacing data.
- In the decision workflow, it is possible to engage Chris on the chat or web callback channel. It is also possible to show him a modified invitation, where he can explicitly choose chat or web callback.
- Merijn
- We can extract the capacity for the "Dutch Language Chat Group" (0) and "Dutch Language Voice Group" (5) from the pacing data.
- In the decision workflow, it is possible to engage Merijn on the web callback channel only.