Botpress v12 vs Dialogflow ES vs Dialogflow CX in 2022 [Part two]

This is the second part of the exhaustive Botpress vs Dialogflow comparison. For part one, click here.

Using Existing Integrations

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.

Dialogflow ES

Here are Dialogflow ES’s integrations from within the UI:

• Dialogflow Phone Gateway BETA
• Avaya
• SignalWire
• Voximplant
• AudioCodes
• Twilio
• Telephony
• Genesys Cloud
• Twilio
• Web Demo
• Dialogflow Messenger BETA
• Messenger from Facebook
• Workplace from Facebook BETA
• Slack
• Telegram
• LINE
• Kik
• Skype
• Spark
• Twilio IP Messaging
• Twilio (Text Messaging)
• Twitter
• Viber

That’s quite the list!

Adding Facebook Messenger gives you instructions, links to more information, information about the environment, and the proper tokens.

Dialogflow CX

Here are Dialogflow CX’s from within the UI:

• Avaya
• Voximplant
• AudioCodes
• Dialogflow Messenger
• Facebook Messenger
• LINE

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 v12

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:

• Website Embedding
• Converse API
• Facebook Messenger
• Telegram
• Microsoft Teams
• Twilio
• Slack
• Smooch (Sunshine Conversations)
• Vonage

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.

Comparison

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.

Visualizing entire conversations

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.

Dialogflow ES

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.

• One list to rule them all.

• If you want to control the flow of a conversation, you need to add an output context in your intent to control where the user is going.

• In the refund order intent, add the same context as an input. Do the same for every other option.

• In the intents list, you can click the add follow-up intent which creates an intent with default contexts. But how do you rearrange nested intents?

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

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.

• Each page is like a node and represents a place in a conversation. This page has a choice and two other buttons.

• Clicking a page like refund order opens it up and closes the other page. You can see the neighbouring pages.

• The visualizer shows one flow (a group of pages) at a time, and on the left hand side you can see all your pages.

• The start page is a good place to include all your functionality. Routes make a lot of sense in terms of what it means (sending users to different pages or flows).

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.

Botpress v12

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.

• This visual flow editor has no secrets. It shows everything that is going on. Every transition connects to another node.

• Creating and updating the logic that decides where a user is sent next is simple.

• When you click a node, the node inspector pops up with a title editor, and the three tabs.

• If the lines connecting nodes together get messy, you can split the flow into multiple flows. This will keep the amount of lines manageable.

• The intent & entities page is what you would expect.

• The integrated Q & A feature is fantastic. You can add contributors who don't need to see your whole conversation flow and have them contribute without breaking any other part of the conversation.

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.

‍Comparison‍

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.

Dialogflow ES

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.

• In the intent editor, there is a very convenient way to set “variables” (use entities), but no way to filter by it!

• You could use contexts for things that happen only once, but this doesn’t scale when we are talking about non-binary 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.

Dialogflow CX

Saving and reading bot memory is done via parameters.

• When creating your first route in Dialogflow CX, you will likely glean over this and see the word “Parameter”. Make sure to click the link to syntax reference, as parameters require special formatting.

• An example of greeting someone once per session without any code. Notice how the way to access the variable “greeted” is different from the way it’s saved.

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.

Botpress v12

Memory is accessed and set using “variables” in Botpress.

• In the node inspector, creating a new action will show this prompt.

• Selecting the Set Variable action in the “Execute code” option shows three text inputs. The type determines how long the variable should exist. The name is the name of your variable, and the value, whatever you want to assign.

• Once your variable is set, you can create a transition (a link to another node / flow) and set it as a condition like shown.

• Or like this when wanting to display it.

• Three lines of code from the code editor. Developers have access to all variable types, meaning they can read and update state directly. You can then invoke these in your flow.

1 of 5

Comparison

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.

Pricing

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 ES

https://cloud.google.com/dialogflow/pricing#es-agent

Dialogflow CX

https://cloud.google.com/dialogflow/pricing#cx-agent-2021-09

Botpress

https://botpress.com/pricing

Comparison

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.

Conclusion

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.