Marvin — our first chatbot

The idea of a Slack chatbot was one of the first that came to my mind when our last hackathon was announced. I wasn’t the only one with that idea, so we decided to combine forces.

When writing a chatbot, in general you have the question of which platform it would work on. If written correctly, a chatbot should be easily extendable to many platforms such as Slack, Whatsapp, text messages, Hangouts and many more. However, due to Slack being our main collaboration tool in the company, in our case this wasn’t even a question.

Building a chatbot sounds very simple when reading about it, but when we started our implementation, we found out we have many problems to tackle, among them were:

• Interacting with Slack API to listen to messages.
• Identifying when our bot is addressed and should respond.
• Understanding what our bot is being asked.
• Interacting with systems to retrieve information.
• And many more.

Using Slack API turned out to be the hardest one very quickly in the process. Slack has several APIs that we could use, each with its own advantages and disadvantages

• The API that is used to read messages is not the same one used to post messages.
• Editing a message is possible through one of the APIs, but only within a certain timeframe.
• Replying is possible as a response to the read API, but only within a very short timeframe.
• Errors were not very informative.
• Slack has its own way of formatting your message; you have to format your messages yourself if you want them to look nice.

The way we tackled the communication with Slack was by using two of the APIs, one that listens to all messages and one that allows you to post a message to any channel you are in. The APIs are based on an integration user which is called an app in Slack (since it is usually used for integrations with different applications) created for our usage. So the first step was to create a bot user in slack. You can read how here.

Listening to messages was done using the incoming webhook API, which allows us to call an external API on each message posted in the organization.

We used it to call our API with the message and then used the mentions or channel information to understand if our bot should respond.

The first problem to tackle was that the API had to respond within a short timeframe, so instead of handling each message as it came we had to create a queue for messages to be handled later. This made our incoming event listener look like this:

Push each incoming message to a queue to be handled later on

Our bot responds when being mentioned, or when the channel is a private message which includes only the bot and the sending user.

Should our bot respond to the message?

This covers most of the cases we want without writing complex code to analyze each response. In a regular conversation another person will understand you are answering him even when he is not mentioned. Some cases were you are mentioned you can understand from the context that the message was not meant for you. Marvin is not that smart yet :). This was a hackathon project and as such we were willing to live with less than perfect logic.

Slack’s post message API can post a message to a channel or direct message. The API also allows to edit a posted message as long as you have the same token and timestamp as the original message.

To use the API you simply issue a REST call with a JSON body that complies to the API requirements. We built a simple method to do that:

And another to update:

We used it to respond to messages and to provide updates. For example, some of the requests our bot knows how to handle take some time. If we had let the user wait for that time period without any response, the user would have gotten the feeling the integration doesn’t work. What we did was to respond immediately to the message with something saying: “OK, got you” and then later on post the response that contained the answer the user was looking for.

As mentioned before, we used a queue to hold the messages that require handling so we will not ignore messages or have timeouts. We kept the details of messages that we need to continue handling so we will be able to edit responses.

Slack includes the ability to add buttons to a message. It is a very quick and useful way to provide your users with some functionality or refinement of what they got in the response. Using the edit API, we could allow the user to update the time filter on the analytics information presented in the message and provide her with the updated information on the same message.

A response with buttons from our bot

When we found ourselves investing most of our day on using Slack API, we started reducing the scope to minimize other problems:

• We reduced the number of systems we interacted with and anything that was too complicated to connect to was abandoned.
• We created a mechanism to generate demo responses so we could show our plans without doing the actual implementation.
• We recognized whether we should answer a message using mentions of our bot.
• We recognized keywords in the message to understand needs, instead of using NLP and extracting meaning from the messages.

There were a few things that we weren’t ready to reduce our investment in:

• The formatting of the responses — we saw this as paramount to the impact this bot could make. We used all of the options Slack gives us including embedding charts, using image generation and buttons for quick responses from the user.
• The personality of our bot — we saw how much fun and different it was to interact with something that wasn’t simply responding with what it was asked, and how it triggered emotion in our users, that we felt it was worth the effort.
  The personality we chose is of Marvin the bot from “The Hitchhiker’s Guide to the Galaxy”, the famous book by Douglas Adams. The story is about a robot company that came with the idea of embedding robots with genuine people personalities in them. Marvin was embedded with a manic depressive personality.
  We used quotes from the actual book and phrases that gave the same feeling in all of Marvin’s responses and the feeling was dramatically changed.
  Even messaging random messages at him could feel like a conversation (though not all the time).

An example of a response from Marvin

Another example of the manic depressed responses

The Slack API problem was handled on the late hours of the day and from there the implementation accelerated dramatically, adding one integration after another.

The bot could handle all kinds of tasks by the end of the first day, like:

• Getting your feature bit status for any user/ feature.
• Getting the details of a ticket from Jira.
• Giving you build statuses.
• Providing you with a campaign’s analytics information.

And all from a simple Slack message.

The result landed us in a tie for first place and got us a yacht trip on a sunny day :) certainly worth the effort!