You must have come across various terms used to define virtual assistants. They are thrown around interchangeably without much thought. The most common ones that I’ve heard are–chatbots, intelligent assistants, conversational AI, and interactive agents.

At first, I thought they are just different names for the same thing. But after I started working on building healthcare chatbots, I began to realize they are different in many ways. To give you an example– A chatbot is the poor relative of the intelligent assistant. They differ from each other on the basis of their capabilities. While one might be able to answer simple questions, others can understand, interpret, and answer complex ones.

It all depends on the intent and purpose of building a chatbot. If the intent is to reduce customer-service costs by introducing bots, then rule-based chatbots are the best. However, if the intent is to provide an interactive platform for end-users, then building conversational AI chatbots is the solution.

I already talked about the 3 different types of chatbots in my previous post. I also talked in detail about the most common use cases in each category (for healthcare products) and the open-source platforms that one can use for development.

In this article, I am going to talk in detail about how to build rule-based chatbots.

But first..

Why are rule-based chatbots still popular?

If conversational AI chatbots offer better engagement and rule-based offer less flexible conversational flow, then why should one invest time and effort in rule-based chatbots? I had the same question in mind.

My research pointed out that they have certain advantages which are hard to overlook. Rule-based chatbots-

• are less expensive to build, and
• need less time to train.

Therefore, if budget and time are a factor in your development strategy, you should consider building rule-based chatbots. But it’s not that easy. Don’t let these two factors alone influence your decision. Let me take you through a step-by-step approach to building rule-based chatbots so that you are better prepared for what lies ahead.

Phase 1: Discovery

The discovery phase is a crucial step that can make or break the experience of the chatbot. When done right, project discovery helps in mapping out the right features for your targeted users. I’ll share my experience of investing time in this phase and how to approach it.

Determine your target audience

It’s a no-brainer. Nonetheless let me say it out aloud. Figuring out your target audience is an important step. Begin by answering this question- are you building the chatbot for patient/provider/payer? What kind of audience needs your solution? Would they be interested in paying for your solution? Do they really need your services or are they happy with their present state?

Figure out the use cases for your chatbot

After determining your target audience, decide on the use case(s) you want to build in your chatbot. There can be different use cases for different personas. I’ve listed a few of them below-

• Patient: Registration, FAQs, appointment booking, finding a provider, insurance verification, creating and maintaining personal health records.
• Provider: Patient scheduling (appointment booking, cancelation, rescheduling, reminders) , Patient registration (patient intake forms, insurance verification), patient screening (based on disease/symptoms, pre-conditions, family health history), patient engagement (FAQs, handover to the right caregiver, well-being messaging), creating and maintaining patient Electronic Medical Record, marketing.
• Payer: Finding a provider (based on location, health condition, cost-sharing (deductible, co-pay)), retrieving information on claim status (approval, rejection, pending), registration, patient verification, FAQs, retrieving subscriber information for verification and treatment (approval or rejection).

Decide the channel of delivery

The delivery medium of the chatbot is an important factor to consider and it will influence a lot of your technical decisions. Therefore, it’s best to decide the medium through which your chatbot will interact with end-users. The most popular mediums are- text messages, email, application (web or mobile), social media (Facebook, Slack, Whatsapp, etc.).

You can have either one or all of them. Ideally, the channel of delivery should be decided on the basis of user research– where are your users most likely to interact with you? What is their preferred mode of conversation? Does it vary with age and gender?

For instance, if you’re building a chatbot that helps young teens in overcoming mental health issues then you must decide the best place to get their attention. Since Facebook is popular among teens, would it be better to deploy the chatbot on Facebook? If you’re deploying the chatbot on your website, how will the users reach your website? Answer these questions in this phase before moving on to the next phase.

User demographics: Age Group 

Figuring out the user demographics helps in defining the personality of chatbot. If your user demographics is younger, it will impact your chatbot’s conversational tone and language. Similarly, if your demographics are farmers in remote areas, it will impact how your chatbot will communicate with people who aren’t much tech-savvy.

What needs to be done to ensure data security on the platform?

Not all healthcare chatbots need to be HIPAA compliant. For example, if you’re building a chatbot that sends medication or appointment reminders, it need not be HIPAA compliant. You only need HIPAA compliance if you’re collecting protected health information (PHI) from end users. But the discovery phase is the right time to know if you need it as it saves you the stress and effort to make it HIPAA-compliant later. It also adds an extra layer of trust when your users are interacting with the chatbot.

Engagement model vs. delivering information model

In the discovery phase, decide if the bot will be just sharing the information with the user in an FAQ format. Or, will it engage with the user to better understand the question before the information is shared. The answer to this question will impact your technology choice of building a chatbot.

Customized content vs. generic

You need to think if the chatbot would be connected with a user profile or will it run independently. Needless to say, building a generic chatbot that gives the same answers to everything is a bit easier than building customized ones.

Will it be paid or free to use? 

Most chatbots I’ve used are free to use. But they’re built by companies and products who already have another revenue stream running. So they build a chatbot to augment their services and improve their customer experience. If you’re building a standalone chatbot to solve a unique problem that no one has addressed so far, you can think about making your chatbot a paid tool. Or, you can think of keeping some part of it available for free and a premium version for people who are able to pay for your unique services.

What kind of user experience needs to be delivered? 

User experience in chatbots is usually hush-hushed, but it plays an important role. The visual language of chatbots plays an important role in engaging the audience. You need to answer questions like – how can designers reduce the complexity of conversations? How can you reduce cognitive load on the user?

Phase 2: Capturing the requirements

After the discovery phase, it’s time to act on the inputs you’ve gathered and get down to action. Start by capturing the requirements from all stakeholders. I’ve shared the two most common ways of capturing the requirements-

User Stories

Writing user stories is the most effective and easy way of figuring out what users want. User stories are written by the development team from the point of view of end-users. It’s an informal and casual explanation of what users want to achieve in their journey.

The most commonly used format is as below-

As a , I would like , so that

I’ll share an example of a user story. Let’s suppose, you’re designing a patient registration and onboarding chatbot. In this case, one of your user stories could be–

As a patient, I would like the chatbot to share the registration link, so that I can sign-up on the platform.

There are certain advantages and disadvantages of writing these kinds of user stories.

Pros: Capturing the requirement in this format forces the product manager to think from the user perspectives and helps in prioritizing the requirements.

Cons: In this format, the visualization of interactions is missing. This makes the conversation flow hard to understand, and results in a lot of iterations at a later stage.

Conversation workflows

A lot of online tools are available to create sample conversation flows. BotSociety, LucidCharts, Draw.io, Bot UI Kits, are some of the popular ones.

LucidCharts is an easy to use tool to design the conversation flows, inject the rules, interactions between the bot and the user, and connect conversation flows.

Example: Below is an example of a conversation workflow that you can use as a reference.

Pros:

• Allows the product manager to think from the experience and conversation flows/interactions standpoint
• Helps discover rules that will govern the conversation flow
• Figure out how one state would connect to another and how the switch would happen
• The tool is easy to incorporate changes, scale, and add more utterances within a pre-created state.
• Conversation workflow designs also help in understanding the training data and add natural language processing (NLP) to understand the users.
• Since this is a continuous cycle that moves the bot from a decision tree structure to a natural conversation over several sprints, it is easier to match the user intents to existing features or highlight the need for new responses.

Cons: Creating conversation workflows is rewarding but time-consuming. So if you are working with tight deadlines or release dates, you might want to skip this step.

Phase 3: UX research

You might want to skip this phase and move directly to phase 4. But let me share a few reasons why UX research forms an important part of chatbot development. User research acts as a foundation for your design strategy. It helps you uncover data that can guide you for important design decisions.

Another advantage of user research is that you can guess the product adoption lifecycle of your chatbot. The research will guide you on who can be the early adopters of your product, who would be interested in paying for your chatbot’s services?

One of my colleagues wrote an article on UX research methods for building conversational AI chatbots in healthcare. If you’re building a healthcare Chabot, I encourage you to read this article.

Phase 4: Selecting a framework and architecture

Before finalizing the technical architecture, making a choice to go with the open-source platform to build rule-based or building it from the ground up, it’s important to understand—

1. Persona you are targeting
2. The channel of delivery
3. Data security and policy
4. Use case

In this post, I’ll talk about two kinds of framework that you can use–

1. State Machine
2. RASA

When should a state machine framework be picked?

The decision to use a State Machine Framework should be made when the chatbot is–

• to be governed by complex rules and conditions rather than intents (NLU).
• to be independent of the user profile. That is when every user starts at the same initial state.
• to have a finite number of states, and each state has an entry and exit criteria. Each state is linked to another state and is ruled by transition criteria.
• to handle more sophisticated conversation based on the training data availability, which is more as the users interact with the chatbot. The more data NLU experts will have to train the bot.
• to incorporate more conversations flows without changing the source code.
• to transit to the next state based on the user input that matches the keyword attached to that state.
• to build the user profile by engaging in the conversation.
• to provide or achieve different types of functionality between 2 consecutive messages exchange.
• to process multiple inputs from the user before sending the follow-up message.

What is a State Machine?

A State Machine is an abstract machine that behaves based on the user’s current state and a given input and performs state transition and provides an output/outcome to the user. It is a mathematical model composed of a finite number of states and transitions.

State Machine Elements 

• Rule (The governing body): State has an entry and exit clause. These clauses determine which state the user can enter and when he/she can exit. In our case of Rule-Based Chatbot, it must be the “intent” of user input (NLU intent of user input).
• Next State: Every new user is assigned to default or initial state, and based on their input, the machine changes their state. For each state, we can set up the entering and exiting rule and prioritize which state should be accessible first, second, or so on based on the user input’s intent.
• Events (The Transition): This is an instance that could impact the State Machine. That could change the state from one to another.
• Actions: It is the outcome that happens when the event instance is dispatched to the state and it produces an action. An action is a granular unit of work. A state can have one or more actions. In Rule-Based Chatbots, we could have actions like Send Message and Change State that can be created for a state.

How State Machine Framework Works for a Rule-Based Chatbot?

State machines have a finite number of states and based on the user input, the state transition happens. Each state has a rule that specifies which state to move based on the user’s input.

Consider we have State A, B, C, D, and E, and let’s assume that State A is the initial state. State B is–

1. User enters “Hi”

2. Bot will assign State A to the user and respond with the message “How are you feeling”?  It will also schedule a change state Action for the user to “State D” to be triggered after 3 days. This change state action will be automatically killed if the user replies within 3 days.

3. Now the user can reply back with positive intent, negative intent or choose for no reply. If the user replies back a text with positive intent, he will move to state B as B is having positive intent as its entering rule. The same goes for the negative intent message.

4. Once the user enters into any state, its corresponding actions will be executed in the pre-configured order.

Preferred tech stack

Backend: Django (mobile APIs and maintaining user’s state) + flask (communication gateway)+ Redis(caching and scheduling task and reminders)

Frontend: Mobile App (ReactNative), Web App (React/Angular)

Database: Postgres

Google Services: Location APIs for coordinates, Firebase for Push Notification

AWS: S3, EC2 & RDS

Twilio for sending SMS messages

SendGrid for emails

NLP Library: SpaCy, StanfordCoreNLP, RASA Core

RASA

Rasa is a popular open-source platform for building chatbots. Rasa provides infrastructure & tools for developers to build proprietary contextual assistants.

When should an open-source framework like RASA be picked for building a chatbot?

An open-source platform should be picked when-

• chatbot is required to be governed by intent (NLP) rather than complex rules.
• chatbot is not necessary to perform any transitions.
• chatbot is needed to be built without writing the complex source code. Turn-Key Solution is preferred.
• User’s data security is of utmost importance.
• a turn-key GDPR and HIPAA compliant solution is needed.
• integration with multiple channels is required and offering a uniform experience is crucial.
• The delivery timeline is short.
• An NLP engine is not required to be built from scratch.
• there are no guardrails required around the conversations flow.

How to build a chatbot using RASA? 

For more information on how to build chatbots using RASA, go to their website that has well-documented information. I also found a blog that shared a step-by-step approach to building rule based chatbots using RASA.

Phase 5: Testing the chatbot

Testing chatbots is hard because the non-linear inputs are difficult to monitor. Other than that, sifting through the staggering amount of data a chatbot receives is not an easy task. But difficult doesn’t mean impossible. There are various tools available in the market that make the testing process easy.

What needs to be tested?

You must be wondering what all aspects of a chatbot need to be tested. Let me share a few areas. If you have built and launched a chatbot, you need to is if it-

• is understanding the intent of the user’s input
• is changing the state when required
• is understanding the vocabulary (NLU)
• is responding with the right fallback messages
• is understanding small talks, free form messages
• is responding back in adequate amount time without any delays or errors
• And of course, following the flow of the conversations as programmed (Happy Flow)

There are many tools available for both manual and automation testing.

Manual Testing: Using Apache POI library, which reads data from an Excel file, that defines the conversations that the chatbot should be able to handle.

Open Source Automation Testing Tools: Botium, Chatbotest, Dimon, QBox

User Feedback: Using tools like Instabug

Phase 6: Measure success of chatbot

And you thought your work ended at testing? Not really! Deploying the chatbot after testing it and thinking that your work is done is like burying your head in the sand. Measuring the success of chatbot is crucial because it allows you to see the true worth of your idea.

There are several chatbot analytics tools available that can help you to measure your chatbot’s success. You can look at successful/unsuccessful conversations, average session of a conversation, what were the questions that chatbot couldn’t answer, are users happy with chatbot’s services, and so on.

One of my colleagues wrote a detailed post on how to measure success of a conversational AI chatbot. You’ll find detailed information on the tools, along with pros and cons, in the post.

---

As you can see, building a rule-based chatbot from scratch is a time-intensive process. It’s imperative that you pay each phase its due time and resources. And just as they say, the fruit of patience is sweet, the chatbot would reduce your dependency by reducing time in conversations with your end users.