Chatbots need to have features that enable human-like conversations. The goal is to make a chatbot conversation more human and thus better than the menu-driven approach of modern apps. In the previous chapters, we discussed types of chatbots and the regulatory constraints to consider for an in-house-developed chatbot. In this chapter, we will discuss the simplified approach to building the integral components of chatbots. Later sections will introduce conversation flow for a sample request to facilitate the context build-up in a chatbot conversation. The chapter will end with the introduction to the “24x7 Insurance Agent” chatbot, which will be the use case discussed throughout the rest of the book.
Customer Service-Centric Chatbots
Business context
Policy compliance
Security, authentication, and authorization
The accuracy of a system in resolving input queries is another consideration for the NLP module.
Business Context
Business context refers to the peculiarities of the business the chatbot is developed for. In general conversations, we can infer meanings to unsaid things or implicit things in a conversation.
The concept of live chat is still relevant in many large companies. The core purpose of live chat was to reduce call center costs and provide another layer of conversation, but it also created another conversation silo and, in many cases, lousy customer experience crept in.
In live chats, the business context was maintained by the chat executive and the customer needed to spell out the context every time. The modern chatbot system needs to identify and sustain settings to construct a minimal conversation flow. Usually, the conversations done through chatbots depend on what is explicitly passed to a chatbot for processing (conversation history), what channel is used to converse (channel), and the medium of the message (text, image, voice, emoji, etc.). The unsaid thing is the context, which needs to be maintained by a successful chatbot.
Conversation context: User chatting about the food order (2345) he canceled last night.
Case 1: No Context Maintained | Case 2: Context of Chat Maintained |
User: Why refund not processed for my food order? Chatbot: Please provide your OrderID User: 2345 Chatbot: Your refund is processed and will be updated in your account in 2 days. | User: Why refund not processed for my food order? Chatbot: Your refund is processed and will be updated in your account in 2 days. |
In Case 1, the context is not maintained, so every conversation needs all the information to be supplied to the chatbot. In Case 2, the chatbot keeps the context of the conversation from where it started and also tries to identify the query to the same meaning.
Building on this generic example, the chatbot needs to be trained in specific business language, terminologies and operating dialect. If you are developing a chatbot for a bank, you need to understand that “time deposit account,” “checking account,” and “roll over” refer to specific features at a bank. This is very important, since your user won’t want to explain what they are talking about to the chatbot time and again.
The business context is built at the Natural Language Processing (NLP) layer, and the conversation framework manages functionality. This specific training for global business context and language requires looking into past conversations with customers.
Note
Every conversation may have a global context and a dialogue-specific context. For example, talking about life insurance is the global context, and within that, talking about a particular policy is the conversation context.
Policy Compliance
Every conversation can lead to many types of requests to be fulfilled by the chatbot. The crucial questions then becomes, to fulfill a user request, what is the compliant way to dispose of that information? The policies and government regulations decide what is allowed and what is not allowed, and if allowed, how to access that information.
User: Update my home address to XYZ, sector-8, India
Chatbot: Address updated to XYZ, sector-8, India
But there are new questions. Is customer allowed to change his address by just providing this command? How would this happen at an actual bank branch? What are the processes and policies that govern an address change?
A policy and regulation guide is essential to drive the conversation through the chatbot. The business process, as well as statutory compliance, needs to be followed across channels for any request to be persisted in the system. For example, updating the address should not be performed even if the request has been confirmed. It may require asking for address proof, reason, waiting three days, or some other process before updating the address.
The chatbots created for customer service need to be carefully taught the must-follow rules or steps to fulfill a request. These rules can differ based on the business and purpose of the chatbot. These steps need to be implemented as strict “AND” conditions in chatbot logic.
Security, Authentication, and Authorization
Chatbots can be allowed to access private information or remain on another channel to distribute public information conversationally. Authenticating and authorization are two essential layers for securing a conversation. A secure communication channel is vital to make sure the data exchanged between the user and the chatbot is encrypted and transferred over a very secure medium.
Security policies can be enforced by having conversations over the HTTPS protocol, having a firewall, and other industry best practices. The security layer must be taken care of by the network technology and technical architecture to secure all the conversations. The security features can be inherited from the existing framework of the business and need not be designed separately, in most cases.
Reference accountability framework
The chatbot needs to authenticate its users to ascertain if they are allowed to access chatbot features, and if allowed, which features are allowed for which user. This becomes more important when your chatbot connects to the backend system for accessing information like HRM, CRM, and other methods. In many cases, an Identity Management System (IMS) like Active Directory can be used to create authentication and access the control mechanism for the chatbot as well. A typical authentication can be a multi-factor login system or an access PIN for authorized users.
Authorization is another essential layer in the accountability framework and it allows the enterprise to control access to the resources. This also controls the access control layer where the systems check what areas or functionality the authenticated user is allowed to access. This is very important because multiple users will want to use the same source of information in multiple independent conversations, and we want to protect the data and deliver only what the user is authorized to access as per their role and policies.
Authentication and authorization service
Accuracy of User Input Translation to Systems
Input | Chatbot Logic Generated Query | System Output |
|---|---|---|
User: Tell me the status of my salary for April 2019 | Select status from payroll_table where empID=UserID and month=“ April” and year=“2019” | Your salary status is “<RESPONSE FROM QUERY>” |
User: When I will get my last month’s salary? | Select status from payroll_table where empID=UserID and month= ?? and year= ?? | Your salary status is “<RESPONSE FROM QUERY>” |
In this example, Input 1 and Input 2 need to get the same result from the system. The chatbot logic needs to resolve for the two inputs before it can fetch the correct information for the user. Here are the challenges and requirements of making sure the query gets accurate data for the system to respond. If the chatbot logic is unable to create the right question, the results will not be correct and may even cause unauthorized information to be shared with users unintentionally.
Chatbot Development Approaches
The chatbot development approach refers to how to build the chatbot logic. The critical consideration in selecting the approach is the balance between natural language abilities and accuracy of results. As you know, NLP comes with a challenge of understanding the natural conversations and translating them to machine actions; a balance must be maintained.
Chatbot classification based on conversation types and response types
The focus of this book and our discussion is on closed domain conversations, where we can have either a rule-based approach or create smart machines using an AI-based approach. In this section, we describe the two popular types of development approaches.
Rules-Based Approach
The rules-based approach, also called the menu-driven approach, works as an extension of self-help portals with a better experience. The critical difference is with the navigation to solutions. In a self-help portal, you need to navigate to the right options manually, while in menu-based chatbots, the navigation can be done using natural language and then actions are performed using menus. See Figure 3-4.
Menu-driven chatbot interface
As shown in Figure 3-4, a chatbot attempts to understand the user question and then presents a menu to choose the next action. The list makes sure the backend knows what exact operation needs to be done to fulfill the request.
Advantages of the Menu-Based Approach
The accuracy of the response is confirmed by the design.
It’s based on heuristics rather than complicated NLP, and is easy to understand and implement.
It’s easy to extend to new menu items without retraining the core.
Disadvantages of the Menu-Based Approach
The functionality is strictly limited to the templates’ code.
The fulfillment is of two steps: understand the context and bring the menu up. After the menu click, fulfill the request.
It offers limited natural language conversations since the chatbot do not understand beyond the coded situations.
Even with these limitations, the menu-driven approach is very successful when accuracy is more important than the experience of a natural conversation.
AI-Based Approach
The AI-based approach is based on an advanced NLP engine to support natural language and fulfill the request based on ML algorithms and system integration for dynamic information retrieval. The accuracy of the chatbot is lower at the start and increases over time.
The critical difference between the menu-based and AI-based approach is the NLP engine. An NLP engine is responsible for extracting the information present in the user input. Moreover, based on the extracted information, the chatbot needs to decide the next steps.
The NLP engine extracts exact information based on ML techniques
Advantages of the AI-Based Approach
Advanced conversations can happen without the user going into multiple steps for actions.
The NLP engine can deal with unseen scenarios and numerous texts.
The chatbot can learn to create custom responses from scratch (natural language generation).
Disadvantages of the AI-Based Approach
The NLP engine is complex to train, maintain, and improve.
The accuracy of responses suffers since the NLP output is not 100% correct.
It requires a vast amount of data for a working chatbot NLP engine.
Conversational Flow
Chatbots for closed-domain applications are built with a defined purpose and functionalities that the chatbot will provide as features to the user. To be able to cover the possible cases of conversation or the user inputs, we must define the scope and all of the flows possible. The flow definitions are essential since we must follow policies to be able to provide access to the required data.
Sample conversation flow
The flow starts with a welcome message and either provides a menu (if it’s a rule-based chatbot) or the user asks a sentence (entirely AI-driven chatbot). Once the chatbot NLP logic identifies which functionality the user requires, there is a decision point to take the user to that conversation path. If the user wants to check the status of an order, his next conversational decision point is to enter the order number. Once the chatbot receives a valid order id, the backend calls for action to retrieve information for that order and take it back to the user. This flow maintains the context as well, so if he needs to track another order, he need not start from the root but can just enter another order id and the chatbot will know to track the order status.
In more advanced chatbots, you can pass multi-intents in one line, but technically the chatbot will process the request in the same flow. So “Track my order number 465” is a single input from the user, which should fetch the same result. The multi-intent chatbots are difficult to build, and chances of error are high.
Creating a chatbot flow is essential since this defines the scope of features and improves the accuracy of the chatbot for the user. It is imperative to make it clear to the user what the chatbot is meant to do for them and maybe define the features beforehand. The exception cases can always be transferred to default responses or a human executive.
Key Terms in Chatbots
The development of chatbots has become a full-bodied development process, which means it is essential for you to understand the terminology of chatbots before you attempt to develop one. The key terms used in chatbot development also have multiple variants as professed by leading chatbot platform providers like Amazon, Google, etc.
In this section, we will discuss some key terms frequently used in chatbot development. In further chapters, we will use these concepts and terminologies to show how to develop the chatbot from scratch.
Utterance
Utterance refers to anything that user inputs to the chatbot. The full end-to-end input makes an utterance, such as “Get me status of my order id 345,” “What is the temperature today?,” “Hello,” “Good Morning,” etc.
Utterances are used to develop a classifier for intents in development. The chatbot stores as many possible utterances in the database, which are the questions asked by the user, and clusters them in different intents, which represent what the user wanted to say.
For developing a chatbot for insurance, we will need to capture actual questions asked by users from different channels, such as chats, emails, office visits, customer value center, etc. We will use all this historical data to train the chatbot to know the actual requirement of the user and which conversational flow to use.
Intent
The intent is the intention of the user identified from the utterance captured by the chatbot. Identifying intent is the essential function of a chatbot. In menu-driven chatbots, the menus help the user to pinpoint the intent, while in AI-based chatbots, identifying intent is a task done by the NLP engine.
The successful matching of intent decides the flow of conversation and delivers the correct response to the user. In domain-specific chatbots, the intents could be different from general intents, and hence domain-specific training is required.
For example, for the utterance of “Show me the stock price of Apple,” the intent is to find the stock price. Let’s call this intent as showStockPrice. showStockPrice is the main intent of the user, while the term “Apple” is the entity, also called a slot.
Entity
Entity gives meaning to the intent by providing additional value to the utterance. An entity can be defined as subordinate to the intent, which tells us the intent is related to which subclass. In this example, “Apple” is the entity of @company_name for the intent #showStockPrice.
Entities, or slots, when maintained in sessions, help retain the context of the conversation. In this example, after this first utterance we replied with the price. Just after that, the next utterance could be “and for Microsoft.” In this case, the chatbot has already captured the intent as showStockPrice, so the slot changes to Microsoft and the chatbot can fetch a stock price of Microsoft.
Channel
The channel is the medium used by the chatbot to connect with the user and fulfill their request. Nowadays, all social media messengers allow chatbots for conversations (e.g., Facebook Messenger, Slack, Skype, etc.).
However, for an application like our 24x7 Insurance Agent, we want to have our developed channel remain compliant with privacy laws and provide an added layer of security when we access the private information of users.
Human Takeover
The human takeover is a term used to denote human fallback during a conversation. Modern chatbots come with the feature of fallback to human assistance when the chatbot fails to understand intents and extract entities, or the confidence is NLP output is low.
A human takeover by choice: At any moment the user can choose to talk to a human, maybe because they are more comfortable with humans or the chatbot isn’t solving their issues.
A human takeover by confidence: A confidence filter may decide if we can fulfill the request with high confidence; if not, the request is automatically transferred to a human without a choice for the user. This provides a seamless experience for the user.
Use Case: 24x7 Insurance Agent
The chatbot that will be discussed throughout the book is based on the use case of an insurance agent. AI-driven chatbots will be discussed using the multiple aspects of security, natural language ML techniques, deployment, and business purposes. Each chapter will discuss some component of developing this chatbot.
Business context: The 24x7 Insurance Agent will be able to have necessary conversations in the insurance domain. People may ask about their policies, premiums, etc.
Policy compliance: The policies can be taken from the standard procedure followed at the customer care center.
Security, authentication, and authorization: We can create a PIN-based authorization, while an IDS-based authentication can also be used if the users already have a product.
Accuracy of user input translation to systems: To ensure this, we can create a confidence filter-based human takeover mechanism.
The AI-based approach or menu-based approach: Both should be fine as per need and balance between flexibility and accuracy.
Conversational flows: The flows must be created by sitting with the business and exploring its policies.
The NLP training will require data of old conversations, intent list, most frequent entities, etc.
These decisions will help the developer to select the right structure and architecture for the chatbot solution.
Summary
Chatbots offer opportunities and challenges. The opportunities outweigh the challenges faced while developing one. In this chapter, we discussed important considerations as you embark on the journey of developing a chatbot, including defining business context, understanding policies to access data, adopting best practices for security of conversations and systems, and ensuring the accuracy of responses. Then we introduced the types of development approaches and their advantages and disadvantages: menu-based and AI-based. The concept of designing conversational flows was covered, which helps create scope and deterministic structure to respond to users. Critical terms used frequently in chatbot development were explained: utterances, intent, entity, channel, and human takeover. In the end, we outlined how to structure the solution for the 24x7 Insurance Agent. The next chapter will introduce the solution architecture and how enterprises can build a successful chatbot in-house.