By Matt Lacey,
Matt is a Software developer with 13+ year experience and specialising in Mobile and .NET technologies.
Over the last few months there has been a massive growth in interest in creating chat bots.
Facebook Messenger currently has a reported 10,000 developers working on creating bots. Telegram, Line, Skype and Slack are also among those chat apps that have added bot support. Microsoft recently announced a Bot framework to make creating bots even easier and the likes of WeChat and QQ in China provide an indication of what is possible with such integrations.
There’s a lot of opportunity and interest in this area but chat bots are nothing new.
Over a decade ago I built a chat bot for MSN Messenger at the company I was at. The bot was fairly simple and wrapped the order lookup functionality that existed on the website.
The reason for building this was the same as the argument that is used now: To make it easier for a person to connect with the business using the technology they’re already using. If they already have a messenger window up on their PC, as was common among customers at the time, then having them launch a browser and go to our website was a bit of unnecessary friction we wanted to remove.
For the same reason I also built office extensions. If someone got an email about an order they wanted to look up, then they should be able to do it right there in Outlook. Or if working through a spreadsheet they could look up details without leaving Excel.
Natural language processing is seen as the complicated part of the process and at the time there weren’t the public APIs that are available now, but in the above example we found this to not be a big issue. Because the bot was highly focused it basically only did one thing: search for orders based on an order code. Occasional and first time users were more inclined to format their requests as actual sentences.
“What is the status of order number 123-A-4567?”
Frequent users soon grew tired of this (as did I when testing) and the need to process simplified input quickly became apparent. While the processing of full sentence requests was novel it didn’t correspond with the reason for building the bot in the first place. There was no benefit in saving a few clicks and launching a webpage and then asking them to type what were basically unnecessary words. The fact the bot was looking for a specially formatted order number meant we were able to use a simple regular expression to identify if the request contained this. We then added some extra analysis on the rest of the input for a few key words that might require a non-standard response.
As an introduction to creating a bot and handling free text input it was a great experience. There wasn’t a need to learn the full complexities of natural language processing and we were able to focus on delivering value to our customers. If you’re considering creating your first bot, I would heartily recommend starting with something very simple that allows you to focus on delivering value and understanding how your customers want to interact with your bot. There will be time to add more advanced functionality in the future.
Five years after working on the MSN search bot I had another opportunity to build a natural language driven system. This one was far more advanced and there were more than a dozen different tasks that the system could perform. At its simplest level there were handlers for each task that the system might be being asked to perform. When a request was received the request went through some standard manipulation such as formatting, stemming and removing stop words. The request was then simultaneously passed to each handler and asked for the handler’s confidence in being able to process it. The handler with the highest reported confidence was then asked to fulfil the request. There was also some handling for scenarios where no handlers had a high confidence or multiple handlers had equal confidence.
This modular approach to handling requests was easily extensible but also, again, avoided the need to have a deep understanding of the complexities of a centralized text parser and processor. This handler approach also enabled easy ways to vary the complexity of understanding different requests. The simplest handlers would just look for specific keywords or regular expressions. The more complex ones could maintain context between requests and do more complex analysis of the input.
The tools and processing functionality now available through artificial intelligence (AI) and machine learning (ML) mean that the analysis of complex input is easier and a practical possibility for many more developers. On the other hand, the above handler approach shows that AI & ML based techniques aren’t always necessary. If you’re just starting out with natural language based processing but are working with a system where there isn’t a simple single task that could provide value (like searching for an order number) but don’t want or need the complexities of something that could handle potentially any input, this could be a useful middle ground. This handler technique has also been popular with developers who want a solid understanding of exactly what is happening with their code and want to be able to make immediate modifications should the needs arise, rather than needing to retrain a ML algorithm.
Some people are predicting that bots will eventually replace a lot of apps. There may be apps that do eventually go away and are replaced by a collection of bots but what this highlights is the importance of the underlying service or functionality that an app provides. In many cases the app is just a conduit to accessing a service. The value from apps comes from providing access to a service. If that access can be provided in a more suitable, alternate way then it makes sense that it should be. If your business model is based on creating the app then you might be concerned by this but it goes to show that the real value is providing a service people want to use and can be monetized.
If you’re an app developer and this prospect makes you nervous, take comfort in the knowledge that apps won’t go away any time soon. Consumers have spent most of the last decade being taught that apps are the way to access services on mobile devices.
Even consumers who are heavy users of the chat apps that are adding bot support aren’t likely to start abandoning all their other apps just yet. While the bot support we have today is more sophisticated than what I was working with in the past there is a long way to go before the apps that host the bots are able to offer all the functionality available to a full native app.
While a website can do a great deal, there are things that are currently only possible in a native app and this pays a large part in the popularity of apps over websites. Similarly, there are many things that can be done in a native app that just aren’t possible as a chat app. There are also whole classes of app that just don’t make sense as a chat bot.
Apps like QQ and WeChat may provide an indication of what is to come in the way of integrated chat bots (or other app extensions) in the future but even in the fast moving world of mobile app development we’re probably at least a couple of years away from seeing such a big shift towards integration in western markets.
Ultimately, bots provide a new way of connecting with and providing value to the people using our apps and services. This new opportunity should be embraced for the services and functionality where it makes sense. The growth in tools and opportunities makes it easier to perform some highly sophisticated tasks but this should not be an excuse for a simple solution if that can provide value to the people currently using the app.