The Undocumented Hardships of Developing Chatbots for Facebook and why you should still do it

There’s a huge, mostly unfulfilled hype around Chatbots right now. Chatbot evangelists tell false stories about fully automated general AIs, capable of handling complex conversations by themselves, rising the expectations of both the users and investors even higher. We were told that solutions are right around the corner, and we’ve almost figured out language with LSTM recurrent neural networks. Even though the development of conversational intelligence has a mass market appeal, reality proves that it is still in a trial-and-error phase. Recently, big players like Facebook had to change directions with its Messenger Chatbot Platform after admitting that current Chatbots have hit a general 70% failure rate.

Without risking to state the obvious, I firmly believe that Chatbots do have their place and use-cases! In fact, we will see more human-like interactions in UI, GUI and games (especially in immerse VR games) in the future. There are also some strong arguments about the usefulness of automated conversations on Messaging platforms:

I’ve recently came across Startup Safary’s Bot that gave me information about the date and location of the events and presentations I’ve registered to. This was way more convenient than downloading a PDF containing my timetable in Gmail and looking through the list every time, having to type every single location to Google Maps myself. This is indeed a narrow use-case, but it really worked. No wonder why Facebook is now trying to rethink chatbots and turn them into something similar to apps with menus. I’m seriously looking forward for Festival Chatbots, that would provide more information about my favorite band, and nearby concerts.

So just because someone in marketing tells you your company needs a chatbot, because everyone else’s doing it, don’t do it, spend your resources on something more useful. But if you wanted to do a simple App or website that gives your users some basic, but useful information, or lets them search for something in your database, go ahead and make one. There aren’t many well-known chatbots in Messenger right now, so your company could be the first to implement something really basic in this field, which could translate as free advertisement for your product.

If you have an idea you want to test, do a prototype first. There are plenty of free and easy to use Apps out there that let you click a chatbot together without any coding. If you and your peers find it useful, go and develop your own chatbot — once you need any kind of special functionality, it is much easier to code your own in the long run, than somehow hacking your desired functionality into existing interfaces.

Writing your own bot

So you have an idea for a killer chatbot, made sure it is possible to implement it with the current technology, made a working prototype that people got engaged with and you’ve decided to write your very own, so you can expand its feature set. You are also absolutely certain that having a chatbot is a better choice for your case than writing a native App or a Facebook application. Good.

First, you should take into consideration, that (at least at the moment) only a limited amount of information is available from the user’s profile’s (name, gender, timezone and language on Facebook). User id’s are also unique for apps or pages (although these two will most likely be merged in the future). These restrictions are understandable, but make it harder to give users a personalized experience or connecting the user’s id with other sources. Receiving geolocation is also an issue, as the users have to send their current location manually to the chatbot.

Secondly, there is no guarantee that Facebook Messenger will remain the most influential instant messaging platform in the future. Neither there is a guarantee that Facebook’s API calls would remain the same and changes in the API won’t crash or disable some functionalities of your Chatbot. For this reason I strongly advise you to somewhat future-proof your Chatbot: separate the AI/workflow and the API calls.

Now if you have ever developed anything for Facebook using its API you might be familiar with the latter issue. Building your business on a platform that can suddenly change overnight, and having to allocate resources on keeping your software up-to-date with the current API all the time is quite exhausting and expensive. Want to start with some example code on GitHub or need an answer from StackOverflow? Hope that code still works and does what you want, otherwise good luck searching Google for up to date solutions, hoping the next one would be more compatible with the current API. The lack of documentation with contradicting solutions, the same variable names used for different reasons with different set of allowed values, automatically unsubscribing webhooks (this is fixed now), and the broken links in the documentation page will only make your descent into madness more exciting. Sounds fun? Now imagine a platform where some data is created on a distant server, either by the server or by a user, then this data is sent to your server, where you run some script, send it back to the server and most of the times to the user who was also involved with the process. Let’s throw in some authentication, rights, user roles and slow server response time to the mix, and this whole process can go wrong on so many levels, that debugging will soon become one of your worst nightmares. There are a few things as challenging as figuring out the documentation through error responses — given that you have already made it far enough to actually receive and log those. If you can, use some existing middleware or library that masks the API calls from you so you only have to call their functions instead of manually building the response JSON objects.

Now if you still want to write your own Chatbot for Facebook here are some great ideas you can incorporate with your solution.

How to make your Chatbot likable

First, find ONE (or a really narrow set of) function(s) that your Chatbot will be used for. Before you want to do any kind of “AI” (be it something with actual machine learning model behind it or just a series of clever up parlor tricks) put the function first. The most important thing is that your Chatbot can do its task well with almost 100% accuracy. Once you have that, then, and only then you should start adding personality and small talk functions.

For example:

Getting the main function right is a hard task itself. However, if users are unsatisfied with the Chatbot’s basic functionality, no amount of additional cocktail party tricks will make them stick with your product.

In the other hand, if your Chatbot is indeed useful and users feel that they can safely rely on its functionality, adding anything more to it is an unexpected, 4th wall breaking extra. Users will love to find out about these extra functions during their conversations with the Chatbot. However, there’s a catch: the more reliable your bot is and the more small talk it can engage in, the more users will try to break it just to see how far they can go with your AI. No matter how hard you try, sooner or later, the Chatbot will misinterpret a message and the immersion is broken. So your goal is to keep up that magic as long possible.

Remember, functionality should always come first. Even if you want to add some funny remarks or images in response to the user’s request, send them after giving them the useful answer to their question. It could be tempting to make a cheeky AI from a cyberpunk movie, but there is a reason why no one ever uses UI’s from sci-fi movie dashboards as well.

Besides adding responses to common user interactions (such as saying thank you, greetings or good bye) you can use the following tricks to make your Chatbot’s AI appear smarter in conversations:

It is also worth noting, that users who want to talk to your Chatbot will also learn how they can communicate with it. They will slowly learn the available keywords and ignore areas your AI underperforms at. If they realise your Chatbot finds interpreting fluent human text hard, they will use keywords as if they were typing their request to Google. By reading the conversation logs, you can fine-tune your responses and add more functionality. However, if your Chatbot has failed to give the right answer to the user’s questions, she or he will most likely not ask that same question again, even if you have since fixed the problem and added the right response to it.

Just because you have released your Chatbot it doesn’t mean you are done: people will most likely engage with your Chatbot in ways you have not previously forseen and expect functions you haven’t realised people wanted. Keep updating your Chatbot and fine-tune it. Don’t be afraid of adding niche functions that only your most devoted users would be interested in, because they will love your Chatbot more if they get a smart answer to something they would have never anticipated. Just be sure to organize your code because the more functions you add later, the more chaotic and bug-ridden your code base will be.


If you are willing to put up (at least for the moment) with development hell, by following the aforementioned bullet points, you will most likely be able to write a Chatbot that people will love to engage with. Find a narrow domain you are familiar with and write your Chatbot in a way that it can successfully handle requests within that domain. Then add small talk functionality and improve on it. Chatbots do have their use-cases but it’s hard to get them right. However, if you manage to make one that users enjoy, you can expect a large buzz around your creation. Developing Chatbot AIs will give you a lot of experience in this field that you will definitely be able to use later on, when such interfaces will become more common.

Kitchen Budapest Stories

Collection of articles written by members and peers of Kitchen Budapest, the Open Innovation Lab of T-Systems Hungary. Articles about technology, innovation, digital literacy, DIY, research and education.

Nagyfi Richárd

Written by

R&D @ Kitchen Budapest + PhD @ ELTE, Hungary

Kitchen Budapest Stories

Collection of articles written by members and peers of Kitchen Budapest, the Open Innovation Lab of T-Systems Hungary. Articles about technology, innovation, digital literacy, DIY, research and education.