Botpress vs Dialogflow ES vs Dialogflow CX

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 v12

• 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 v12

• 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 v12

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.

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.