Open vs. Proprietary Solutions

Currently, the development of customer service chatbots is dominated by high priced specialists who often use proprietary technology to deliver solutions.

These solutions have the following main drawbacks:

• They lock in customers to proprietary solutions
• The customers don’t have access or have limited access to their own data or critical source code
• The customers cannot easily extend or customize the solutions without help from the vendor
• The solutions are often driven by black box technology which is hard to even experts to debug and control
• The solutions are expensive for what they are

There is no reason why things should be this way except for the fact that the chatbot market is relatively new (although not that new) and there is less information available for both chatbot creators and businesses about alternative solutions.

One thing is for sure though, the cost of these solutions will come down as more people discover that natural language processing (NLP) technology is widely available, is fairly easy to use for most developers and is priced competitively.

Even if the cost comes down, however, the other three drawbacks remain. These are drawbacks that Botpress aims to solve by democratizing chatbot development.

Our goal at Botpress is to make the creation of high quality, customized bots within reach of entry level developers and content creators, as well as to find ways in which advanced chatbot developers can maximize the value from their skills.

Botpress templates are being built on popular, well understood technologies (i.e. using the Botpress framework) which means the data and source code is open, it’s easy to find developers to work on your projects, and the templates are customizable and extensible.

Extensibility is so important because once a business has a basic customer service bot up and running they are suddenly going to realize all the opportunities this opens up for providing other engagement services to customers in an integrated way.

If the system is not open and extensible, and it’s not easy to find developers to work on it, they will not be able to add the functionality they need for a reasonable cost or even at all.

For example, imagine a company that sells tickets to concerts, creates a FAQ bot to answer simple repetitive questions and to escalate more difficult questions to customer agents. They then realize that some of the questions being asked relate to the availability of tickets to certain concerts which can’t be answered with a simple FAQ implementation. They therefore decide to integrate the bot with their ticketing system to get the answers.

The problem they have is whether they are able to do this or not, if they have bought a proprietary bot solution, they are highly reliant on the vendor to do this if it’s possible at all. And even if it’s possible, the cost of doing this will be much higher than for an open system, given they are a captive customer.

Another issue is that the work they do integrating their external system with the bot will only work with the vendor’s system. It cannot be easily switched out to work with another system, so the more work they do with that vendor, the more locked in they become.

And of course, the quality of the solution itself is highly dependent on the vendor’s proprietary solution, as they cannot access the best in class third party solutions but are restricted to the vendor’s solution.

This problem becomes even more acute when the ticketing company realises that they could actually sell tickets directly from the bot because they realize that this will require even more investment and the solution will suffer from all the same drawbacks discussed previously.

They therefore decide to redeploy the bot on an open framework at much expense and effort. This is because they realize now that these changes are just the beginning of what is possible for bots and ultimately the contact center and the services will be combined in an onmi-channel experience that needs to be open and extensible.