A model for chat and messaging bot discoverability in the enterprise

Chat and messaging bot design is still in it’s infancy, but a widely adopted principle is that bots should have a very focused application.

Make it quick and easy to accomplish a task, and limit the opportunities for users to get lost or reach conversational dead ends.

This is generally a good principle to follow, however it presents some challenges to organisations who have a range of applications they want to provide a bot interface to. For instance, how do users discover bots? How can information be shared between bots to minimise repetitive data capture? One way to address this is through a ‘god bot’ such as Google Assistant, Alexa, Siri, and Cortana. God-bots have a broad range of capabilities and are typically considered Channels in their own right. They may provide a way for third parties to extend this capability set using custom Skills. At present these extensions only support the limited command-and-control pattern. This is great for checking the weather, or finding somewhere to eat, but any applications that require storing conversational state will be limited. Monolithic or discrete composition? So, if it is agreed that chatbots should be focused applications then does that mean we have to accept the limitations of these focused applications? Or, does it mean that there needs to be a shift to god-bots, accepting the limitations of command-and-control? If we take an example of a local council, an organisation that offers a wide range of services, and needs to support those services. How can these wide ranging services be supported while still being convenient to users? One of the ideas we are currently exploring is the idea of a discovery bot, which is responsible for directing users to the application of their choice. The first time a user engages with the council with an enquiry, for example a ‘Blue Badge’ enquiry, the discovery bot can use menus or Natural Language Processing (NLP) to understand the users intent, before redirecting the user to the appropriate target bot.

Users are aware of which service they are talking with at all points, if the chat needs to be continued or restarted, the user will appreciate being able to go straight to that chat bot without having to navigate and rediscover.

How does this work? I’ve tried to show in the following diagram the principle of discovering a single bot, but this model scales well to any number of bots. Support for this model is channel dependent. Basically, if a channel supports navigating to a chat bot through a URL, then the model can be implemented on that channel. Facebook Messengers m.me links are a great example of this. They make it even easier by letting you share context using parameterised m.me links. In a later post I will share the technical detail explaining how this can be done. Thanks for reading!