What is Google Dialogflow?

We are undoubtedly witnessing significant growth in software services designed for helping businesses increase the ease with which their clients access them. More and more, companies both big and small are turning to such technological solutions which in turn transform the way businesses and clientele communicate. By offering more instantaneous responses to queries, businesses stand to enhance customer satisfaction and thereby strengthen loyalty.

On a more personal level, I had long been sceptical of engaging a bot, however, once offered an expedient, simple solution to my problem within minutes, I began to think otherwise. Yet the question remains: are chatbots as reliable as traditional customer services, and are they natural and organic enough to handle user-specific issues? 

While working on a recent project, I came across a  product from Google Cloud Platform called Dialogflow. It turned out to be a very interesting experiment and actually,  worked better than I'd expected - hence the following article.

Business-customer conversations

Dialogflow is a service powered by Google Cloud Platform, enabling business-customer conversations, either by voice or text and built on natural language processing (NLP). Given its breadth of possibilities for integration, it seems a good fit for any kind of business. It can also be used within many popular platforms and services like Facebook Messenger, Slack, Skype, Twitter,  Amazon Alexa, Hangouts Chat, Viber or Twillio. However, unlike many existing chatbots using strictly pre-designed conversation flow, Dialogflow provides better UX owing to the use of machine learning. The present-day trial version (ideal for non-commercial projects) is free of charge and likely a good choice when starting your experience with chatbots and voice apps. The standard version is sufficient for a small business as it's priced based on usage at $0.002 per text request. 

How does Dialogflow work?

Depending on the complexity of your conversations, if they need any personalized data to be displayed to the client or saved into your database or how many scenarios you foresee happening within one conversation topic, the time you will spend on creating your chatbot may differ significantly. However, the flow is, in short, the same in every case: 

• The user sends an inquiry to your app
• Your application sends the user's message to Dialogflow
• Dialogflow categorizes the query's intention (assigning the right intent)
• When the right intent is found, Dialogflow uses assigned entities or context parameters, and if needed, requests external data via webhooks and prepares formatted and personalized answer
• The answer is sent to the application
• The user receives the response 

To better understand the flow which is very important when creating your first chatbot, you need to get a better idea of an agent structure, of what intents, entities and contexts are.

What is a Dialogflow agent?

A Dialogflow agent is your virtual agent dedicated to handling conversations within a specific chatbot. It contains the entire structure for creating a natural dialogue flow and as such, provides a top layer for language configurations and a knowledge database for further agent training. An agent can handle conversations in over 20 languages and if needed, can be multilingual. As with humans, an agent is only as good as we train him to be; his knowledge is built with the use of machine learning mechanisms like intents and entities.

What is a Dialogflow intent?

The most important element in the Dialogflow structure, one responsible for identifying a user's intention, is intent. Finding the right intent has a crucial role in creating conversation flow. It defines what the user is looking for and enables us to configure organic answers via many text scenarios and custom parameters. From this point onwards, we can employ webhooks for the use of external data. Intent can be triggered by a specific event in our application, for example entering a page or identifying users input in our chat window. Let’s take another example of a platform for booking doctor appointments. We would like to initiate the conversation in a moment when the user types something in the chat window. We should start by defining why our customers are writing to us. They may either want to book an appointment or just get information about our opening hours. For each intention, we create a separate Dialogflow intent. 

To help our agent in matching the right intention, we create training phrases. A training phrase is nothing else but our prediction of what the potential input may be. For example “I would like to book an appointment”, “What are your opening hours” or simply “Hello”. The more training phrases you write, the faster your agent will learn. A fact worth mentioning is that each user's input is stored as a history, thereby providing material for future agent training through which to achieve a best-possible match accuracy. 

When a user's input matches any of the given phrases the intent is found. Where input does not match any training phrases, a fallback intent is called up for handling any unforeseen situations. We can configure a fallback message to guide our client toward asking the right question which, hopefully, will generate the right intent.

For each intent, we set up further scenarios. In the first case, we can simply posit a simple static answer like “We are open from Monday to Friday from 8 am to 6 pm”. When it comes to booking, we need more information from the user to proceed. We need to know when and what kind of doctor is required. For this purpose we use entities.

What is a Dialogflow entity?

To identify specific information a user gives us, we use entities. These are variables, words or phrases standing for dates, names, addresses or any kind of information that is unique to the user, all of which helps us to process his request. Dialogflow by default provides us with a library of system entities for more common variables like date, location, address, email etc., but we can specify our own entities in the Dialogflow Entities section of the platform. In our booking example, there are two user-specific bits of information required: the desired date and name of preferred specialist. For a date, we can use offered system entity @sys.date, and for the specialist, we need to create a custom one for eg. @doctor. 

We immediately assign as many specialisations as we can think of for a variable called @doctor. Our agent will also learn new ones from within training phrases. We define what information we are expecting to receive from the user in the “action and parameters” section of our intent. Since we are without an appointment date and type of specialist and are unable to finish the booking, we can mark these as required parameters. We can then add more training phrases, including specific dates and names of specialisations and match them with our expected entities. This allows our agent to learn the pattern, search for this information in a user's message and store the values or require missing information.

In a scenario where a user does not specify the date or specialist in the initial message, the Dialogflow agent will detect this and follow up with questions specified in prompts (actions and parameters) to get the required values.

Given values are stored as variables inside the intent and we can refer to them in our answers.

When we have all the information we need for progressing the booking, we can then enable webhook calls for this intent. This allows us to connect to any endpoint of our choice for processing the gathered data, check a doctor's availability, create appointments in our database or trigger possible answers based on the booking status straight from our application. 

What is Dialogflow follow-up intent?

But what if there's no spot available in tomorrow's schedule and we want to offer the user another option?  We set up a follow-up intent.  This will be only matched as a continuation of our booking appointment topic and will carry on all the parameters and values given in the first part of the dialogue within its context. 

Dialogflow contexts are similar to natural language contexts. If a person says to you "yes", you need context in order to understand what they are referring to.

With follow-up intents, we can create many dialogue scenarios and handle them individually. By asking the right question, we can guide users to give us the answer we need. For example, the question “Would you like to schedule the appointment for another day?” would probably result in either “yes” or “no”. Thanks to the context connecting follow-up intent with its parent intent, we now know exactly which question this answer is referring to. In our example, we can prepare two follow-up intents with two different actions. One is based on the user's positive answers, for which we could use a webhook call to search for the next possible date. The other could easily finish the conversation. 

Each intent can nest as many follow-up intents and as many scenarios as you may foresee. Nesting can go on perpetually, giving you the possibility of natural conversational flow. Designing your machine to interact with customers using the information they provide creates this feeling of talking to a real person.

This simple example could result in a conversation like the one below. It took only a moment to set up on the Dialogflow side and it seems pretty natural, however, it only covers a user's more predictable behaviour with only one direction of dialogue development. Possibilities of creating a dynamic flow are very wide and describing them would require a separate manual. But it's certainly good material to play with if you plan to create a more advanced chatbot. 

In addition to its interesting and complex structure, Dialogflow offers step-by-step testing tools for helping you through your flow, and to visualise how it will look on the user end. I found it very helpful when my intents tree got bigger and its scenarios more advanced. 

Natural language understanding

It's unlikely chatbots will ever be as interactive as humans: we will never be able to fully predict every possible scenario or user input.  But when you think it through then put in the time to design the right flow, I think the experience of talking to a Dialogflow agent can prove a surprisingly good natural language understanding. Admittedly, some of my most advanced scenarios still have messages misunderstood by the agent, but it must be remembered that the machine learning process takes time. The more user inputs we receive, the bigger our knowledge base will grow and thus the greater the accuracy will be in matching and answers. When we analyse the real history of users' inputs, we can adapt our chatbot, add more training phrases and “teach” our agent a better language. This means that for more advanced dialogues, chatbots may never be self-sustaining entities as it would require constant improvements from our side. Still, many businesses can benefit from introducing a virtual agent to their services for handling easy-to-solve issues immediately. In doing so, they save as much customer time as they do their own.  

At Startup House, we're always interested in new ways to efficiency and how to help your business find its best online practice. If you'd like to chat about this or any other area of expertise, don't hesitate to reach out at hello@start-up.house

Recommended readings:

Product Designer’s role in the Product Life-Cycle

Product Managers & the 4 Main Challenges They Face

How can error tracking and application monitoring save you time on development

Security Testing: The Watchdog of Software Protection

Configuration Control: The Choreographer of System Changes

Test Infrastructure: Building Blocks for High-Quality Software

How can you monetize your digital product?

What is the Difference Between Quality Assurance and Quality Control?