In a previous article, we wrote about tools for conversation design. This new post is about the different tools you can use to develop the conversation. There are many tools in the market but there are two we usually recommend: Chatfuel and Dialogflow. Which tech stack to use is one of the most sensitive decisions teams must make during the conversational development lifecycle, and vendor lock-in one of the most common concerns. For this reason, the last section of this article is dedicated to these topics. We hope you will find it useful.
Dialogflow is Google’s tool to create conversational experiences. Previously API.ai, Dialogflow offers NLP and can be integrated with different channels. With Dialogflow you can build and deploy a conversational agent in Actions on Google, in a different channel like Slack, or use it as an NLP API for a chatbot you built in a different tool (learn how we did it at bots4health in this post).
You can also integrate Dialogflow agents with other applications using Firebase or Webhooks, which makes it a perfect tool if your conversational interface needs to execute business logic or retrieve business information.
In Dialogflow you can define a series of intents (things users want from your bot, for example “book a taxi”) that are related to expressions (such as “I need a taxi” or “Please pick me up at Rosebud St at 10:30”) in a one-to-many relationship. Inside of the different expressions, there are entities that collect information from the users and that you can apply in the logic. For example, in the expression “Please pick me up at xyz street at 10:30 tomorrow” Dialogflow resolves two entities:
Location: Rosebud St Time: 10:30am
Dialogflow provides a graphic environment, but intents and entities can also be managed from a development console as JSON files. In the Dialogflow dashboard, you can also train your agent. You can do so by looking at the input from users the agent could not process, and matching it to existing or new intents or highlighting entities that were not automatically discovered. Dialogflow also provides basic analytics and can be integrated with other analytics providers.
Chatfuel is great for proofs of concept or button-based bots as it has one-click integration with Facebook Messenger. It has an easy to use interface that non-technical people can use with very little training.
In chatfuel, you can design the conversation flow using visual blocks and sections, and you can add some basic understanding of common expressions. There is a free plan that has limited features and shows a chatfuel ad to users at the beginning of the conversation. If you need more or don’t want your users to see the chatfuel branding, subscribe to their premium plan. It gives access to a useful “CRM” with .csv data export and lets users take over conversations directly from Chatfuel. Chatfuel has basic analytics and can be integrated with other analytics providers. Chatfuel comes with limitations: You can only use it to create chatbots for Facebook Messenger and the friction to change to another tool is very high.
Tech stack selection
Chatfuel and Dialogflow are just two of the many tools to create conversational interfaces you can find in the market today. Most have comparable features and similar user experiences, and different organizations will find different tools more aligned with their needs and believes.
There are a number of things to consider while selecting a conversational tech stack. Based on our experience we have developed a template to assist in this task. The Conversational Canvas helps us make sure we collect all of the information we need to make an informed decision and recommend a suitable tech stack for our conversational projects:
- What are the channels for communication with the chatbot?
- Does the project require integrations with other systems?
- Is the navigation based in buttons or keywords, or in natural language?
- How many languages will the chatbot speak?
Other parameters that play a role in the decision are not as technical. Some of our clients have partnerships, existing projects or better relationships with organizations that provide a certain NLP solution. For Microsoft-based organizations, it may make more sense to use Microsoft Bot Framework and LUIS than a Google product such as Dialogflow. A lot of companies have partnerships with IBM and want to use Watson. As long as features are comparable, we’re usually happy to work with whatever solutions our customers prefer.
How to avoid vendor lock-in?
Vendor lockin is one of the most common concerns while defining conversational architectures. At The Neon Project, we mitigate vendor lock-in in two ways. First, by developing the conversational logic in a standalone infrastructure when it is a core part of the business model, In addition, by continuously exploring new NLP solutions. Most 3rd party NLP providers, like Dialogflow, use JSON to define models, so it’s relatively easy to reuse data in different services, and the performance of different solutions is overall comparable. Making integrations with different NLP providers easier is a priority for us. For this reason, we have programmed a conversational proxy. This proxy lets us change the NLP of a conversational agent from one provider or model to another with just one change in the integration parameters. You can learn more about our approach to conversational projects in this post.