1. Home
  2. Training Library
  3. Google Cloud Platform
  4. Courses
  5. Building Chatbots with Google Dialogflow: Part 2

Implementation: Intents

Developed with
Calculated Systems


Building Chatbots with Google Dialogflow

The course is part of these learning paths

Implementation: Intents

This course is the second part of our series on building chatbots using Google Dialogflow. In this course, we'll be taking a hands-on approach to implementing a Dialogflow chatbot, specifically focusing on the graphical user interface. You'll follow along as we cover the example of building an online banking customer service chatbot using Dialogflow.

We'll also discuss the use of databases and other knowledge sources in order to provide meaningful responses that give you the option to serve real-world information to your user. 

Learning Objectives

  • Learn what intents are and how to train your chatbot to look for them
  • Set up entities in Dialogflow
  • Understand how chatbots interact with users and how to test your chatbot
  • Learn how to connect your chatbot to a data source
  • Understand the user interfaces available with Dialogflow
  • Learn how to use the Knowledge service to build chatbots quickly and with less configuration

Intended Audience

  • Anyone looking to build chatbots using Google Dialogflow


Before taking this course, make sure you've done Part One first. To get the most out of this course, you should also have a basic understanding of: 

  • Computer science techniques
  • REST APIs and SQL
  • Google Cloud Platform

Now in this segment, we're gonna dive right into how to create Dialogflow in a very real, literally practical sense. Not only are we going to define intents, we're also gonna discuss how to do entities, parameters, responses and all of the functionality as a click through demonstration. I'll explain the components as we go as this is a graphical user based tool. We should absolutely take advantage of the visual interface and show you what it looks like as we describe the concepts.

So what we're gonna do is build a chat bot that mimics the previously mentioned real-world banking concierge bot. We're going to have two main intents. One of which is to check balance of a payment card and the other is to transfer money between two payment cards. So we have two reusable payment cards each of which has a different number but they follow the same pattern. We want users to be able to ask queries about how much money is on each card but also transfer funds between the cards.

So with these intents in mind, normally we would first work with the broader team and select a set of training phrases. But for now, we're gonna skip over the training phrases just take the intents and actually start creating a bot. So the first thing when Dialogflow is opened, the new interface reminds you that this is in fact a Google product. Remember, the only way to use Dialogflow is through Google. It's actually considered part of Google Cloud. What this means better for worse, depending on your perspective, is that you need a Google Cloud project connector at the agent level. This means the highest level of everything will be underneath an existing, or if you want to creating a new Google Cloud project. This has some good and bad implications.

The good implications are that you're able to take full advantage of existing service controls, security controls, and integrations to get you started with your project. This means you have a single interface to permission your systems through a very common set of tools along with the rest of your assets in your project. But the downside, which is literally the same thing, is that everything has to be controlled through the project. You're tied at the hip to Google Cloud.

An important nuance though, just in case anybody is not a primary GCP user, the fulfillment and data repository services and the integrations that handle the incoming and outgoing messages to the end user, don't have to be on Google Cloud. Just the chatbot itself lives on Google Cloud. So if you have data elsewhere or you have a preferred integration that's not a Google service, you're absolutely able to bring those as well. 

So when you go to create a new agent, you'll see that you either can create a new project or link it to an existing one. If you're doing this for the first time I recommend creating a new project especially if you're brand new to Google Cloud. You should type out a agent name as well, one that is descriptive and what we could call machine safe. This means avoid white spaces and special characters as this might get passed to the backend.

At the top, double-check the new time zone and then finally hit create. At this point, you're gonna see a status where it's gonna show that it's working and eventually it'll switch over to done. While this sets up, be aware that the project you're creating potentially has billing implications. So if you're with a bigger company make sure you're part of the right organization and that it's linked to the right billing account or if you're an individual or small team just make sure you have billing enabled.

Now Dialogflow and its core is quite cheap and they have a very good free tier. So it's not a terribly big concern, just something to note. So when you see it going from working to done, you'll then be greeted with a screen that looks like this.

At the top left, you'll be able to see your agent with a gear that brings you to settings and by default, you're gonna land on the intent screen. If you're ever managing multiple agents or collections of agents, just pay attention to the top left, you can click the down arrow and quickly change between an agent you're on and also make sure that your agent and language are correct.

So let's dive into creating some intents and discuss the practical step-by-step process for what that looks like. So in creating your first intent, let's discuss the one we just went through, check card balance. There's two variants of this. One is just for a single card and the other is for all of your cards.

The parameter here could either be card number or the word well, all, because we need it to be able to handle more than one card. A very important nuance here is that this is a one intent. We don't have separate intent checking for one card or all cards. We have one intent that is well parameterized with well-defined entities. This is extremely important because checking card balance for just one card versus all cards has a large amount of overlap in how a user might talk to the agent. And people who would request that would have a lot of overlap between intents causing confusion and this is gonna lead to much worse results and the perception of a worst chatbot.

So it's important to remember, keep the number of intents low with clever parameters and good actions for slot filling in order to have a good bot. We also have a second intent that signals that the user wants to transfer money. We'll dive into the specifics in a few minutes, but just know that this one actually has some interesting complications to it. And that you actually have two cards that have different meanings.

This leads to the same entity card being assigned to two different parameter slots. But let's focus entirely on the first intent for now, the one where you wanna check a balance. If you haven't created any intents before, you'll be prompted with an option in the middle of the screen to "Create the first one". If you've already played with making new intents, don't worry could always click the create intent on the top right, and also don't worry about the default fallback in default welcome intents. Those really just cover how a user is handled when we don't know what they're looking for. So just leave them there and we'll start to create a new intent.

So when creating an intent, the first challenge is to name it. And this might seem a little trivial and a little pedantic, but it's actually extremely important. On a personal, it actually burned us a little bit at Calculated Systems when we were first getting started with Dialogflow because this gets passed to the backend. An intent really needs two things in order to have a good name. First, it needs to be descriptive, but second, it needs to be safe.

Much like the agent title, it needs to have careful spaces, camel case or snake case, because this is going to parse to your backend service. So it's important to understand what the backend service will see. So if your backend service has trouble parsing spaces or maybe if you're looking to parse the intent straight to a Postgres database, and for those of you who're unaware Postgres has some special considerations for mixed case, it could cause a lot of heartache. I typically recommend all lower case with underscores as the safest, but really it's up to you, and this is just my opinion. And also to reiterate and really reinforce it, this is important. Trust me, it'll save a lot of debugging down the line.

And after you've named your intent, it's now time to start training Dialogflow of what to look for in order to pick up on the intent. Now it's important to capture a lot of variability and permutations here, but you don't need to capture everything. If you're familiar with machine learning, you wanna capture it, but not overtrain the model. Although with Dialogflow, you're protected against that somewhat so don't worry too much about over-training but you still need to capture a lot of variations.

You wanna be able to say things to this intent such as card number for 1234A. Maybe you wanna say check balances for all of my cards. Maybe the user says 1234A, account balance. You need to be able to understand what might be passed to it, and if the parameter comes first or after. And in this example that we've discussed you might get a card number, but you also might get some extra entities such as account ID. And although we can disregard this extra information such as account ID, capturing common patterns in the training phrases can actually be helpful to guide the users to the right intent. But very importantly, you need to understand all the ways that somebody is going to ask the question.

Now as a developer, the best way to do this frankly, is to ask your colleagues how they would ask for this intent and to brainstorm yourself. But as you go towards production, you really, really need the help from one of the overlying business analysts, PMs, or somebody who's in the field who has direct contact with the ideal end user. It's a common mistake to assume that you can understand all the ways a real end user's going to use the chatbot, especially if you're not part of that group yourself.

In my experience, people love to give opinions on how you should write your code, especially things that are fun, like chat bots, so ask around. But it's hard to solve this just as a developer because this is really where an organization issue meets a technology issue and you can't solve it with just one or the other. You should also start to brainstorm around this time on how to get to slot filling.

This means how do we ask about an missing entity? Do they even have a missing entity? And what should the up question be? So if we have a missing credit card number or payment card number, maybe you want to say, "I'm sorry what was your card number?" Or, "Hey, what's card is this for?"

Just think of these like training phrases but for slot filling in the entities. And frankly, much like the train phrases this should be part of the before project but let's just assume that you're going to start working through them now. But when you go to set these entities and slot filling, you've actually just walked right into a land mine. You can't actually fully set up training phrases without having entities yet.

After all, how does Dialogflow know what one payment card number looks like, and how does it know what a good account number looks like, and how does it differentiate all of those from a phone number? You can't actually get started to finding really good training phrases until you've defined the entities that get slotted into the parameters.

About the Author
Learning Paths

Calculated Systems was founded by experts in Hadoop, Google Cloud and AWS. Calculated Systems enables code-free capture, mapping and transformation of data in the cloud based on Apache NiFi, an open source project originally developed within the NSA. Calculated Systems accelerates time to market for new innovations while maintaining data integrity.  With cloud automation tools, deep industry expertise, and experience productionalizing workloads development cycles are cut down to a fraction of their normal time. The ability to quickly develop large scale data ingestion and processing  decreases the risk companies face in long development cycles. Calculated Systems is one of the industry leaders in Big Data transformation and education of these complex technologies.