artificial-intelligence-automation-bookcase-1329068

Building Customer Service Chatbots: Part 2 – What tools can we use?

In our previous blog post, we discussed how chatbot solutions are limited in what they provide. We also said that if you do build them correctly, they will perform, and perform they will. Before we go into how to build those good bots, let’s go over some different platforms in which we can do the building. We will explore several leading solutions, built by large tech giants and startups alike. One thing to keep in mind, though: this would be a limited list. In the past few years, a good number of solutions have emerged, and they vary in capabilities and cost structure.

The way we see it, the platforms should be evaluated according to several key areas:

  • Functional Scalability: how well the platform can scale for large bots with complex business specifications?
  • Development effort: for those real-life complex cases, what kind of development effort is needed?
  • Customer support fit: is the platform a good fit for building a customer facing bot?

Let’s start:

IBM Watson

IBM provides a very sophisticated chatbot solution. It has been used by some of the bigger players – from Harman Kardon to Vodafone. IBM is one of the pioneers in this field, and so, the Watson chatbot framework does have some nice feature in its bag. However, the editor it comes with uses an old paradigm, first-generation paradigm – table-based rule structured UI. If you are going to use this editor, then building a complex, multi-domain bot would be impossible. Thus, you’ll need to hire IBM-certified integrators (for example, LivePerson) to do the work. On the good side, it has a good NLU engine and even a limited context understanding. Context understanding is key to reduce the number of rules needed when designing a “smart chatbot” – more about it under the Servo section. When designing a chatbot with Watson, you will still need to invest a lot of work in training the NLU, building the chatbot logic flow and connect it to the correct database fields and custom code for more complex cases.

Google – Dialogflow

Dialogflow is built by API.AI, a startup company acquired by Google a few years ago. Its technology is now integrated and provided as part of Google’s services. From our perspective, Dialogflow is a very similar offering to IBM’s Watson, barring the context understanding: from our tests, it does not have the ability to easily jump between sub-conversations. Dialogeflow brings other benefits, though:

  • More compatibility with chat clients such as Facebook Messenger, Slack, Skype, and more
  • A great NLP/U. In fact, Dialogflow is primarily an NLU engine

Again, as Dialogflow is more than all an NLU engine, a customer experience manager in need for a chatbot, would need to get a development team building the bot’s logic and conversation flow.

Microsoft Bot Framework and LUIS

Microsoft chatbot framework appeals first of all for developers. A framework is a layer of code accelerating some of the development, allowing a less steep learning curve for the programmers and ultimately faster time to market. The framework is tightly coupled by Microsoft’s Language Understanding Intelligent System NLU engine (hey, I hope it’s ok to come up with a reasonable deciphering of LUIS). It also uses with their Azure cloud hosting, which actually is the whole point of Microsoft investing in this field: they want to lure developers and companies to use Azure hosting, which is one of their main revenue channels now. To companies already using Microsoft Azure, it’s great. LUIS core technology is very similar to Google’s and IBM, in which you will need to train the NLU, build the rules and connect to the right database fields and devices. However, their framework does provide a better scaffolding on which the developers can build the chatbot for you.

With all that being said, so far we have seen a set of tools that still rely significantly on developers. What about zero-coding platforms?

Manychat

manychat platform view

Manychat claim to fame, among other points, is by allowing anyone, not only developers, to create bots. “Building a bot is easy, fun, and proven to get results.” their slogan goes. Indeed, Manychat platform is very popular, especially for Facebook Messenger chatbots. It has a great graphical rule-engine flow editor, a dashboard with analytics and audience information, live chat interface and many great, intuitive-to-use features. Its main drawback stems from its dedication to Facebook Messenger. While being very suitable for marketing and social platform lead generation, this would not be a great choice for customer support. First, not every customer might have a Facebook account. Second, the interaction with the customer would need to be done under FB Messenger limitations and regulations: this means that if your customer has already logged into your site, the bot would know nothing about her, and could not make any decisions or recommendations based on her past conversations.

The other disadvantage is actually the zero-coding promise: for meaningful actions, the bot has to make decisions based on business logic. This means it has to look up in databases and documents, activate some API calls and see the user’s past actions. In Manychat the road for that is convoluted: you have to use external APIs and cannot build this as an integral part of the bot.

Still, Manychat presents a great tool, super useful for marketing purposes.

Chatfuel

Founded in 2015, Chatfuel is one of the pioneers in the chatbot field. Its offering is very similar to Manychat. It’s aiming to help to build chatbots with no-coding, has a nice rule sequence interface, analytics and more. It also suffers from the same problems: Facebook dedication, convoluted coding, and sales-and-marketing orientation.

Rasa

Rasa provides the leading open-source NLU solution in the market. As in Watson, Dialogflow and their kind, Rasa’s main strength is in its NLU. Rasa saw the future coming and collected together a bunch of NLU and NLP components, such as Spacy, NLTK, and others. Since then they have progressed to include more modern deep-learning-based components and in general, are keeping up respectably with their giant counterparts.

On the flow front, Rasa tried to add a new chatbot building paradigm, based on training: where the developer needs to supply the right answers to questions, without building a set of rules. This is called Rasa Core and it supposes to learn over time and ultimately give the expected answer. We’re still not sure if Rasa Core would live up to its promise, but even if it will, it’s not necessarily the best approach to build big chatbots. Chatbots are actually big applications, with a lot of state to handle. It is uncertain whether a new paradigm could replace years of well-tried engineering design patterns.

Servo

First things first, the author of this blog post is one of Servo’s founders. Servo was built to provide a low-code platform for creating industry-grade bots – bots that access data sources, has an elaborate set of business rules, and use modern engineering methodologies like source versioning, design patterns and more. It’s open-source, but has a best-of-breed flow editor, that implements Behaviour Trees, a state-machine paradigm that was originally built to create AI in games. That’s why its called ‘low code’ – you don’t have to code, but if you do, it’s not a lot.

It also boasts a flow debugger, a strong context engine, and hierarchical memory modeling. The developers can configure to use their favorite NLU engine – be it Rasa, Watson, Wit.ai or others. It can create multi-lingual bots for multi-platforms, such as Facebook Messenger and Alexa, all using the same behavior tree. It allows sub-processes, which is essential for building big, complex systems.

It’s not hard to see this is my favorite engine. With that, it also requires a dedicated developer(s) – less than the rest, perhaps, but still.

Summary

All in all, there are many solutions on the market that will provide a decent user experience, and you will need to choose the right platform based on your needs. Things to consider are:

  1. Cost – mainly for development and maintenance. Each platform brings its own pricing model (some free). Some can be very expensive when your chatbot usage grows and it is very unlikely that you’ll be able to move to a new platform and build it from scratch.
  2. Flexibility – check what connectivity you need and what platform brings good support for future integrations
  3. Functional Scalability – you will start from a simple chatbot but it will need to grow its skills in the future. Which platforms can handle complexity at best?
  4. Eco-system – If you are already using a platform such as Azure or Watson for your core business, staying at the same eco-system might save you cost.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin

Thank you for your interest

Please enter your Details

Bitnami