Botpress vs Dialogflow ES vs Dialogflow CX in 2022 [Part one]

Comparing Dialogflow and Botpress is daunting and a time sucker. Both chatbot making ecosystems have countless functionality and different ways of doing things that make head to head comparisons tricky, even for people in the industry. If you are deciding between the two for you next project, there is really only one real factor that can force you one way or the other depending on your requirement (Botpress isn’t a SaaS, and Dialogflow is hosted). For the most part, you’ll find that both options are legitimate, but you may find a preference.

To help you understand what it’s like to build a bot with Dialogflow or Botpress, I’ve come up with a list of important points and taken screenshots so you can visualize the practical differences. I've focused on : general ease of a platform, onboarding and working with new team members, performing common actions & managing things at scale.

It’s important to note that, to a certain extent, when you go for Dialogflow, what you’re really doing is investing in Google Cloud Platform, so I've grouped Dialogflow ES (essentials) and CX (customer experience) together. Also, to be fair, I'll be comparing with Botpress Enterprise, to make sure the comparison is for paid solutions.

TLDR

For a pure FAQ style bot, Dialogflow ES will do the job! For full control over your capabilities and data, you need to go to Botpress Enterprise and self-host. Otherwise, Dialogflow CX and Botpress can handle most projects well, and all three have similar language understanding capabilities. Dialogflow CX has overall slightly more features and has the google polish, while Botpress is easier to understand and work in. Pricing is tough to compare, as the Dialogflows are priced per message (CX being much more expensive than ES), and Botpress’s pricing model is more service-oriented.

Comparison Table of Differences

‍

Full Comparison

‍

Adding Buttons, and choices

Buttons, choices and suggestions are wonderful because they allow users to know what the options are, and make it easier for them to pick what they want. Even on phone calls, options can help users navigate through menus. On other text-based platforms that don’t support buttons shorthands can make it easier to answer.

Dialogflow ES

• The default response types on Dialogflow ES don’t contain anything resembling buttons!

• When you select a platform like Slack that supports button-like functionality, you can see the built in response types for it. Slack has Image, Card, and Quick Replies that the default (no-platform) option doesn’t have.

• Quick Replies and Cards are easy ways to add buttons in Slack.

• In the chat emulator, a platform specific preview shows the difference between the two. It’s convenient to have this within Dialogflow itself.

• You can easily add links or text. Quick replies have their values equal to the text. Values are used for Natural Language Understanding intent detection.

• There are two ways of handling responses. The first is to create an intent with training phrases similar to the one used in the Card / Quick Reply. Dialogflow catches it and sends the user to the response.

• The second method is to use fulfillments, a fancy way of saying actions performed afterwards. Specifically, fulfillment’s webhooks just mean : handle the response with code.

• Unfortunately you have to go to a different page to handle all your fulfilments.

1 of 8

At this point, you’ll have to use google cloud functions, or your own server to handle custom logic. There is an integrated code editor, but it is quite limited. It will do in a pinch for one or two actions, but you wouldn’t want to have your entire code here.

If you are planning on supporting multiple platforms, including web, you’ll have to create responses for each type. The upside is that this is less likely to break. On the other hand, you’ll have more repeated work. Platform specific previews are great for testing. It’s difficult to go from intent to intent, to see what clicking a button really does. If the response handles code, it’s also difficult to see what is happening, even just to get a general perspective of what is going on.

Dialogflow CX

Dialogflow CX handles buttons similarly and differently at the same time.

• In a page, you need to edit fulfillment. Think about it as actions that happen within this page (position of user in conversation).

• The menu for adding Dialog Options. Text is straightforward, but there is no clear option for buttons.

• The “Custom payload” option is what you need if you want to add buttons. It’s not very intuitive.

• For example, this is how you add buttons / chips. You will need to navigate the documentation.

• If you click the test agent button and try it, you get something like this. No buttons, no way of seeing what the button would look like on different platforms. Not very helpful!

• To test out your flows, go to manage, then integrations, then Dialogflow messenger’s connect button.

• Enable, then click done

• Click the subtle "Try it now" button, then open the chat bubble on the bottom right and try your queries. It seems like if you want to try it out more conveniently, you need to create an html file and add the code they give you.

1 of 8

Good luck figuring this one out! The UI doesn’t make this obvious, and searching for the answer will yield you results for Code based-solutions and for Dialogflow ES. Rich responses are powerful, but for some reason haven’t been given proper GUI treatment. This is a coding based solution that you are forced to deal with in a gui. Finally, testing this out in the emulator doesn’t show you how it would look for different platforms like Dialogflow ES, or how it looks on webchat.

Botpress

• From the left menu hand, drag and drop the choice icon.

• Questions can be re-used, so there is a selector

• Picking questions and answers. Notice the disable free text. This of course only works on platforms that allow it.

• After creating or selecting the question / answer pair this is what you see.

• The advanced section allows you to give a prompt a set amount of times if the user writes an unmatched answer.

• In the flow editor, you can easily visualize and handle the consequences of the choice. On failure is for when the user hits the maximum amounts of incorrect responses.

• If you don't want to force a choice on a user, but rather simply give them suggestions, set the max number of retries to 0 then detect user input in the “User_failed_input” element that triggers “On failure”.

1 of 7

Overall making required choices is easy on Botpress once you know how and easy to visualize. Providing suggestions is less intuitive and feels like an unplanned use of the Choice skill functionality. The fact that buttons are cross platform can save you time if you are planning on supporting multiple platforms.

Comparison

Botpress is somewhat unintuitive here, in that you need to use the choice skill, even if you want to show suggestions. The advantage is validation; you can force the user to respond to one of choices. Splitting off suggestion functionality from the choice skill might help make this easier. Dialogflow ES is somewhat easier. The issue is that there is no button functionality for all supporting platforms. You need to open the platform specific tab to try it. It’s moderately difficult to find. Dialogflow CX is the loser here, with no GUI-based way of adding buttons. Not everything is better off with code, and it’s a bit difficult to understand why they went this way. While Botpress and Dialogflow ES both could make it clearer how to add buttons, Botpress offers convenient cross-platform buttons and validation, while Dialogflow ES makes it much easier to have suggestions.

Visualizing button pressing flow

Botpress takes the cake here. For it’s single fit solution makes it easy to see what happens after a button has been clicked. Dialogflow’s buttons offer a convenient link functionality, but in terms of conversation flow, this can be tricky to visualize. Dialogflow ES doesn’t have a visual flow like Dialogflow CX or Botpress, so that makes it also difficult.

Testing out the buttons

Botpress and Dialogflow ES have opposite strategies in the emulator. Botpress assumes everything will be similar, so only shows you one general view, and Dialogflow assumes everything is different, and shows you each version separately. For some reason, Dialogflow CX seems to have gone the path of having the default emulator not showing you either, and instead shows you the data. This is quite inconvenient, both when developing for a single platform, and multiple platforms. It’s an example of CX not just being an upgraded version of ES.

Natural Language Understanding Capabilities

Chatbot maker solutions often boast of industry-beating NLU (Natural Language Understanding), but how does this translate for conversation building? There are two questions you should be asking about NLU if you are planning on using it. Does it support X language, and how well does it support it?

There are generally two things that can go wrong with NLU. The engine detects something when it shouldn’t (false positive), or it doesn’t detect something when it should (false negative). In practice, the solution to both problems is to give the machine learning engine more examples and counterexamples. When both engines have similar benchmarks, the difference is you will probably have to add a bit more example sentences to cover edge cases to the less accurate engine for it to be as accurate. This may not even be the case, depending on the topic you are trying to crunch.

Botpress open source offers fewer language engines than Dialogflow when used locally (12 out of the box). If you want to use a language that’s not one of the 12, you can also use a FastText model (Facebook Open Source with language list found here) for NLU, and if you need to tweak your language model, you can do so. You can also use the Dialogflow engine for it’s NLU if you’re okay with Google hosting your data. It’s not either or. Both platforms are always improving on this. Since Botpress can use Dialogflow for NLU, the fair comparison is what can Botpress NLU do that Dialogflow NLU can’t.

NLU in a popular language is likely to be of similarly good quality on both platforms, and less popular languages will be more troublesome.

That being said, If you expect Hebrew or Arabic support, please note that at this moment, Dialogflow ES does not support those languages.

Recognizing Sentence Elements

Typically, natural language understanding is broken down into two components, intent detection and entity recognition. You can think of intents as sentences, and entities as a part of a sentence you wish to understand. Dates, times and location are entities.

Take this sentence as an example to illustrate : “Find tickets from Tokyo to New York on June 11th”. The intent is purchasing a flight ticket, and the sentence itself is called an utterance. An intent will typically have many utterances to feed the Machine Learning Engine. Tokyo, New York and June 11th are all entities. Tickets are not an entity because this sentence structure wouldn’t really work with something other than plane tickets. However, you could have it as an entity if you had a “purchase something” intent. It’s up to you to decide what you want to extract!

Dialogflow and Botpress have more or less the same kind of functionality, with User Experience changes, and ready-made options.

Dialogflow ES

To create an entity in Dialogflow ES you can assign them first, or add them after you wrote your utterances.

• To create an entity from an intent’s utterance, simply highlight the part you want (in this case #14147) and a popup appears.

• There are a lot of default options out of the box.

• When your search turns up empty, the create new button is convenient.

• “Allow automated expansion” allows the user to write something like “apple, pears, bananas”, and the NLU could match “oranges” too.

• Once you have defined your entities, and upon creating an utterance, Dialogflow will automatically tag the contents. In this case, the automated tagging was a bit overzealous, but it’s easier to remove the tag, than to add it, so all is well.

1 of 5

Dialogflow CX

• Interestingly, Dialogflow CX doesn’t follow Dialogflow ES when it comes to entities. The new entity button is missing, so you’ll have to go somewhere else to add it.

• Instead, you get this at the bottom of the intent page. “Is list” allows you to put a series of values (apple, pears and bananas), and “Redact in log”, is for developers to hide sensitive information like credit card numbers in their logs.

• In the Dialogflow CX entity page, you can create entities. This is essentially the same as Dialogflow ES, but in a different order. The main exception is the “Redact in log” option found in advanced.

• This is something unique to Dialogflow CX.

1 of 4

Fuzzy matching and automatically added entities causes the issue of false positives. For example, if you want to detect round fruits like apples, pears and melons, and select that option, bananas would also match, despite it not being round. Entity exclusions can be used to account for that, although naming all non-round fruits would be impractical. Your mileage will vary.

Botpress

• Creating an entity in Botpress is quite simple, but it’s not done on the fly.

• Highlighting something doesn’t give you the option to create a new tag like Dialogflow ES does. At least you can press the number on your keyboard (in this case 0), in order to quickly tag everything.

• If you want to tag something, you need to create a slot first. This is different from Dialogflow.

1 of 3

Comparison

Entities are abstract for everyone, and no platform makes it as intuitive a concept as intents. Users need to search by themselves, or discover it in the documentations / tutorials. This is an action that will very often require Developers. That’s because many custom entities like order numbers will require Regular Expressions.

Fuzzy matching in Dialogflow seems slightly more powerful, because it also fuzzy matches re-ordered words, but unless the language allows words to be re-ordered, this doesn’t seem to be very useful.

The real difference between the Dialogflow and Botpress is automated expansion. You can provide a list of synonyms and Dialogflow will still be able to understand. Given a shopping list : apples, pears, bananas, as entity examples and the sentence “I want to buy mangos”, Botpress will not correctly detect it, and Dialogflow does. You can solve this by adding more exceptions, but that is more work. This also creates a new problem, as you now run the risk of over-detecting. The exception field in Dialogflow CX is designed to handle this. Overall, since this optional, it’s inclusion is a benefit in favor of the Dialogflows.

For an average user, Dialogflow ES wins for having the most default options, automated expansion, and more convenient tagging.

Dialogflow CX, wins on in-sentence lists of entities. You can do this in Botpress but it’s considerably more complicated. Dialogflow CX also wins with their feature of hiding information from logs, which may or may not be important, depending on your use case, but this is only a win over Dialogflow ES, as you have total control over Botpress.

In Dialogflow, entities are automatically tagged, and the user can modify the name if they want to differentiate. Somehow that’s more and less intuitive at the same time, but for people who start out, it’s one less thing to worry about. In Botpress, entities need to be created first, before the user can tag them in utterances.

Deploying production-ready chatbots

You could say Botpress has to be hosted yourself and Dialogflow is already hosted for you, but that wouldn’t paint the right picture. In practice, Botpress Enterprise offers hosting services, and you will likely need some deployment with Dialogflow. Why? Because while Dialogflow can be fully run from the cloud, the moment you want to add custom functionality, you have to deploy that functionality yourself, on the suggested Google Cloud or elsewhere.

Dialogflow ES

So long as you are not adding custom functionality like fetching order information from a remote database, you won’t be needing code deployment, but there is still the bot version deployment to do (all in the cloud).

• Once you are ready to deploy, go to settings, then click “Publish a version”.

• Give it a name, like Initial release or v1.0.

• You can call your environment “Production”. The Cloud Function fulfilment option is the same as Webhook, but integrated with Google Cloud.

• In the Integrations page, select the integration you want, then you can select the environment you created. That’s it!

1 of 4

For deploying your custom code, you can pick another platform, but all the documentation will point towards using Google Cloud’s serverless functionality. You will use this api to deploy your code.

In reality, if your bot is any bit complex, it will access an API, and if in doing so, you will need custom code. While this is simply done (upload your code with one command), if you want to do any kind of usability tests before changing your code, then you will likely have to create a copy of your agent in Dialogflow ES to test against. There is no easy way around this.

Dialogflow CS

This is very similar to Dialogflow ES.

• You need to create a version for the environment first.

• Dialogflow CX has an almost identical organization as Dialogflow ES after creating a version. Create an environment (in this case Production), then navigate to Integrations.

• In the Integrations page, you can once again select production to deploy. Like for Dialogflow ES, for deploying your custom code, you can pick another platform, but all the documentation will point towards using Google Cloud’s serverless functionality.

• This is how you link up to your functions in Dialogflow CX. There is no shortcut to Google Cloud Functions like in Dialogflow ES, but you can use all the same.‍

Botpress

Deployment of Botpress is usually done by the user to maintain data ownership, but Botpress can host or help with hosting depending on your needs. At the time of this writing there is no self-serve hosting functionality. Custom functionality is attached to the Botpress instances, so this somewhat lessens the complexity of deployment over Dialogflow. For a scalable deployment, you will need a software engineer versed in hosting software, or use Botpress Enterprise services.

Botpress Enterprise does include pipelines that allow you to identify and move a bot from draft to production, but this requires you to already have hosted a production ready instance running.

• Botpress provides a production checklist to make deployment easier.

• Since functions live in Botpress, everything can be tested together, and you can move everything to review, then production.

For connecting with an integration, you’ll have to follow documentation. Most of the work is done in configuration files, so you’ll want a developer to handle that, or Botpress Enterprise Services.

Comparison

Dialogflow ES is difficult to beat if you don’t need any custom code. It’s intuitive and quick. If you do need to deploy functions, you’ll end up with an extra step. Dialogflow CX is slightly more difficult to deploy to production environments (one extra step, and less obvious error messages), and has the same issue with custom code. The upside of using Google Cloud Platform is that you are likely to use cloud functions. While they are not the cheapest way of hosting code, they are the easiest way to have highly scalable functions.

The process to deploy functions for Dialogflow is to create a new function, host it, get the link, update it in the Dialogflow webhook / fulfillment, test the new version to make sure it works, and if so, deploy the new version. The first time, it shouldn’t be too much of a pain, but if you think you are going to often update your code to match your conversation logic, you are adding an extra layer of complexity. In Botpress, code and conversation logic live in the same world, so updating, testing and deploying is much easier. The downside is that the developers must use Nodejs, so if they aren’t familiar with it, there will be a learning curve, depending on what they previously used. The upside to that, is that in theory the documentation should be more up to date, seeing as there is only one library.

Were it not for custom code, Botpress would be the worst in this category, because you actually have to host something, as opposed to not. While Botpress offers deployment services, so technically you don’t have to do anything, it will never be as convenient as the self-serve model. Custom code negates the advantage this confers to Dialogflow.

Hosting yourself has the problem of managing scaling. Of course, if your project cannot include outside services, then Botpress is clearly the way to go. Botpress does have documentation on deployment for it’s Open Source version, but it’s not a complete auto-scaling architecture, as you would get from going with Dialogflow.

That's it for this part. Here is Part 2 of Botpress vs Dialogflow ES vs Dialogflow CX.