(Not another) Make your First Bot Tutorial
Thoughts on links, markup and hosting for bots
Let’s face it, the how to make your first bot tutorials were helpful a year ago, but right now I feel like I am going to scream if I have to read another basic tutorial that just show you how to cut and paste a few API keys, responds to one basic request and ends with, the sky's the limit. These tutorials are reinforcing the idea that bots are just toys and programs for geeks to get excited about.
The other post that drives me crazy is the aspirational post that allows people to feel like bots are going somewhere without providing a roadmap for how to get there. We are still very early in the bot revolution, so let’s make a roadmap and get moving.
Bots need links, markup and hosting to become mainstream.
Short Sighted Focus
Right now, people are focused on how to integrate with APIs and get the bots to work, but if we are going to make this bot revolution happen we have to make the bots as useful as websites. There are three things that make websites great: links (URLs), markup (HTML), and hosting (web servers). Let’s rethink all three but in light of making a bot.
Real World Example
I need my haircut. I am looking on yelp. I find Andre and John a salon near me. I read some great reviews about Andre. Yelp provides a link to book Andre. I click it and a friendly bot greets me with:
bot+sms://13234547887/schedule?stylist=andre
Bot: Hello, I am the schedule bot🤖. What time would you like to schedule your 💇 with Andre?
Me: Tomorrow at 4.
Bot: Great, Andre is available then. Can I get your name?
Me: Daniel
Bot: Thanks, I have scheduled with Andre tomorrow at 4:00 PM. See you then Daniel.
The link I clicked on looked like this: bot+sms://13234547887/schedule?stylist=andre
There is a lot in that link so let’s unpack it.
Deep Linking Bot URLs
If you have written your first bot you have a hard time sharing it with other people. That is because linking to them isn’t easy (although Facebook is making it easier for messenger bots). If you can link to the bot, you can’t deep link to a specific part of a conversation. To this end, I would like to propose a URL schema for bots.
bot+sms://13234547887/schedule?stylist=andre
Protocol: bot+service
The protocol is in two parts. The first is bot, this tells our browser or OS that we are linking to a bot. The second part, sms, tells us that our bot is built on SMS and that the OS need to open our text message app. The second part could be replaced with various messaging apps Facebook, Kik, Line, Skype, etc.
Bot Name/Domain Name
Continuing on, we encounter 13234547887. This is the phone number for the bot and it has replaced the domain. For app-based bots you could provide the app ID. Optionally the standard could be expanded to have a TXT DNS record which points to the App ID or phone number. This could allow for bots to be access via domain names. (Ex. bot+sms://yoursite.com/schedule?stylist=andre)
URL Path: /intent?entity=value
Finally we have the URL path, /schedule?stylist=andre. This is where things get interesting. There is a lot of work going into making bots sound human (and that’s another post), but the key thing to understand is that those technologies can be summed up as Natural Language Processing (NLP). NLP maps human readable strings to intent and entities. The bots engines key off of these intents and use the entities as variables. In our example, we have had an intent of schedule and an entity called stylist with a value of andre.
Implication of URLs for Bots
URLs for bots would provide a lot of interesting implications, the first is that you could link between bots and allow a single endpoint to house multiple bots. Second, with deep linking of the bots, web crawlers could start to index the bots and provide bots as part of search engine results. Third, having a standard URL structure would help to keep one company from getting a lock on bots because linking is a great equalizer.
A standard URL structure would help to keep one company from getting a lock on bots because linking is a great equalizer.
Sign up to learn more about our bot platform.
Botflow: Markup for Bots
So now we can navigate to bots and link to specific actions. Let’s look at creating an HTML for bots that can make them as easy to write as web pages. HTML provided a powerful framework for developers to be able to display and collect data. Botflow can do the same. One big difference between the two is that botflow will be run on the server side and translated to the various messaging platforms.
Each botflow would be comprised of a series of intents or states. The intents map to the URL path and can link to other intents or trigger an extension. The intents can branch like a flowcharts based on the user’s feedback.
Tags
HTML is based on tags. So what are the key tags needed for a bot?
Intent
The intent tag is the top-level tag. It can be thought of as a state in a state machine. The intent will have a name attribute and can have a series of parameters. Those parameters can be passed in through our URLs or collected forms. The intent tag can have a nested message tag that is sent to the user. The prompt tag can ask the user for information. Finally, intent tags could have nested intent tags.
Message
The message tag allows a node to send a message to the user.
Entity
The entity tag is a parameter for the state. Its data can be populated via the prompt tag, a URL parameter or the session. If the value is present the prompt will be skipped.
Prompt
The prompt tag will ask the user a question and save the response to the parent variable. The prompt tag has basic validations including picking from a list.
Extensions
Extensions are like Javascript for HTML. Ideally they can be written in Javascript and provide that link between data sources (databases, APIs, etc.) and user input.
The bot platform should provide a series of basic extensions for common items like forms. In our hair cut example, we might want to inject a step in the schedule flow to ask for the kinds of services that you will need before determining a time to schedule. You might be getting your hair dyed so that service will take longer. We might also want to have an extension to handle payments.
Here is an example botflow for our haircut conversation written in haml:
schedule.bml
intent: schedule
entity: stylist
prompt: Which stylist would you like to schedule?
accepted_values: andre, john
show_options: true
entity: schedule_at
extension: scheduler.new
param:
stylist: session.stylist
entity: name
default: user.name
prompt: Can I get your name?
next: thanks
intent: thanks
message: Thanks, I have scheduled with #{stylist} #{schedule_at.day} at #{schedule_at.time}. See you then #{name}.Implication of Markup for Bots
Once you have a markup for bots you can leverage all of the existing concepts we use when building websites, such as CMSes and WYSIWYGs. Additionally, if you combine these with a runtime engine you can perform unit testing to ensure that the bots are working as expected.
Sign up to learn more about our bot platform.
Hosting
The early web servers were super simple. Upload some HTML files and then the server will share them. The browser does all the heavy lifting of making them look like something. Over time, the web server became the place where script languages connected to databases and produced dynamic HTML.
Bots need a friendly hosting environment. Hosting a bot is a complicated task. It involves a lot of plumbing to create the integration between all the messaging channels (SMS, Facebook, Kik, Skype, Slack, etc.) and then being able to save that data and pack it up to your own web app. The bot platform will allow you to have all the plumbing taken care of so you can focus on building bots and not connecting channels (so you don’t have to read yet another building your first bot tutorial).
Sign up to learn more about our bot platform.
Putting it All together
We have looked at this problem from the consumer side, now picture that you are the salon owner. You decide to launch a bot for your hair salon. You don’t want to hire a developer so you click over to the Bot Platform and create an account. After creating the account you pick the salon workflow templates. You answer some questions about your stylist and configure your schedule to sync with your Google Calendar. You then link the bot to your Facebook page. You go to the promotion tabs where you grab some links to each of the stylist in the studio. You update your Yelp profiles to allow for quick scheduling.
A week later you have some free time because you are not spending as much time on the phone scheduling clients. You browse the extensions marketplace and decided to enhance our bot by installing an extension that allows your customer to refer their friends and another extension that tracks their visits like a loyalty card. All of these are features that would cost tons of money in app development, but are just part of our more complete and truly powerful bot eco-system.
You order new business cards, but instead of putting your website on their you put your bot’s URL. After all, who wants to go to a website about a salon, they really want to just schedule you.
Conclusion
I think that bots are missing all the elements that make the web work: links, markup and hosting. Providing solid solutions to these three problems will allow us to get past your first bot tutorials and onto building bots that matter.
We are building a platform to bring all of these ideas together. If you would like to learn more, click here to sign up.
About the Author
Daniel has been a technologist for 15 years and is the founder of Commerce.io, an e-commerce platform for messaging.
