I have already written an article about how you need a developer for creating a reasonably useful Dialogflow chatbot. In my previous article, I mentioned some high-level reasons why a coder would be very useful when building a Dialogflow bot. In this article, I get more specific.
Here are some questions people asked me recently. All of these are normal questions you will face when building a bot. In other words, you will run into at least one of these questions when you create your own bot.
How exactly does Dialogflow know what intent to match each request to?
This is what someone asked me in the comments section of my YouTube channel.
The answer is: only the Google (Dialogflow team) employees know. 🙂
Dialogflow is not open source. We cannot take a look under the hood and figure this out for ourselves.
But does this mean we should just assume there isn’t any way to understand what is happening and just do whatever we can and then pray that somehow everything works?
No, there is still some logic and there are some systematic ways to analyze what is going on. In my Dialogflow Conversation Design course, there is a chapter called “Dissecting Intent Mapping” which helps you understand this much better.
If you had a coder on your team, they would be able to use the knowledge from that chapter and help you build tools which can answer the question. Or at least make it less of a black box. 🙂
Many people have asked me (and on forums) how to handle regex in Dialogflow entities.
You might know that Dialogflow doesn’t support entities which can be defined as regular expression patterns (as of this writing, March 2019). I wrote an article which provides a suggestion to get around this limitation, but my suggestion requires that you write a custom integration.
Which means you need a coder in your team.
There some outright “missing features” of Dialogflow which you can only get around by writing code.
A client recently asked me: “How do I download the conversation logs?”
There is no way to get conversation logs in an easy to parse format (such as CSV) in Dialogflow. You need to write code to do this.
Another client asked me: “How do I actually measure the accuracy of my Dialogflow chatbot?”
Again, there is no simple way to measure the accuracy of your Dialogflow bot. You need to write code to do that too. (In theory, you can use Chatbase, but that also requires coding as of this writing, plus Chatbase isn’t the complete answer to that question.)
A client recently mentioned in a contact form that he chose Dialogflow because it is a low-code platform. While it may be the “lowest-code” of all the “NLU-powered” bot frameworks, Dialogflow isn’t actually low code in my view.
I suppose the primary reason for this is that unlike other low-code platforms, bot frameworks are still a work in progress with many open questions around fundamental features. (For example, slot filling is a great concept, but a very poorly implemented feature across many bot frameworks).
When you don’t have a lot of “commoditization” of the basic feature set, I am not sure you can build low-code platforms on top of that.
For example, CRUD (create, read, update and delete – the basic database operations) operations which display data in some line-of-business applications in your intranet portal is a pretty commoditized feature set – there are only so many ways you can implement these things, so it has been possible to make them as “push-button” as possible. Generally, that is what these successful low-code platforms do – reduce the amount of code that end users (business people) need to write for a well understood and fairly commoditized feature set.
I don’t think bot frameworks are quite at that stage yet.