Using Chatbots to Improve User Engagement—Part Two

Chatbots and AI are rapidly developing and powering a new wave of customer engagement. It's not too late to pull ahead of the crowd, and Progress can help.

In my last post, we covered some of the background behind the rise of chatbots, their capabilities and the methodology for putting one to work for you. Today, we'll dive a little deeper and delve into the actual development of a bot.

Let's start with some examples. As a part of our exercise with the Microsoft Bot Framework, here are couple of bots we built:

The Warehouse Bot

 

The first is a warehouse bot. It is capable of answering questions related to warehouses and stocks.

For example, you can ask for a sales report or the status of a stock in the warehouse and then configure it to notify you about depleting stock items if required.

 

The bot here demonstrates its capabilities to serve rich media content like Kendo UI charts and graphs, images, HTML and more. The bot can be integrated into various channels like Skype, Outlook, SMS and many others.

Note that although rich media content is allowed, some channels might not support it—for example, SMS can’t serve the images.

 

Notification Bot 

Another is the proactive notification bot. It notifies the relevant users about a new order being placed, and acts upon it based on the response from the required user. What you see here is an SMS conversation initiated by the bot.

Again, the channel of communication can be SMS, Skype, Slack, Outlook or another channel. This is to demonstrate that it is not always necessary for the conversation to be started by a user. Sometimes when the bot feels its necessary, it can start its own conversation.

Bots give you the power to establish meaningful, natural language communication among your applications, and the beauty of it all lies in the simplicity of the system. The system can be understood through just a few components.

Components Needed to Create Your Bot

• The bot registry: This is a publicly available registry where people can install your bot for you. In the case of a Skype bot, it is the Skype bot registry. When you log in to Skype and search the bot by name, you will find it right there and can easily add it to your contacts.
• The client: In the case of an SMS bot, the client is the SMS application on your phone. If you're using a Skype bot, the Skype application on your system is the client. The client varies depending on the channel of communication.
• Microsoft Bot Framework: This is the infrastructure laid by Microsoft to facilitate building bots. It provides easy integration, various messaging channels, conversational infrastructure and assimilation with the natural language engine.
• LUIS: The “language understanding intelligent services,” currently supports five major languages. You can create an application in LUIS and host it on a public cloud. In our case, it is hosted on Microsoft Azure. Hosting is paid for per usage. It is easy to use LUIS for language understanding because it identifies and breaks down sentences into intents and entities. Intents translate to the purpose of the sentence, while entities can be considered the subject of the intent. For example, a time, date, place or name could be considered entities. You can also define custom entities.
  
  This application does need training, and it requires definitions of the intents and entities for given sample utterances. For example, you can have intents for Greeting, Farewell, ProcessOrder, and many more. The more you train, the better LUIS understands. Here is a sample training screenshot:

• The bot brain: This is one of the only pieces where a lot of code needs to be written. You need to write intent handlers, meaning you must define the action with that intent once LUIS decodes the intent of a given utterance. The action can just be a prompt or a call to a database or invocation of a web service. You can write the bot in Node.js or C# if you're using the Microsoft Bot Framework. In this example, we've written it in Node.js and have hosted it on Modulus. Here is the sample code:
  var dialog = new builder.LuisDialog('https://api.projectoxford.ai/luis/v1/application?id=769f6dc0');

  var bot = new builder.BotConnectorBot({appId: 'notfbot', appSecret: ‘XXXXX’ });

  bot.add('/', dialog);

  // Handling the Greeting intent.

  dialog.on('Greeting', function (session, args) {

        console.log ('in greeting ');

        session.send('Hello there! I am the notification bot. I can notify about the urgent orders');         

  });

  // Handling unrecognized conversations.

  dialog.on('None', function (session, args) {

        console.log ('in none intent');   

        session.send("I am sorry! I am a bot, perhaps not programmed to understand this command");            

  });

  dialog.on('Notify', function (session, args) {

        console.log ('in notify ');

        session.send('we just got an urgent order. Want to review it?');          

  });

   

• System of records: This is where you have your data and information, possibly in the form of a web service or database. In our case, it is an OpenEdge application hosted on the Arcade cloud.

 

Architecture of the Progress OpenEdge Chatbot

Let's put these bot components together.

Below is an architectural representation of all the components and their interactions. The arrows show how data flows from the software client at the user end to the bot, and vice-versa. The purple box is the user client, like a phone, Outlook or Skype. The blue box is the Azure cloud, which hosts the natural language engine LUIS and bot framework. The green box contains the Progress specific pieces (the OpenEdge application). This exposes the REST endpoint and serves as the data store and actual bot application, which contain the business logic/intent handlers.

If a user types an English sentence on Skype addressing our bot, the message is sent to the bot framework which knows the public URL of our bot deployed on Modulus. The bot knows the URL for LUIS and asks it to resolve the message. LUIS returns a structured JSON where it breaks down the message into intents and entities, and ranks the intents with scores as shown below:

 

 

Once the bot knows about the intent and entities of the message, an action can be performed. The action can be as complex as establishing a nested conversation with multiple rounds of question and answers, or as trivial as invoking a REST endpoint and serving processed results.

The bot framework portal pictured above shows the messaging endpoint is the public URL of the bot hosted on Modulus. Enabling a bot is as easy as clicking on the ‘Add’ link in the ‘Add another channel’ section.

The bot is running on the channels marked with a ‘Running’ status. Each channel has a specific set of instructions for enabling a bot on the channel. Once you add a bot, you will get a bot URL which can be directly sent to user, who can then add the bot to their local clients (Skype, Slack etc.). In the case of an SMS bot, you'd get a phone number . With Slack or Skype, it would appear in the bot registry as well.

Thoughts on the Development Experience

The framework, as well as many other aspects of the development, are in beta mode, so you can expect some changes to arise. However, you can participate in their roadmap and request some really interesting features for free.

Initially, I hit a few bumps (as I am sure everyone will), but the community was really active and helpful. I would suggest paying extra attention to the LUIS training. Defining clear intents is key, and getting enough sample utterances is equally important (around 20-30 per Intent is a fairly good number).

If possible, I would recommend getting subject matter experts to write sample utterances for you. There are infinite variations of a question, and there can be many responses to the same question, so templating the responses is a good idea.

It is also important to define thresholds for intent resolution. For example, LUIS resolves the utterances and assigns a score for each intent. The intent with the highest score is chosen. However, it is possible that the highest score is too small to be considered for an action. In such cases, you can define minimum thresholds and let the intents resolve to ‘None’ if it doesn’t suit you.

One of the powerful features of LUIS is active learning: it can critique its own work and ask you to relabel things if they don’t seem right to you.

Where Should I Look for Help?

The documentation for Microsoft Bot Framework is illustrative and nearly complete. If you want to look at the code samples we created to prove the idea, you can find them on Github. You can also find all relevant links on the GitHub ReadMe page.

If you want to start interacting with the bot, try adding the notification bot to your Skype using this link.

Alternatively, you can also e-mail me directly and I'd be happy to help.

Chatbots Beyond OpenEdge

This exercise was mostly focused on the easy integration of OpenEdge applications to the bot framework. However, I believe that the flexibility of the bot framework opens up a whole new avenue to integrate them with any of our products. I can imagine a bot welcoming a user who starts up Progress Rollbase, or assisting someone using Progress Corticon to build a conditional form like our bot lawyer example.

It's an exciting technology and we're always thinking of how we can improve our products to help you be more productive. What do you think of chatbots and where would you like to see them? Let us know in the comments.