What I Wish I Had Known from Start About Developing Chatbots

Erik runs a chatbot development agency. They provide chatbot solutions to large companies, particularly in the customer service and marketing space.

Erik told me on the one hand business is going very well because the conversion rate on pitches for chatbots is extremely high. This perhaps reflects the fact that he is one of the first to market in this space.

At the same time, he was struggling to find the right tools for building quality chatbots efficiently.

When he first discovered the no-code platforms such as Chatfuel and Motion.ai he was optimistic that these tools would solve his problem. While he found that they worked well for prototyping the bots, he quickly ran into problems.

Many bots needed to be customized in ways that could only be represented in code, and these platforms didn’t support coding. Some bots need to be integrated with his client’s legacy systems, and again this was not possible.

Just these problems alone were deal breakers, but even if they could be solved, he still wasn’t comfortable with all the logic and data residing on a third-party system which he had no control over. His clients often insisted on hosting the bot themselves for security reasons.

He therefore decided to get the bots coded from scratch using Microsoft Bot Framework and where possible to use developers in low cost countries. Doing this predictability created other issues.

Although he now had ownership of the code and data and could customize the bot to the degree required, the results were mixed.

He rapidly realized that all the bots had many features in common, such as role based security, subscriptions, broadcasting, human in the loop, but these features were being coded from scratch by the developers which unnecessarily increased the development time and ate into his profit margins.

The development risks were also unnecessarily high because different developers were coding the features in different ways and the overall architecture evolved in an ad hoc fashion. Some developers had recognized this problem and started to create reusable libraries for common features, but these libraries were hardly the high quality libraries that he would want to build his business on. They presented their own risks and unwanted dependencies, especially when functionality needed was complex. It was difficult for him to verify the quality, let alone give his clients confidence that everything that was built was of a sufficiently high standard.

He briefly considered the idea of building his own platform but that seemed like an overkill. Doing this would create unnecessary development and maintenance costs as well as potentially sales issues if market standard frameworks that clients would prefer emerged, which he believed would happen. It was just a matter of time.

In his mind the problem was similar to the problem that web developers faced at the dawn of the internet. At that time there were no content management tools such as Wordpress, so the websites needed to be coded from scratch every time. This created the same problems of increased development costs and variable quality in code and output that he was facing now when creating bots.

When Erik found Botpress.io online it didn’t take him long to recognize that Botpress offered a potential solution to his problems. He liked the modular architecture in theory and it made sense to him to build an equivalent of a CMS for bots. It was what he believed was needed. It could be the missing piece in the puzzle, but he needed some questions answered first.

Firstly he needed to be sure that the solution was robust, secure and reliable.

Secondly, he needed to make sure that all common critical features that he had identified as being required were available via the framework

Thirdly he needed to make sure that the economics would work for his agency.

Being a hands on and technical person himself he decided to personally validate the first two questions by actually testing the system. He joined the Botpress community and worked through some of the video tutorials using the open source version.

The fact that there was already a large and active community of developers using the software meant that it was battle tested which was a good thing.

He was initially concerned that Botpress was open source which his clients may see (rightly in many cases) as being a security risk. He however found out that Botpress had a curated enterprise version that was maintained separately to the open source version specifically to address the security issues.

Of course the open source version offered some advantages in that it was free to use and in many cases ideal for developing bots outside of the enterprise use case. It meant that the components and approach were heavily used and validated by many different developers.

Many of his clients demanded that they host the chatbot on-premises and that they control the data for security and commercial reasons and Botpress supported this. In addition, Botpress allowed for full customization of the code and integration with internal systems which was the original problem he had with the “no-code” platforms.

Most of the features he wanted were available. These included role based security, multi-user management and user interfaces for managing the bots post-deployment. He could easily add what was missing as a module.

In fact the modular architecture and the graphical interfaces to the system made ae very easy to understand where everything slotted in. This meant that even if he switched to new developers halfway through a project or someone had to pick up the code after a long interval it wouldn’t take long for the relevant person to get up to speed. So far so good.

The economics question was obviously also important. Would using Botpress reduce his overall development costs? Profit margins were tight. His expectation was that using a framework like Botpress would reduce development costs and at the same time increase quality and features.

It turned out that his expectations were correct. The cost of running Botpress was a small fraction of the cost of building even some of the features himself and the quality was better than a proprietary solution.

The hidden benefit of the framework approach was that he would be able to spend more time on the chatbot UI and functionality and thereby could significantly improve the end customer experience.

He had observed that many of the chatbots in the market were not that good. It could even be said that as an industry the chatbot makers were failing their customers.

It could be argued that this is because companies were not prepared to allocate reasonable funds to developing chatbots because they were unsure of the results.

Another argument is that the development process for chatbots has been very inefficient to date because chatbot makers have not had efficient tools to develop chatbots and therefore much of the development cost was focussed on what is essentially infrastructure.

The emergence of frameworks like Botpress had the potential to massively improve the quality of chatbots as more development budget is spent on user experience.

For the record, Erik is not an actual person but a composite of some of the agency owners who have contacted us with their issues, requirements, and interest in what chatbots can do. In various ways they shared their version of “What I wished I known at the start about developing chatbots for my clients”.

If we could summarize the main issues they would be:

• Building great chatbots requires access to the code and data.
• Developers need to customize the business logic and integrate with internal systems. It’s not possible to create great chatbots without developers.
• Many enterprise clients have security concerns and therefore want to run their chatbot on premises. The also want the same role based security and user management that would expect from any software that they use.
• The framework that an agency chooses should provide a wide range of common features out of the box.
• It doesn’t make sense for any agency (or dev shop) to build their own chatbot framework for their internal use anymore than it makes sense for them to build their own databases from scratch. Not only would that be uneconomic and generate large maintenance costs, but their customers would likely prefer that they use established, well understood infrastructure products that are built for purpose rather than try to build non-core infrastructure themselves.
• The industry is in need of frameworks so that more development dollars can go towards user experience rather than infrastructure.