The first article in this series, “Microsoft Bot Framework: Let’s Get Chatty!,” took a look at the Microsoft Bot Framework and how to set up the channels of communication. The second article, “Turning Natural Language into Meaning with LUIS (Natural Language Understanding),” focused on natural language recognition using LUIS and organizing the conversation into some basic dialogs. This article explores how to bring your bot more places and offers up some approaches to making sure your users love your bot!
The Bot Framework also supports interactive voice response via the Skype channel. When you use this channel, Skype’s service takes on the work of translating the voice to text, recognizing when the user is done speaking, and passing along the text to your bot. When you reply, Skype also takes on the text-to-speech chores to reply to the end user. The combination of the bot framework, LUIS, and interactive voice response could lead to a revolution in capability for IVR systems.
To take full advantage of the voice-specific capabilities of the framework, you will need to use the Calling API. In a chat window, messages are passed back and forth only when complete. In a voice interaction, it takes time to speak phrases and there are interruptions. Using the Calling API lets you handle these voice-specific nuances of the platform.
Going Cross Platform
The Microsoft Bot Framework supports more channels out-of-the-box than any of the other bot frameworks out there. It supports Facebook, GroupMe, Kik, Skype, Slack, Telegram, SMS, Email, and more. Despite this impressive diversity of channels, it’s not everything you would want to connect to your bot. Alexa from Amazon is very popular and you may want to add voice controls to your mobile app, for example. The good news is that Microsoft’s Bot Framework is flexible enough for you to add new custom capabilities like this.
Adding support to a custom app is very simple and straightforward. Within the Bot Framework. it is simple as using the Direct Line API they have included to route messages to and from your existing bot.
Supporting the Alexa platform is more challenging due to the differences in the interface. Alexa does both the voice-to-text and the meaning recognition via its skills toolkit. The core concepts are the same, even if it names them a little differently. Alexa uses the terms intent and utterances the same as LUIS does, but instead of having Entities, it has slots.
Manually setting up all of the same utterances, intents, and slots in Alexa to match the work you’ve done in LUIS would be a very laborious undertaking. Fortunately, Amazon does have a mechanism to upload intents as JSON files. As an added bonus, LUIS supports the ability to export its configuration into JSON files. It shouldn’t come as a surprise that they are different file formats. This means you will need to write a translation routine to export your LUIS model into a format that can be read by Alexa.
Once you have your intents uploaded to Alexa, you can build some simple wrapper services matching what Alexa’s SDK that route to your bot’s endpoints. It’s a less elegant solution than just being able to configure a new channel inside of the bot framework, but it is an example of a way to use the bot framework as a universal platform that can support channels it wasn’t originally designed for.
Don’t Be Human
Bots should never pretend to be flesh and blood human beings. First, people tend to get angry when they discover they are talking to a computer instead of a person. It feels like a betrayal. Second, people speak differently to a bot compared to how they speak to a person.
When you feel like you’re talking to a real person, you tend to talk in stories. For example, if you were calling to report an outage on your Internet connection, you might say:
YOU: “I was playing Overwatch, my team was winning too, and the Internet just cut out. I already tried resetting the router.”
Language recognition programs such as LUIS would struggle with this sentence because it would need to eliminate the unnecessary information to focus on the two key facts it cares about: The user is experiencing an outage and they have already reset the router.
If you know you’re speaking with an automated system, you would choose simpler statements without the background stories.
BOT: “I’m ISP Bot. How can I help you today?”
YOU: “My Internet isn’t working”
BOT: “Can you reset the router?”
YOU: “Already did, still not working”
In this case, the user can still interact using natural language but, because they know they are talking to a bot, telling it a backstory isn’t likely.
Have Some Personality
Because your bot isn’t trying to be human, you have the freedom to make it be whatever you want. If you’re a university, your bot could be your team’s mascot, for example. This is a unique opportunity to inject more of your brand’s personality into the customer experience than you could practically do with people handling the chats.
There are other benefits to giving your bot a special personality. By choosing a personality that doesn’t pretend to be “Carol in Customer Service,” it should be clear to the user they are talking to a bot without explicitly labeling your bot as a bot.
Microsoft’s Bot Framework is surprisingly extensible. You can easily adapt this platform to be your company’s natural language interface across all devices and channels, including voice communication. Your bot is a unique opportunity to provide a new channel for your customers and inject some of your brand’s personality into the mix.
About the Author
David Talbot is the director of Architecture & Strategy at a leading digital bank. He has almost two decades of innovation across many startups and has written extensively on technology.