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.
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
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.
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 handles buttons similarly and differently at the same time.
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.
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.
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.
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.
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.
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.
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.
To create an entity in Dialogflow ES you can assign them first, or add them after you wrote your utterances.
1 of 5
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.
1 of 3
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.
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.
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).
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.
This is very similar to Dialogflow ES.
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.
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.
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.