My personal bot, BotDunc, has had an interesting birth. As I mentioned in my previous post, my approach has been to launch early and iterate quickly. BotDunc is all about learning real bot-lessons, not about creating a perfect bot.

Encourage users to have a conversation your bot is qualified for

It’s important to set some expectations with your users about what your bot’s purpose is. When I first launched BotDunc, it was just positioned as “my personal bot”. However, it’s pretty hard for a user to know what that means — not many of us have interacted with a personal bot before. As a result, BotDunc got some pretty random questions at the start.

I quickly iterated my bot so that it now sets users expectations by providing a clear explanation of its capabilities when people first start chatting with it. I also exploited “buttons” that encourage users down successful conversational paths. These two actions helped to gently encourage BotDunc’s users into a more sensible conversation.

But it still struck me that BotDunc has a bit rudderless — what is it really for.

BotDunc learns about cuisine

Whilst thinking about how I might give BotDunc more of a purpose in life, I hit on an interesting idea — what if BotDunc could make suggestions to colleagues for places to lunch near our office? Pret or Eat? Surely BotDunc could manage that one? And it might be quite handy — my team might even use it!

So, I set about building a restaurant recommendation service within BotDunc. It’s a peculiar feature of a bot that you can pivot its purpose without making any changes to the user interface. In BotDunc’s case the interface is Facebook Messenger and Twitter, so I couldn’t change it even if I wanted to.

To make my restaurant service I decided to curate a small database of local eateries near to our office. I could put these details into a Bluemix-hosted Cloudant database. Then, I just needed to setup a dialog to collect some basic details (what type of food, etc, is the user looking for), issue a query to Cloudant, and integrate the results back into my bot’s response. Simple!


The initial implementation of my restaurant search function quickly proved that I needed to be more ambitious. Simply providing a list of establishments was a bit restrictive — I really needed to have a feeling for their distance from the user’s location and to show a small list of the closest options. That required me to know where the user is located. I could ask them, but the likelihood of the user providing precise location details seemed quite remote.

It was at this stage that I noticed that Facebook Messenger has a button that pops up a map and allows the user to send their current location, or to select a point on the map and send that. This was perfect — once implemented, my users were now able to easily tell me where they were. BotDunc received a precise latitude/longitude, meaning I could use that to search for relevant nearby restaurant choices.

BotDunc uses the “Send Location” button in Messenger.

Geospacial indexes

Once I had my user’s location, I needed to find a way to use that to drive a location-based search. Did I need to get to grips with geo-spacial distance calculations? Luckily, it turned out there is an easier way — and that my choice of Cloudant as a database was an auspicious one.

If you store data in a Cloudant database in GeoJSON format, it’s a snap to add a geo-spacial index over it, which allows you to do location-based searches…that’s location-based searches without having to deal with the underlying maths — perfect!

Even more wonderful, a Cloudant geospatial index even allows interactive querying using a mapping dashboard, which is perfect for viewing and administering your geoJSON formatted data.

Administering geo-location data in the Cloudant Dashboard.


Just returning a list of restaurants to the user is only semi-useful. If you already know the establishments, fine. But most users will need a bit more information to make a decision. So, I extended BotDunc to help the user make a decision:

  • A photograph (I nipped out at lunch-time to take some quick snaps of local restaurants with my iPhone) of the establishment helps to give a better clue of its nature.
  • A button that launches a mapping app to show the restaurant’s precise location and aid navigation.
  • A button that launches a browser for the restaurant’s website.

Now my restaurant search was beginning to get quite useful — and quite a bit more sophisticated than just a textual conversation. Photographs, buttons, launching external apps. BotDunc was beginning to hit the big time!

BotDunc providing an interactive restaurant selection.


I don’t know about you, but for me one of the most critical aspects of choosing a restaurant is its menu. My amateur photography was providing the bot equivalent of an external view of the restaurant. It was now time to see if my bot could support the next step we take in the physical world — to read the menu.

I discovered that there are some services that provide syndication of restaurant menus (Single Platform, Locu) — it’s how Google, Foursquare, etc, provide menus. With a judicious bit of tinkering I managed to drive one of these to provide a menu in response to a click of a button in BotDunc. Now users can see a photograph, visit the website, launch maps for navigation and read the menu. That feels like a quite comprehensive set of functions that should be useful to BotDunc’s users.

BotDunc pops up a menu over the conversation.

Collecting suggestions

Flush from my success in building a location-based restaurant search, I thought I’d give my colleagues the possibility to make suggestions for restaurants they’d like me to add to my database. Users can can say something like “I found a great new restaurant” to BotDunc and he’ll guide them through the process of collecting some basic information. I store this information in the Watson Conversation “context object” during the conversation’s flow, inserting it into a Cloudant database for manual curation once everything has been collected from the user. I guess you could say that this makes BotDunc a “conversational transactional system”. On second thoughts that sounds like a bit of a mounthful — lets stick with #ConvComm.


In my quest to give BotDunc a better purpose, I’ve ended up stretching the conversational paradigm quite significantly. Although the conversation drives the experience, it’s not sufficient to build a really compelling experience — buttons, carousels, geo-location, web and app integration — all of these features came together to build a kind of “mini app” within Messenger.

Unfortunately, in the process I’ve lost some of the multi-platform abilities I’d originally planned for. Although BotDunc exists within Twitter as well as Facebook Messenger, Twitter’s more basic capabilities preclude the functionality described here. As a result, the Messenger version is “BotDunc on steroids”, with the Twitter version being decidedly less capable. That’s unfortunate, but does emphasise the tensions in this still maturing marketplace. It also mirrors multi-platform experiences elsewhere — the industry is littered with failed attempts to provide a single development technology across platforms. It seems that #ConvComm is destined to follow that trend.

Conversational Commerce may be great, but when we use it as a launching-off point for other capabilities, it becomes really powerful. By thinking about the user’s problem (finding somewhere to eat) rather than the technology (Watson) I was able to pull together a variety of services and technologies to create something (hopefully) useful.

Watson is the heart and sole of the BotDunc, but by no means the entirety of the solution. My suggestion to other bot authors is to stretch the bounds of what is possible in a bot — branching out from basic natural language processing gives you so many more possibilities.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store