Sample Business Process: Facebook BP-iWD

Facebook BP-iWD is a sample Business Process that shows how Genesys Social Messaging can work with Genesys Intelligent Workload Distribution (iWD). Facebook BP-iWD is supplied on the Genesys Social Messaging Management product CD and is used together with two of the Business Processes that are supplied with iWD, as described below.

Requirements

To use Facebook BP-iWD:

• Install Facebook BP. This creates some configuration objects that are required by Facebook BP-iWD.
• Use the iWD Setup Utility to install these Business Processes:
  • Standard Genesys to iWD Adapter
  • IWDBP

For information on how to install and use the iWD Setup Utility, consult the intelligent Workload Distribution Deployment Guide.

Important

iWD Setup Utility is no longer supported from iWD release 8.5.104 onwards. From that release onwards, all configuration is done manually. See Manual Installation of iWDBP.

In Release 8.1.0

Facebook BP-iWD and its associated Business Processes do the following things.

1. Facebook BP-iWD proceeds in the following stages:
   1. A query is sent to Interaction Server to see if there is already an interaction down the flow in the strategy with the same Facebook Post ID.
      • If such an interaction is found, it is updated with the content (merged) of the newer interaction, then the newer interaction is terminated.
      • If no such interaction is found in the strategy, then this current interaction proceeds into the Buffer stage, which delays the delivery of the interaction to the agent queue.
   2. The Buffer stage periodically checks if an interaction with this Post ID can be delivered to the agent desktop; in other words, if there is an interaction with the same Post ID being processed by any agent in the group.
      • If there is such an interaction, the current interaction is delayed in the buffer stage.
      • If there is no such interaction, it proceeds to the Classification and Screening stage.
   3. The Classification and Screening stage tries to classify and screen the interactions that will be delivered to the agent group. Note the following:
      • This stage uses:
        • A subroutine that screens for sentiment and actionability.
        • A subroutine that classifies for sentiment.
      • Routing decisions can be made based on the classification/screening results. One way of doing this is presented in the sample BP, which you can modify. All the results are attached to the interaction, and can later be viewed on the agent desktop in the attached data tab.
   4. The last stage passes the interaction to Standard Genesys to iWD Adapter.
2. Standard Genesys to iWD Adapter attaches some required key-value pairs to the interaction, then passes the interaction to IWDBP.
3. IWDBP performs classification, prioritization, distribution, and archiving.

Important

For the MergeItxData method in the ESP block of Facebook Inbound Strategy to work properly, the settings/delay-updates option in Interaction Server should be set to false. With this setting, Interaction Server forces updates of interaction properties in the database each time it processes RequestChangeProperties.

For more information about the Standard Genesys to iWD Adapter and IWDBP Business Processes, see the intelligent Workload Distribution 8.1 Deployment Guide.

In Release 8.1.1 and Later

1. Facebook Inbound Strategy-iWD can be described in two main steps.
   1. The first step depends on whether you want to create a contact record for each author of a comment to a Facebook post. If you do, you must set the x-submit-comments-itx option to true, which makes the system create an interaction for each comment (this is in addition to the interaction that it creates containing both the base post and all of the comments on it).
      • If the interaction being processed is one of these comment-only interactions, it is sent to the Stop Interaction Comments in Parking Queue strategy, which creates a contact for the author of the comment, then terminates.
      • If the interaction consists of a post plus comments, it continues to the next step.
   2. This step determines whether this interaction contains comments on some post that is already in the strategy and so should be merged with it.
      1. A query is sent to Interaction Server to see if there is already an interaction down the flow in the strategy with the same Facebook Post ID.
      2. Then,
         • If such an interaction is found, it is updated with the content of (merged with) the newer interaction, then the newer interaction is terminated.
         • If no such interaction is found in the strategy, then this current interaction proceeds into the buffer stage, which delays the delivery of the interaction to the agent queue.
2. Facebook Inbound Buffer Strategy-iWD is similar to the preceding, but it determines whether this interaction contains comments on some post that has already been delivered to an agent. If it does, the interaction is held until that agent can accept delivery of it.
   1. The buffer stage periodically checks if there is an interaction with the same Post ID being processed by any agent in the group.
   2. Then,
      • If there is such an interaction, the current interaction is delayed in the buffer stage until it can be delivered to the agent who is processing the earlier related interaction.
      • If there is no such interaction, it proceeds to the classify and screen stage.
3. Facebook Classification-Screen Strategy-iWD tries to classify and screen the interactions that will be delivered to the agent group. Note the following:
   • The strategy organizes the task as follows:
     • The strategy itself screens and classifies posts for sentiment and actionability.
     • One subroutine screens comments for sentiment and actionability.
     • One subroutine classifies comments for sentiment and actionability.
   • Routing decisions can be made based on the classification/screening results. One way of doing this is presented in this Business Process: All the results are attached to the interaction, and can later be viewed on the agent desktop in the attached data tab.
4. Facebook Calculation Strategy-iWD processes all previously-attached classification and screening keys and attaches the keys desktop_sentiment, desktop_actionable, and desktop_expand, which the desktop uses in presenting the interaction in its user interface.
5. Facebook iWD Delivery Strategy delivers the interaction to iWD.

Important

For the MergeItxData method in the ESP block of Facebook Inbound Strategy-iWD to work properly, the settings/delay-updates option in Interaction Server should be set to false. With this setting, Interaction Server forces updates of interaction properties in the database each time it processes RequestChangeProperties.

In Release 8.1.4

Starting in this release, Facebook BP-iWD:

• Filters out interactions of type question. That is, if the substring "<type>question</type>" occurs in the _facebookXML value of an interaction, the interaction is terminated.
• Checks for interactions of type facebooksession (Facebook chat) in inbound strategies: FacebookItxType=10. If the type is facebooksession, the interaction skips the rest of the Facebook Inbound Strategy-iWD and Facebook Buffer Strategy-iWD, and goes straight to the Facebook Classify-Screen Strategy.

In Release 8.5.1

In Facebook Classify-Screen Strategy and Facebook Calculation Strategy, the KVListSetData function is used instead of KVListAddData. KVListSetData does not create duplicate keys.