Home / DialogFlow / Messenger Bots / Chatbot makes $3 million in sales in 1 hour
DialogFlow | Messenger Bots

Chatbot makes $3 million in sales in 1 hour

This was the topic of a recent interview on the Mixergy podcast.

But was it actually a chatbot?

Initially, I got a little annoyed after listening to the interview.

A few things became clear to me immediately:

  • this was for a heavily promoted event involving some well known internet celebrities, meaning the sales may have been just as good even if they had sold those products without using chatbots
  • the 1 hour window was due to opening up the shopping cart even as a live YouTube event was happening
  • they were talking about not just Facebook push notifications, but rather combining it with the mobile wallet to get a lot of responses. Plus a complicated/sophisticated backend system that required significant development effort.
  • the bot didn’t understand a word of whatever messages the users sent it. It was basically an autoresponder sequence where there was a “default answer” (similar to the default fallback intent in Dialogflow) which linked to the live event’s URL

My first thought was: why are you calling an auto-responder sequence a chatbot?

Then I realized something else: there is a lot that NLU based bots can learn from the world of rules-based bots. Whether or not the nomenclature is right, you cannot argue with results.

The $3 million chatbot is probably as unintelligent as it gets when it comes to chatbots (its true), but people actually used it. Which is more than what can be said about a lot of NLU bots people are building today.

It does seem like NLU based bot builders end up with much poorer quality bots because they want to go all in on the NLU instead of providing useful solutions for their end users.

So here is a list that I can think of based on my experience building Dialogflow bots. In my view, by not taking these things into consideration, the NLU bot builders are actually making it harder on themselves.

What NLU bots can learn from rules-based bots

Yes, this should have been the actual title. But for some reason the current title seemed a little less sleep-inducing 😉

1 Constrain the input

It is perfectly alright to not let the user type a message when they only need to press a button. Don’t enable both typing and buttons.

(See “Design Matters” below).

2 Add rich controls…

People often ask me how to make sure you get the proper date and time input in Dialogflow. Well, if you could use a calendar control, this problem is solved quite easily!

There is no calendar control in most of the messaging apps (and I hope this changes soon), but see how easy it is to schedule appointments in web-based live chat widgets like Drift and Intercom. Surely, the world of NLU bots can learn a thing or two from that.

3 …  and actually make use of them

For example, I talk about something called the “Fallback to Select” pattern in one of my courses. The idea is that you ask the user to type out an answer, but if the number of choices are limited, then just show them some buttons so you can move forward with the conversation in case their first try fails. Don’t try and add a ton of training phrases (some of which don’t even belong) just to handle such a use case.

4 If all you have is slot filling, everything looks like a required parameter

Yes, just stop using slot filling. It may be a great concept, but it is still not a well implemented feature.

Instead, get a sequence of inputs by setting your own input and output contexts, and use rich controls to augment this process. (Remember that you cannot even use rich controls within the slot filling feature at the moment).

5 Create a flow diagram…

Before you create your Dialogflow bot, first create the conversation flow diagram using tools like XMind and Mindomo.

It not only makes it easier to think through what you are building, it even makes it easier to build your bot.

The greatest advantage of rules based bots is that they have visual flow builders. Using a good mind-mapping tool is probably the closest thing to a visual chatbot builder for Dialogflow at the moment.

6 …. but don’t use cross-bot-framework visual builders

In case that term didn’t make sense, here is what happened. I recently learnt about some “visual chatbot builder” tools for Dialogflow (which I don’t wish to name, but they are the most popular ones out there). The problem is, these chatbot builders use the absolute least common denominator approach and try to build bots which work on all bot frameworks – Dialogflow, Lex, LUIS, Watson, RASA etc.

This is a really bad idea, because there is a lot of difference between these bot frameworks. As a result, you end up not utilizing the best features of any of the frameworks (not to mention – because they are so unfocused, the visual builders are not very intuitive to use either).

So don’t worry about building a cross bot framework bot. Focus on getting something working on a single bot framework first.

7 Actually have a defined end to the conversation

This might seem like a strange addition to this list, but you can easily see the problem when you don’t have this feature. Have a defined end to the conversation, and make sure you indicate that visually.

Even better, simply disable input.

When you don’t explicitly indicate that the conversation has ended, the user isn’t going to know what to do. This ends up with either

a) a bot that looks stupid or

b) a lot more intent design work on your plate.

8 Don’t try to handle corner cases (especially during the prototype phase)

Rules based bots don’t care about corner cases. 🙂

You can get some inspiration from that.

When you build out your bot prototype, you need a lot of mental discipline to ignore the corner case messages (especially the abusive ones).

But if you don’t ignore the corner cases, you will waste a lot of time creating intents which you don’t even need.

You can handle corner cases when your bot becomes so popular that even the corner cases add up to a really significant number.

9 Design matters

This is quite obvious, and I realized how important it is when I created my first rich website bots. All of them looked ugly. In my defense, I was only trying to teach people how to build the website integration! 🙂

Then I added better looking “dumb” website bots to my website by using an external service (I will be writing an article on this topic soon).

Not too surprisingly, there were a lot more interactions on the “dumb” but well-designed bots (even though they came with appropriate disclaimers).

Also, did you notice that there is absolutely nothing else you can do other than click on the button if you want to move forward in the conversation? (point #1).

10 Reduce cognitive load

That’s just a very fancy way of saying “Don’t make the user think”.

For example, when the conversation ends, my website chatbot gives you an excellent visual indication – you don’t even have any way to interact with the bot because the input textbox becomes invisible.

11 Allow easy conversation restart

And make the restart button obvious (always visible).

When you reach the end of the conversation, notice that the ONLY way you can interact with the chat window (see image above) is to click on the always visible Start Over button at the top right of the chat widget.


In summary, you should take a close look at all the elements which make rules based bots so effective and think of how you can incorporate them into your NLU bot.

Related Posts

  • Excellent post and advice.

    One of the things I am finding in the development of my ChatBot is it is much easier to create a good working bot when you can show valid responses for the user. When you have to rely solely on a Smart Speaker that doesn’t show the user suggestion chips it becomes a lot harder as the user can say anything which can cause your bot to go down the fallback intent path and then completely exit.

    Given that we’re in the early days of smart speakers I am wondering it is preferable to be explicit with users (when using a Smart Speaker) around what the valid responses are. This is where it would be nice is Google built in some A:B testing within DialogFlow.

    • >>it is preferable to be explicit with users (when using a Smart Speaker) around what the valid responses are.

      The concern with this approach (and Dialogflow does mention it in the docs) is that people will become very impatient if the bot speaks out all the possible choices. Unless you have a very small set of choices, it doesn’t help.

      Also remember that these are intended to be (or at least aspire to be) better than phone based IVR systems which were found to be very annoying because they did provide explicit hints.

      In a way, that is also the answer to “Wait, why don’t you just tell (show) them all the possible responses in the first place instead of trying to understand what the user says (types)?” 🙂 I think that is why a hybrid NLU + rules-based approach would be better.