6 lessons from building my own chatbot

Bots have captured the business public’s eye. Facebook opened up its Messenger platform to bots in April, and, since then, over 11,000 bots have reportedly been published.

To understand the promise of the bot platform better, I decided to write one myself. Over the course of a month, I built a bot that allows a user to search for concerts and sports events in their city. Here are a few lessons I learned.

Lesson 1: Pick a platform that’s easy

When I first started, I had to consider which platform to build on. I knew Rails, but, from what I’d read, it’s not the preferred solution for real-time apps that interact with users. (That may have changed with the addition of Action Cable, which I haven’t tried yet.)

I needed a language that was good with real-time interactions. Go, while very robust, doesn’t have a large third-party ecosystem, so I dismissed that and settled on Node (which uses JavaScript). I soon discovered that while Node has a huge ecosystem, the flip side is that there is very little standard setup. A Node application is built on a number of helper libraries and programs, each of which must be configured. Figuring out the right combination for building a chatbot backend wasn’t obvious, and there wasn’t any boilerplate code available.

Lesson 2: Use a bot-as-a-service platform

One of the business patterns I’ve seen is that as soon as a new business model is widely adopted, several startups will come along to transform the business model backend into a software-as-a-service (or SaaS) offering. I started to hunt around and soon found some bot-as-a-service (BaaS) platforms, including Wit (part of Facebook), Reply.ai, Smooch.io, and Meya.ai.  After experimenting with several, I settled on Meya because of how easy it was to get started (free, with an online editor) and because of its support for Facebook Messenger.

Meya has abstracted all the bot operations into a simple markup language built off the idea of states (e.g., operations the bot or user does) and flows (e.g., collections of states that go from one to the next). The language allows the programmer to create easy-to-follow workflows built off a number of components corresponding to basic programming operations — such as outputting text, taking text input, and comparing a variable with a reference value.

Another key advantage of Meya’s platform is the ability to create custom components in the Python language for more advanced operations, typically passing information to an API.

Finally, Meya’s team has been very responsive on Slack and quick to add support for Facebook’s cards features. By making a good choice of a BaaS platform — instead of building it myself in Node — I was able to speed my development significantly,  thanks to the platform itself and the excellent support I received.

Lesson 3: Your platform dictates your distribution and your capabilities

Another significant advantage of a BaaS is wider distribution. The Meya team and other BaaS platforms have worked to ensure that their platforms integrate with the most widely used messaging platforms, like Facebook, Slack, Telegram, WhatsApp, and SMS.

Because there are so many different platforms, the end developer has a huge advantage over a built-from-scratch application, in that he can rapidly distribute across many channels without having to rework the code. Adding a new messaging integration in Meya is usually a straightforward process of registering a new app with the messaging service and plugging the API keys.

Your platform also dictates the extent of your bot’s capabilities. The various messaging platforms are competing with each other to offer bot makers new functionality, such as Facebook Cards and Buttons. More recently, Facebook has released new features, including prebuilt responses, login options, and persistent navigation.

Each of these new features generally requires a new type of API request. If you pick a BaaS to build your bot, make sure it supports the specific features of the messaging platform you want to support. A BaaS provides another benefit here since it generally offers you an abstraction (e.g., a button) and handles the integration with each platform (Buttons on Slack will behave differently from Buttons on Facebook, for example).

Lesson 4: Buttons beat A.I.

While there has been a huge interest in A.I. for bots, A.I. is not the reason people use bots. People use bots because messaging can often be a faster and simpler experience than navigating a new website or downloading yet another app. For the user, a bot means less time learning a new interface and less context switching — e.g., why leave Facebook to check your bank balance if you don’t have to?

So messaging is faster, but that doesn’t mean we should focus on A.I. While A.I. has made great strides in terms of understanding user intent, it still falls down on complex queries, and it requires a lot of typing on the part of the user. Here’s an example:

What times is the movie Mad Max playing on Thursday in San Francisco?

The user is doing the job of remembering and reiterating all of the context for the interaction, and then depending on the A.I. to interpret it correctly. This seems like a huge step backwards from standardized UX elements like buttons and other options on the screen.

As a rule of thumb, buttons are better than A.I. for most applications. Buttons have the advantage of being a much quicker option for users entering their selections and for providing unambiguous responses back to the application.

While predefined buttons clearly aren’t as expressive as any written language, they work great for most of the tasks we’re already used to doing on the web and within apps.

Because bots are a newer application, there’s still ambiguity for users wondering how to respond to different features, but once you walk them through it, that shouldn’t be an issue. Overall, if you want your bot to be part of your user’s daily habits, think simple and fast. Think buttons.

Lesson 5: The interaction is the UX

For product managers used to dealing with the complexities of CSS and iOS elements, creating a bot is a very stripped-down experience. It’s both simpler and faster, but it also leaves you little flash and glitter to make a dull app look good. Like a rock band having to do an acoustic set, there’s not much to hide behind.

These are the principles I found helpful:

1. Focus on the user’s intent
2. Remember context
3. Personalize
4. Optimize for speed
5. Use graphics to provide rich experiences

It’s helpful to get all the permanent context you need, like the user’s name and city, up front and, ideally, to get this information from the API without having to explicitly ask the user. But if asking is unavoidable, get those details up front. It’s important to have the bot remember them so the user never needs to repeat that step, the same way that a good clothes salesperson would remember your name and the styles you like. Then, use that context to determine all of the bot’s interactions (e.g., “Here are movies you might like in San Francisco”) while giving the user the option to change elements of the context if desired (e.g., “I have your city as San Francisco. Type ‘Change City’ if you ever need to change it”). Personalize your interactions with the user’s name for warmth, but strive to demonstrate friendliness and efficiency by focusing on the user’s intent (e.g., “Welcome back, Tim. Please choose your banking option below”) and use buttons and persistent navigation to make it as easy and quick as possible for users to achieve their intent.

Graphics provide one of the few design elements you have access to, so use pictures (and to some extent videos) to provide visual branding and enrich the results you return to your user.

Lesson 6: Use reusable patterns

Many of the core activities your bot performs, such as passing a request to an API and parsing the results or subscribing a user to an alert, are independent of the particular focus of your bot.

There are also standard user patterns that follow from other platforms — like first-time flow, sharing, and subscribing, which have similar analogies in chat. From a technical perspective, because there’s no CSS, JavaScript, or iOS dependencies to worry about, much of your code can be reused as general-purpose patterns on your next bot.

For a developer, this means a faster build-measure-learn loop on each new project, which means more focus on the high-value business purposes of your bot and less on the plumbing. If you do multiple projects, you can copy out particular patterns and save them for later projects.

Finally, a note on testing. No matter what you envision, your users likely will have responses you didn’t anticipate. An easy, low-cost option for user testing is to recruit U.S.-based people through Amazon’s Mechanical Turk service, and ask them to try out specific features on your bot and give brutally honest feedback about what they don’t like.

Exciting times ahead

Bots are just now starting to gain traction, and they represent a significant opportunity for businesses.

In particular, many businesses may find them a low-cost way of providing better customer service, product tracking, and after-purchase follow-up than phone trees and emails. And with BaaS platforms, the development cycle is potentially quicker and lower cost than with earlier technologies. Should be exciting times ahead!