This is the second part of the exhaustive Botpress vs Dialogflow comparison. For part one, click here.
Which integrations are available and how easy are the integrations? Is content per integration or per type?
Existing integrations are key to saving time when doing something a hundred times over.
Here are Dialogflow ES’s integrations from within the UI:
That’s quite the list!
Adding Facebook Messenger gives you instructions, links to more information, information about the environment, and the proper tokens.
Here are Dialogflow CX’s from within the UI:
If everything didn’t look so similar, one would be forgiven for thinking Dialogflow CX shares half its name with its predecessor, but there are only two non web-based text integrations!
Reusing what worked with Dialogflow ES, Dialogflow CX makes it straightforward to add Facebook Messenger. One can only wonder why they didn’t re-use more.
Botpress doesn’t come with a lot in the way of UI-accessible integrations. You will need to change some configuration files and read the documentation.
On the modules page, the only reference is the web channel — which is also conveniently used for the Emulator when developing bots in the Botpress Studio.
The documentation page lists these channels:
In terms of numbers, there aren’t that much more than Dialogflow CX’s, but you get several popular text-based platforms out of the box.
Despite needing to change configuration files to enable messaging channels, the instructions in the documentation are detailed.
Facebook Messenger integration requires a change to a configuration file. This could be made easier for non-technical people.
To get the embedding URL for the web chat, you must open the documentation and build the URL yourself.
Dialogflow ES has more ready-made integrations than both Dialogflow CX and Botpress. Botpress’s UI only mentions webchat, but it supports a similar number of integrations with Dialogflow CX. The webchat channel is by far the easiest to test since it doesn't require configuration (Botpress requires you to go to the docs to accomplish this and Dialogflow CX doesn’t). However, Botpress supports more common text-based integrations than Dialogflow CX. Botpress wins over Dialogflow CX because it’s better to have somewhat complicated integrations to basic services than missing integrations.
How are the bots organized and how easy will it be for you to onboard team members? Will your team enjoy working and collaborating on the platform or will they find it frustrating? The three platforms are surprisingly different from each other in this respect.
Everything is flat in Dialogflow ES. There is no flow editor. This means if you want to send a user to an intent from another intent, it will be tricky to visualize. You need to use context.
1 of 4
You can quickly see if you were to add more complexity (follow-up intents), this would soon become difficult to track. The lack of a visual flow editor is what causes this and is the most significant lacking of Dialogflow ES (and likely what spurred the creation of Dialogflow CX).
Dialogflow CX has a flow editor, but it’s more like a flow visualizer. You can see your flows, but you have to go through many menus and create them by filling out forms to change the appearance.
1 of 4
There isn’t an easy way to make something happen when a page is entered (like start). Instead, such actions must occur when a route is triggered. Say you wanted to add a tracking pixel at the beginning of the conversation to track usage in your analytics platform. You would have to add it as a webhook (custom code implementation) in each route and event handler.
Event handlers are notable routes that handle cases like a user submitting without any text or default responses.
The flow of the conversation can be tricky to follow for two reasons. The first is that there is no top-down logic. Multiple routes can be triggered simultaneously so there is no single position in a conversation. The second reason is that Dialogflow opted not to visually link the routes/event handlers to the pages they flow to and instead treats a page as a whole.
The flow UI really feels more like a visualization than an editor because you can’t move anything or edit anything inline. The lack of control can feel somewhat frustrating at first, but you do get used to it.
Visualization is one area where Botpress truly shines! The visual flow editor/flow logic is intuitive and straightforward. It doesn’t hurt that everything is very snappy.
1 of 6
Botpress’s flow editor is responsive, transparent, chronological, and straightforward. The Q & A feature is fantastic for getting people to contribute without much training.
Dialogflow ES has a straightforward way of visualizing your conversations — a list. Complex conversations don’t appear to be a priority as the method used for conversation logic “context” isn’t displayed on the intents list page. For a FAQ that’s totally legitimate, but for anything more than that, it’s going to be tough to figure out what is going on. It should be relatively easy to onboard new team members if it works for your use case.
Dialogflow CX has what can best be described as a flow visualizer. You can edit your flows through the right-hand menu, by filling and updating forms and saving. Compared with Dialogflow ES, it’s leaps and bounds better at helping users visualize the logic of the conversation. It’s a pity that instead of showing where each route leads, the flow editor treats the entire page (or node) as one big node and amalgamates all the connections to the other nodes, making it more difficult to see which route goes where. You can also have multi-matching or multiple routes triggered simultaneously, so you have to be careful. The UI also does a bad job at showing that intents are optional and how multiple matches are handled. Generally speaking, many things feel more complicated than they need to be. Someone seasoned with Dialogflow CX will not encounter too many issues, but onboarding less technical team members will take time.
Botpress has a proper flow editor. You can move your nodes (the equivalent of Dialogflow CX pages) around within your flows, and connect them by dragging and dropping.
A node in Botpress has three chronological stages, the beginning, the after response, and transition. Dialogflow CX organizes things in hidden but accessible route-oriented silos. This means your node does different things depending on where users will be sent to and you can’t see what everything does at a glance. The benefit of Botpress’s approach is that you can see everything that happens and the logic. Things like displaying a welcome message will be shown in the flow itself. The Q & A feature allows you to quickly onboard non-technical people and have them contribute to your chatbot immediately. You can think of it as having a mini Dialogflow ES page within Dialogflow CX.
Ease of scaling
There are two types of scaling: bots that can scale to handle huge amounts of traffic and complex bots that can scale to handle huge conversation flows.
You shouldn't have to worry about scaling with either Diaglogflow ES and CX or Botpress — provided your project involves a conversational AI platform and your functionality pertains directly to conversations. The base versions of Botpress Enterprise and Dialogflow ES and CX are all auto-scaling and can handle huge traffic. For customer code, Dialogflow can call cloud functions (which are very reliable) while Botpress handles that within the base application (so once again, auto-scaled).
In terms of managing very complex bots, you can refer to the previous section about visualizing entire conversations. Both Dialogflow CX and Botpress should be able to handle big conversation flows. Dialogflow CX comes out ahead in terms of visual polish, and Botpress has a more understandable and decluttered interface. All platforms support User Role Management, which allows you to set different roles for each team member.
Saving and Extracting from Bot Memory (like order numbers)
Memory is a requirement for any non-trivial app. Getting information from another service and displaying it to the user is perhaps the most common use case. Other cases include remembering a user's response to a question so that you can take that into account at a later time.
Without a flow editor, bot memory isn’t as fundamental in Dialogflow ES. Within the UI, there is no way to show or not show an intent-based on parameters. You need to use code if you want to have this kind of logic.
1 of 2
If you want to manage memory in Dialogflow ES, you need to write code. The Dialogflow ES libraries can help, but if you need to write code for every flow logic you will write a lot of code for something that other platforms integrate natively. At that point, you really would only be using Dialogflow ES for its NLU — and you can get that elsewhere too.
Saving and reading bot memory is done via parameters.
1 of 2
Parameter presets are called presets because they happen before any call to webhooks (custom code).
It takes a bit of time to understand the syntax. You will need to read documentation to use this feature. Unfortunately, there isn’t any autocomplete/suggestions interface to show you what variables are available.
The last way of modifying parameters/variables is accomplished with custom code/webhooks. This requires reading this documentation and probably loading a Dialogflow CX library to consume the API. When submitting a response, you can set the session_info.parameters properties to the new parameters you want. There is a lot of reading involved and examples of changing parameters in webhooks are hard to find.
Memory is accessed and set using “variables” in Botpress.
1 of 5
Botpress’ superpower is having an in-app code editor that has access to and is able to update user memory. This will greatly simplify your iteration process.
This isn’t something that’s so easy it's completely intuitive — no matter the platform. In Dialogflow CX and Botpress, the place you are likely to find it first is in evaluating expressions, not in assigning information. Botpress is slightly ahead of Dialogflow CX because it includes graphical variable-insertion functionality.
Dialogflow’s nomenclature here is a bit surprising for a developer. Parameters are variables and can be modified at runtime. Webhooks are more than about signaling — they are what you can use to set parameters with remote data.
Dialogflow ES is simply not a contender here, likely because it’s meant for simpler chatbots.
This is the easiest to talk about and the hardest to compare of the categories. Here are the pricing pages for the three options :
Dialogflow CX is much more expensive than Dialogflow ES, which is interesting because the main difference between the two is the addition of the visual flow editor. Botpress, which also has a visual flow editor, doesn’t operate on a self-serve model, so you’ll have to contact them for pricing. The base Botpress Open Source application is free, and customers can pay to unlock enterprise features and get support. If you don’t want to pay per message and are happy to host yourself, you must go with Botpress.
If you are looking to build a pure FAQ-style bot quickly, Dialogflow ES is probably your best bet. If you have no custom code requirements, a small team, don’t care about on-prem and elementary conversation flows, it’s hard to beat. It has good integrations, is already hosted by Google, has good NLU, and has a straightforward interface. For anything else, there are better alternatives.
Dialogflow CX builds on many concepts from Dialogflow ES and adds scaling features, namely a flow editor and some NLU features like recognizing lists of things. However, it expects the customer to come up with most integrations themselves. If you have a complex application and want to use Google’s products, this will get the job done.
Botpress will feel somewhat in between the two Dialogflows and is Open Source Software instead of a Saas. Featurewise, it’s similar to Dialogflow CX, but with the simplicity you find in Dialogflow ES. There are features and polish here and there that Dialogflow CX has that Botpress doesn’t, but they are mostly on par. If you need to change anything, you can as you have complete control. That aside, the cleaner, more understandable interface in Botpress is arguably the best reason for going for Botpress.
The inclusion of the code editor within the Botpress app may not seem like much, but many changes require updates within the flow, and keeping the two close together makes a lot of sense. Reading and updating variables are more accessible and you can update and test the two without having to redeploy your code each time.
A possible deal-breaker between the Dialogflows and Botpress is deployment. If you want everything on-prem for data control reasons, keep in mind the Dialogflows are SaaS hosted by Google. The other implication is the ease of deployment & maintenance. In Dialogflow, custom code for fetching or updating information will have to be handled in a separate flow, but likely in Google Cloud functions. Dialogflow is easier to deploy, but you’ll have to deploy any code you add yourself, introducing complexity you don’t have with Botpress, which bundles code and logic into one convenient workflow. All solutions are auto-scaling and should be able to handle whatever you throw at them.
Pricing is complicated to compare because actual usage depends on your chatbot. Dialogflow has the most straightforward pricing structure, with a per request pricing model. CX charges an order of magnitude more per request than ES. Finally, Botpress Enterprise pricing is custom to your needs. If you don’t want to pay per message, you have to go with Botpress. Generally speaking, industry research indicates chatbots are usually quite profitable projects, and we expect all pricing models to reflect that.
Think Botpress might work for you? Our sales team would love to talk to you and figure out your needs for your next project. You can also try out Botpress yourself, as it’s Open Source.
Botpress made two big releases this month — read on to learn more!
A detailed comparison of Dialogflow ES, Dialogflow CX and Botpress, with screenshots. Part one!
Chatbots are increasingly being incorporated into businesses and fast becoming the future of the Internet.