TL;DR Dialogflow’s UI is not the best to design more-or-less complex conversations. It has poor search capabilities across intents, as well as very limited functionality around managing “nested” dialogs (those which have in- and out- contexts).
Using only Dialogflow, it might be quite a “painful” experience. It makes sense to look into 3rd party conversation design tools which support API to extract the designed dialogs and import them into Dialogflow. One of such tools is App.Chatbot.
There are quite a lot of blog posts and publications in the Internet about how to build chat bots using Dialogflow platform. I am not going to repeat the basics here (terms like intents, entities, contexts, etc.).
Instead, I will share our experience in building the chat bot which supports quite a long conversation around any of supported topics.
Our Customer Services team decided to offload some work to the modern technology — AI, and with a small team of developers we started investigating how we can help there.
Based on some preliminary triaging, the choice of suitable platform to build the bot was made in favour of Dialogflow. Shortly, the main reasons to choose Dialogflow as a bot engine were — wide range of supported languages, reasonable price even for the Enterprise plan (Standard plan with 3 req/s is completely free!) and mature NLP support out of box.
.When we just started, as many other developers, we looked around and played with Dialogflow trying to understand its UI, concepts and specifics. We tried to build several simple conversations, using parameters, contexts and entities. Everything looked simple and very promising…
Then the time came to start building real, longer conversations. Company hired a conversation designer — nice guy, he also has decent experience in script-writing for big name companies.
His task was to create conversations for our chatbot. Those conversations are supposed to simulate the FAQ and troubleshooting steps, that a live support person usually does: answering specific questions about cancellation or pausing the subscription, troubleshooting issues with sign-in and sign-up, authentication issues, or issues with playback, etc.
Our conversation designer started building the conversations. As appeared in practice, Dialogflow’s UI is not the best tool for designing (wire-framing) of dialogs for a chatbot. As such, another platform was picked for these needs — https://app.chatbot.com
The web interface of App.Chatbot is quite an advanced one, and allows to prototype bots. Also it is possible to test the designed bot directly inside the platform, as well as to connect the bot to several popular social and messaging platforms (Facebook, Slack, and few others):
To help users get answers for their queries, our conversation designer decided to go on with an approach of “quick replies”, assuming users would click one of those offered buttons, instead of typing free text messages.
Obviously, clicking the “quick reply” button should not be the only way to interact with our bot. Users should be able to also type the answer, with the similar words as it is scripted for the “quick reply” button. For instance, when Bot replied with a choice of 3 quick reply subjects — “My account”, “Payment Issues” and “Sign up”, and user types in the answer “I have a problem with my payment”, then the bot should be able to categorise the reply as “Payment issues” and define the context respectively.
Looking at the picture above and the requirement around the support for freely typed text, it may lead you to a conclusion that we heavily rely on contexts while building our bot conversations.
Now, as I mentioned earlier, Dialogflow’s UI is not the best when it comes to designing, or even configuring complex, especially contextually linked, nested conversations.
There are several ways how developers (bot builders) usually structure their dialogs (or conversations), using the means provided by the platform (Dialogflow).
Option #1, is to mark related conversations with some text label prefix, e.g.: [PAYMENTS].
For a slice of the conversation from the screenshot above, that might look something like:
[MY ACCOUNT] Payment issues
[PAYMENTS] Payment payment
[PAYMENTS] Payment failed: sufficient funds
[PAYMENTS] Payment failed: countries match
[PAYMENTS] Payment failed: countries mismatch
Each line above represents one intent (which has many utterances inside). Dialogflow keeps everything in a flat structure. You can search only by intent name, not by utterance (“usersays”)…
Option #2, is to use the follow-up intents, using the Dialogflow’s feature to build nested conversation — when output context of the previous intent matches the input context of the next intent.
Dialogflow developers did some work to visualise such dependencies. But the nested tree is collapsed by default:
From the screenshots above you may see that it is pretty much impossible to find any nested intent unless you remember its name at least approximately (then one could use the Intent Search bar):
we would have to manually expand each and every intent and verify if search term matches part of the intent’s name (no highlight is built in, unfortunately). Not a scalable approach, honestly speaking.
In that sense, App.Chatbot is somewhat simpler to use, because we may click the “Expand all” (+) button and then use browser’s “Find” (Cmd+F) feature to search for a term and such term will be highlighted:
Since there is no out-of-the-box integration between App.Chatbot and Dialogflow, migrating manually all those intents and conversations would be super tedious, error prone and complicated. That would also require a ton of effort and attention from the people doing that job.
Fortunately, both App.Chatbot and Dialogflow have API which allows to export stories (from App.Chatbot), and programmatically import configured intents (into Dialogflow).
The only problem with API is of course, JSON schemas and concepts within each platform mismatch completely!..
After a close examination of the JSON document which we received in a response to the API call, we understood that it is still feasible and does not require a lot of effort to convert data exported from App.Chatbot into a Dialogflow’s JSON document (separate for each Intent).
As a result, we managed to connect 2 systems together: design conversations using the App.Chatbot, and use NLP capabilities from Dialogflow.
We periodically execute script and migrate conversations from one system into another, and never manually touch Intents imported into Dialogflow. For us source of truth, so far, is App.Chatbot.
How we retrain the model by adding new user utterances will become a topic for another publication.
Dialogflow is a great platform to start building chatbots. With its simple interface and advanced NLP engine, it is a piece of cake to build your own agent. Having talked to several people I realised, that not only developers can build bots, but even marketers and customer support people!
At the same time, once you start adding more and more conversations, and those conversations become more complex and start having a nested structure (linked via input and output contexts), Dialogflow’s UI turns into a hard to use one — from the point of overviewing a complete conversation, but also from the point of searching for a specific intent to add further modifications.
It makes sense to look into other options and solutions, which have more user- friendly interface to design and configure conversations.
One of such solutions is to use App.Chatbot platform, and integrate it with Dialogflow via API.
Many thanks to Darko Antic for his decent review and very nice suggestions.