Our internal bot has been running for a while and getting some use.
We've gotten it so that it runs for 7 - 10 days without issue, but after that length of time it seems to quietly lose the connection and we previously weren't checking for that. I'm not sure if that is a feature of Slack itself or the library we're using. In any case, 7 - 10 days seems pretty good and we should probably add some code to recover if something happens.
To get to 7 - 10 days with a Slack bot, the key was to use the Ping/Pong functionality you can see here. It's part way down the page, just look for 'pong'.
We're currently pinging every 10 minutes. This is a lot less than I've seen recommended, but I believe those recommendations were based on building chat clients with the RTM API, not long-running bots with lots of downtime. I don't want to get in trouble with Slack for sending a million ping messages for no reason.
Instead of upping the number of pings we send (which may have helped) we've added some functionality to check as part of our ping/pong functionality to check for the health of the connection. This seems to be the more responsible way to run the health check and reconnect if the connection is offline.
We've tested our reconnect, which works well. Now we just need to wait 7-10 days to see the production failure occur and see if it recovers.
A user can't really tell what state a conversation is in from looking at the text on the screen.
Does a user understand that this conversation had a specific state and it needs to be revived in that exact place? That isn't really how a conversation works with a human being.
You leave off. You might meet at the coffee pot. Their might be three separate emails.
What you return to doesn't have to be addressed as though it were some procedural checklist. The bot needs to be smart enough to remind the user, to help them pick up where they left off, or just move on if that is what needs to happen.
One of the great things about Slack is that it serves as a direct IM tool, a more general discussion tool, and allows for private groups and channels.
When you're building a bot for this type of tool you need to think about where you want your bot listening and how you want it to behave when you are messaging directly vs. in a public channel.
For our first bot we decided that the main focus would be on the direct messaging and we would keep the bot chatter out of the channels (public discussions) and groups (private discussions). But in the event that it appeared that contextually someone should use the bot, we would make a suggestion asking if they wanted to direct message the bot.
We can then invite the bot to channels where we think this would be appropriate, and not invite the bot where we think it would be annoying.
Slack is quite powerful and well thought out in this regard and this type of cross-linking between messages, channels, and users is easy to do.
If you are just getting started with this, it is very helpful to read the Message Formatting Spec for Slack.
The first thing I have noticed in building a bot is you need to think a lot about state management, even for a basic bot.
The original app we built had 5 or 6 entry fields on a form and you did not need to think about state at all. With the chat bot I now need to think about the state of the interaction between bot and user as it moves from step 1 to step 2 to step 3.
At this point I am going to allow the user to skip ahead with some smart text analysis, and I've accounted for that in my state document. But I am not yet allowing the user to move backward or change an answer.
For our basic bot we have developed a simple flow chart on a white board that describes the 5 steps and where we allow skipping, and what are the criteria for the skip.
For anything more complicated you would need to write something up and spend time thinking those requirements through. As it is for our bot, we are going to release an MVP and get some user feedback from power users, then we will look at possible expansion and feature addition. And I will likely need a real flow chart for that.
We are starting to build a couple of conversational UI programs at work using Slack. Slack is a great program and I wrote an earlier post about some challenges I had writing a basic integration.
So now we're tackling something a bit more sophisticated and building some bots. The first will be to handle a couple of basic data entry tasks that we have that we think will be better or easier if people can do them directly from Slack.
Of course we'll need to get user feedback on whether they actually make life easier, but I think by investing a little time in the bot it will improve things. We plan to do this in two ways:
Our bot will parse some answers and use extracted information to pre-fill some other data.
Allow multiple entry/splits on some items by indicating that you want to do so. Where this would require a grid in the web, and might be unnatural given the flow of existing pages, we think it will work quite naturally in the bot.
Jonathan Fries on .