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.