In my last post about sending a welcome message to a Bot with LivePerson using a Direct Line Channel, I showed you how to solve the case of the missing welcome message.

In this follow up post, I'll talk about the constraints that LivePerson's 3rd party bot integration placed on our bot's ability to use Adaptive Dialogs like ConfirmInput() (otherwise known as "QuickReplies") and hero cards based on the "Chat" Conversation Type that was used for the integration.

I'll then dive into the changes we had to make in order to send the welcome message from the bot to the user when switching from Chat to Messaging Conversation Type.

Chat Conversation Type Constraints

After successfully getting the welcome message working for our bot using the Chat Conversation Type, we immediately started seeing failures in our bot while running through LivePerson. We quickly identified the failure point when the bot returned the first ConfirmInput() dialog type. A ConfirmInput() returns a "QuickReply" dialog which usually consists of two or more buttons that the user can click. Very common uses are for Yes/No responses, of which our bot made extensive use.

Upon further investigation, I discovered that 3rd party bot integrations using the Chat Conversation Type did not support QuickReplies, only bots integrated with the Messaging Conversation Type did.

Given that constraint, we initially went down the path of replacing all QuickReplies with regular text responses, but that introduced problems around reliably being able to interpret the answer to a Yes/No question. With QuickReplies, we get two choices, a Yes or a No button. With a plain text response, we'd have to handle all sorts of variations:

• Yes
• yes
• Yeah
• uh-huh
• etc.

It was introducing more work for us and adding non-determinism to answering a simple yes/no question. It also introduced a degraded user experience none of us were happy with. If we didn't want to lose the richer experience of working with QuickReplies, we had to re-integrate the bot to run as a Messaging Conversation Type.

Returning to our bot configuration in LivePerson, we changed the Conversation Type from Chat to Messaging.

We started the bot, tested the connection, and everything appeared to be set for the bot to run.

Where's my Welcome Message Part 2

After changing the Conversation Type to Messaging, the bot was back to its original behavior of not greeting the user. The first thing a user typed into the chat window was interpreted by the bot as the answer to the first question they never saw. Turns out that while running in Messaging mode, that LivePerson never sends the WELCOME event wrapped in the channelData payload like they do when running in Chat mode.

{
  "type": "message",
  "text": "",
  "channelData": {
    "action": {
      "name": "WELCOME"
    }
  }
}

When running in Chat mode, I updated our code to handle that incoming event in order to send the welcome message from the bot to the user, but that no longer worked. I had to find a way to get the welcome message sent while running in Messaging mode.

Welcome Message

It turns out, when running in Messaging mode, LivePerson offers a welcome Message configuration point while integrating the bot. You simply need to check the Welcome Message option. There is a default welcome message that is used, but it's possible to customize the welcome message as well.

It's a good thing that we could customize the welcome message, as you'll see in the next section, First Question.

First Question

We were receiving a welcome message, but we still were not receiving the first question. It took a call to LivePerson support to get an answer. In Messaging mode, LivePerson relies on the user to make the first move (aka, type) in order to get the bot working. There was no way to "trigger" the bot to send that first meessage, it was not something LivePerson supported in Messaging mode.

Remembering that we could customize the welcome message, we ended up putting our greeting AND our first question into the welcome message.

The resulting changes looked like this:

Now the first thing the user typed was a response to the first question that we put into the welcome message. The bot was working again and this time, fully supporting QuickReply dialogs.

LivePerson Conversation Type Summary

This is list of constrains and trade-off's we discovered when deciding which Conversation Type to use when hosting the bot with LivePerson.

Chat

• you write the code the sends a welcome message by handling the WELCOME event sent by LivePerson.
• does not support QuickReply dialog types
• begins every chat window with no history

Messaging

• use LivePerson bot configuration to send the welcome message
• supports QuickReply type dialogs
• the chat window contains the history of all previous chats

In Closing

In the end, we had to cut a couple corners to get our bot running in LivePerson because of their integration constraints. Also, the bot does behave differently when running in the emulator or Azure Web Chat than when run in the LivePerson hosted chat window.

But given the user experience was more or less intact, and the conversation flow was started the way we wanted it to start, changing from Chat to Messaging was exactly what we needed to do.

Happy Bot'ing!