Seamless experience across Digital Messaging Channels
|Request to Publish||Yes|
|Description||Seamless experience across Digital Messaging Channels|
|Version as of||8.6|
|Capability/Industry Area||Conversational Channels|
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.
When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Pega 8.6 has introduced Digital Messaging (Known as Unified Messaging in prior versions) as a channel in Channels and Interfaces to facilitate chat bot capabilities when customers reach out to a company through various social media platforms like Facebook, Twitter, WhatsApp etc.
Refer to Creating a Unified Messaging channel | Pega for details on how to set up a Digital Messaging Channel. The channel can be configured to initiate a case based on the intent identified from the customer’s incoming messaging. Pega does this by running the customer’s message through a text analyzer rule, which uses NLP to detect the intent. The case type rule can be specialized for BotAgent channel so that relevant messages/questions can be pushed back to the customer via the social media channel they initiated the conversation from.
Accessing the same case via multiple channels
Once a case is initiated, out of the box, Pega supports the case to get completed via the same channel and even supports escalation to a human when this feature is used in conjunction with Customer Service application. But there can be cases when a customer starts a conversation from one channel and abandons it midway. As an example, let us consider that the Customer wants to update his address. They can initiate this request via twitter. The channel rule detects the intent and starts the Address Change case. Based on the question shapes configured in the conversational flow, the bot will respond by asking questions related to the new address, the date from which the new address needs to be effective etc. Refer to this link to understand how to configure a conversational flow : Conversational flow. It might so happen that the customer leaves the flow midway and then wants to resume the same conversation from another channel (for example facebook) at a later point of time. This capability is not provided out of the box. When the customer initiates a conversation from the second channel and an intent is identified, it is always treated as a new case and a new Address Change case is initiated. The bot will proceed with asking the same questions like new address, effective date etc, which means that the customer has to repeat his answers that he already provided through the first channel. This article provides a design pattern to address this use case seamlessly, wherein the customer need not enter the same details again and gets an experience as though they are resuming the conversation that they abandoned in the first channel.
Refer to this link for the capabilities supported out of the box Supported chat and messaging features by channel | Pega
Also note that Pega 8.6 has introduced a new feature called Channel hopper which allows the customer to transfer their chat from the web to any of the digital messaging channels like FB, Twitter etc. For this capability, the customer has to initiate the transfer from the web messaging widget. They then have a limited amount of time to complete the transfer from the other channel. Please refer to pega community for more details on this feature.
Listed below is one possible approach to achieving a seamless experience across channels
1) As the first step of the conversational flow, introduce an activity/automation that uses a data page to fetch any Address Change (In this example) case that has been instantiated by the same customer in the past, which has an open status and has pxActiveChannel property equal to “BotAgent”. If required there can be a condition to choose only cases that have been instantiated in the past one week or a timeline as suited to the business requirements.
2) If there are no results obtained from the data page, it means that the current case is the first attempt from the customer. In this case, nothing else needs to be done and the case can proceed as normal. But if the data page has a result, it means that the customer attempted an Address Change case previously. In this case, open the old Address Change case, using the ID retrieved from the data page.
3) Copy over the properties that hold the answers to the question shapes from the old case to the new case.
4) Resolve the old case, using pxChangeStage API with status as Duplicate, so that it will not show up in searches in the future.
5) Each question in the conversational flow gets displayed only when the property associated with the question is not empty. In this case, when property values are copied from old case to new, the question will not be displayed as the property value is not empty. If there were 10 questions in the case and customer had answered 5 questions as part of the first case, then the answers to these 5 questions will be prefilled in the new case by the activity. So the first 5 questions will be skipped as the part of the new case, as property values are not empty. The customer gets to see the 6th question directly that gives them the user experience of having resumed the initial case and not starting a new case from scratch.
6) If a data page result is obtained due to an old case, the case can also be routed to a question shape to display a message that indicates to the user that the system already has some information that he provided earlier. At this point, the customer can be provided an option to choose whether they want to keep that old data or re-enter them.
7) If they choose to re-enter, then the answer properties can be cleared using a data transform and the case can be directed to the first question itself. If they want to retain the answers, the properties will not be cleared, so it will skip the initial questions which have answers prefilled and resume the case from the question where there is no prefilled answer.