HowTo : Create a chatbot with human fallback

Sometimes it's necessary to have a chatbot for answering the users' most common questions, and solving the issues that more regularly appear (which may be a great percentage of the doubts and may cover almost all of them). However, for particular queries (not so "general" or "common"), a human being should intervene in the conversation to try to give a more accurate answer to the user.

This document explains how to go from a chatbot to a human agent and provides a brief overview about it.

About the example

It's a very simple example, whose only purpose is to show you how to make the user talk with a human when the chatbot fails to "understand" the user and give them an answer. Then, when the human agent considers, they can make the chatbot to start answering again.

Basically, the solution consists of using the context (which can be global, or valid only for each user).

The global context is used to determine if a human is available (during work hours) and it's feasible for a human to respond. The user context is used to turn on/off the human support for each particular conversation.

You can use the Chatbot context API for this solution.

So, now take a look at the most relevant objects of the Knowledge Base.

GlobalHumanSupport Web Panel

This Panel sets the global context value for determining if human support will be allowed. That is, during the hours that a person can assist, you should set this context value to True.

MyAgent Conversational Flows

The Conversational Flows object of the KB is called "MyAgent." It's a chatbot that only has four Flows.

The Input Not Understood Redirection property is set to the "HumanSupport" Flow. So, when the user enters something that the chatbot cannot "understand" (that is, none of the Chatbot Intents are identified by the NLP provider), a redirection to the "HumanSupport" Flow is done.

Take a look at the HumanSupport Flow. It doesn't have any User Inputs and the Conversational Object property is set to a Procedure called "EnableHumanSupport."

The "EnableHumanSupport" code is as follows:

parm(out:&EnableHumanSupport);

Context.GetContextValue(!"MyAgent", !"GlobalHumanSupport", &Messages, &Value)
&EnableHumanSupport.FromString(&Value)

It reads the global context value "GlobalHumanSupport" and returns its value in a variable (&EnableHumanSupport). As this variable is returned by the conversational object Procedure, it's automatically set as a user context variable. As a consequence, this information is set in the user context.

CustomMyAgentChatbotWebUI Web Panel

Calls the CustomPanelChatWeb Panel that has some modifications over the PanelChatWeb (which is a Chatbot resource).
Look at the SendMessage and NotifyOtherClients subroutine:

Sub 'SendMessage' //Send Message
    &WebClient = &WebNotification.ClientId
    &NotificationInfo = new()
    &PreviousContext = GetChatMeta(&UserId, &Instance)
    NewMessage(&UserId, ChatbotMessageTypes.User, &Send, "", &PreviousContext, "", &WebClient, &Instance)
    GridSent.Refresh()
    SendMessageHSupport.Submit("", &Instance, ChatbotPlatform.Web, &Send, "", &PreviousContext, &WebClient)
    Do 'NotifyOtherClients'
    &Send.SetEmpty()
endsub

Sub 'NotifyOtherClients' //Notify Clients
    NotifyClientsHSupport(&UserId, &WebClient, ChatbotNotificationTypes.ChatbotMessage, !"", false)
EndSub

The SendMessage and NotifyClients Procedures that belong to the CommonChatbots module (Chatbot generator), were saved with other names and modified: SendMessageHSupport and NotifyClientsHSupport.

In SendMessageHSupport, the modification is to send the message to the NLP provider only if the "EnableHumanSupport" user context variable isn't TRUE.

&ParameterValue = Chatbot.Context.GetUserContextValue(&Instance, &UserId, "EnableHumanSupport", &Messages)
if &ParameterValue <> "True" 
// send the message to the provider
endif

In NotifyClientsHSupport, the message to be sent through the socket includes the UserId.

&chatMessage.Message = &NotificationMessage
&chatMessage.UserId  = &UserId.ToString()

&NotificationInfo.Id = &ChatbotNotificationType
&NotificationInfo.Message = &chatMessage.ToJson()

for each CommonChatbots.GXChatUser
    where GXChatUserId = &UserId
    where not (&IsFromClient AND GXChatUserDevice = &SourceClient)
        &Socket.NotifyClient(GXChatUserDevice, &NotificationInfo)        
endfor

This is because the chat Panel of the support assistant will need to identify the User alongwith the message.

This notification will be received by the support assistant in their chat Panel. The support assistant's chat panel is the SupportForMyAgent panel.

SupportForMyAgent Panel

It calls the SupportPanelChat Panel. This Panel receives the notifications of the messages sent by the user when the &EnableHumanSupport user context value is True.

The 'SendMessage' subroutine has some changes over the same routine of the PanelChatWeb (Chatbot resource). It builds up the message and sends the notification to the user.

Sub 'SendMessage' //Send Message
    &WebClient = &WebNotification.ClientId
    &NotificationInfo = new()
    &PreviousContext = GetChatMeta(&UserId, &Instance)    
    NewMessage(&UserId, ChatbotMessageTypes.Response, &Send, "", &PreviousContext, "", &WebClient, &Instance)
    GridSent.Refresh()    
    Do 'NotifyOtherClients'
    &Send.SetEmpty()
endsub

All the messages (the user and the support assistant messages) are saved in the GXChatMessage table.

The support assistant can end the conversation by clicking on the EndSupport button. There, the &EnableHumanSupport user context value is set to False.

Managing the users in a console

Surely, the support assistant will have more than one client to assist, so the GlobalHumanSupport has a grid to see the users who require human assistance and select one (open the chat Panel to answer to this client).

This grid refreshes automatically when a new user asks for assistance, using a socket notification, which is sent from the EnableHumanSupport Procedure (the conversational object of the HumanSupport Flow).

This solution can be changed to better meet the needs of each scenario; for instance, save the name of the support assistance in each conversation to be able to follow up the issues.

Remember that all the Chatbot generator objects (the resources) can be modified as necessary, including the GXchatMessage table, and the NewMessage Procedure (that saves the messages in the table).

Requirements

The minimum required version for running this Knowledge Base is GeneXus 16 upgrade 10.

How to set up the example

Some steps also need to be followed to get the sample ready to run.

1. Do a checkout of the KB.

2. Check that your Chatbot module is up to date. Go through the menu Knowledge Manager > Manage Module References, and check that it's installed (updated).
How to install the module manually: After executing GeneXus, go through Knowledge Manager > Manage Module References > Right-click on the server section > Upload from file > Select the ChatbotGenerator opc > Install.

3. Configure the chatbot provider's credentials. See Configuring GeneXus for using the Chatbot Generator

4. Webhook
It's generated under the instance's module, and its name is CustomWhatsappWebhook.

Configure inbound message webhooks in Twilio
http://<server>/<baseURL>/<InstanceModule>.CustomWhatsappWebhook.aspx (.NET) or http://<server>/<baseURL>/<InstanceModule>.CustomWhatsappWebhook (Java)

Add provider's credentials into the SendWppMessage Procedure.

5. Do a Rebuild All.