According to a Business Insider study, 80% of businesses plan to use chatbots by 2020. At Workato, we’re no different; we know chatbots are crucial to the future of work. That’s why we launched Workbot for Slack in early 2016. Since its inception, we’ve expanded and improved Workbot, adding a version for Microsoft Teams and incorporating new Slack features like Message Menus.
But how does a bot get built? Why does Workbot work the way it does? Members of the Workbot team offer four lessons on what it takes to create a functional bot.
1. Identify desired use patterns and build around them.
When the Engineering team first conceptualized Workbot, chatbots were already popular. But there was a problem: existing bots were generally static and not very useful to business users.
“At the time, most existing bots only sent notifications,” explains Harish Shetty, head of Engineering and part of the original Workbot team. “For example, a bot could send you a notification when a customer filed a ticket in Zendesk, but that was it. You couldn’t perform any actions using that bot.”
Shetty recalls that, in a meeting, he suggested that users might desire greater functionality. “Apart from receiving notifications, you might want to get data from systems. For example, when a new contact comes in through a web signup form, you might want details about that account or about how your funnel is doing according to Mixpanel.”
He explains that Workbot actualizes this logic by enabling contextual commands—actions a user is likely to want to take based on a notification. “When a user receives a new ticket notification, for example, they might want to get a 360° view of that account. Workbot suggests contextual commands associated with the notification, so the user can easily ask for the information they need.”
In determining how Workbot would provide better functionality, Shetty’s team identified three usage patterns:
- Approving requests from Slack, which requires a highly customizable bot that can incorporate rules specific to a user’s organization.
- Initiating a command from Slack, like fetching account details from Salesforce.
- Executing commands on a schedule, like pulling periodic reports from an app into Slack.
Once they identified these use patterns, the team set to work building Workbot. The initial build took two weeks to prototype and two months to implement. The Product team then spent an additional four days creating recipes—a set of instructions that power Workbot workflows—to integrate the bot with other apps. Workbot officially launched in February of 2016.
2) Humanize your bot.
The Workbot team quickly realized that building an interactive chatbot entailed far more than the ability to respond to commands or execute actions in other apps. To be truly interactive, Workbot would have to engage with users in a way that was natural—and, in some ways, distinctly human.
“We built the original version with a command line kind of interface,” says Shetty. “As we started using it, we realized that’s an okay interface for engineers like me, but it’s still very difficult to use.” He points out that the rigidity of traditional command language presents a special barrier to non-technical users. “It might take you several years to master all commands in a command language,” he says. “We had to make it easier.”
Shetty explains that they began by simplifying the interface so Workbot would respond to more flexible phrases—like “Please create a Zendesk ticket” or “Zendesk create ticket”—instead of only specific commands. From that point, they made the interface more intuitive. In the current version, Workbot guides the user through a command by asking questions like what a ticket’s priority is or which action you’d like to perform next.
“Essentially, we went from a very strict interface—where you had to interact with Workbot in very specific ways—to a final, interactive version. Now you don’t need to type much to get your message across,” says Shetty. The natural language processing (NLP) module also understands aliases; whether a user types “Salesforce” or “SFDC,” Workbot knows which program they mean.
From a Product team perspective, humanizing Workbot extends beyond the language it uses. Not only must the commands be simple for non-technical users to remember, but the integrations and use cases themselves must be grounded in real-life workflows.
Ee Shan Sim, a Product Manager who created the initial Workbot recipes, explains that the Product team tried to adopt a layperson’s perspective. “We asked ourselves, ‘What would it be nice to have a bot do for me?’ To understand that, you have to jump into the day-to-day lives of your target users. You have to ask, ‘Okay, if I were a sales manager, what functionality would I want?’ Or ‘As a project manager, which of my daily tasks could a bot make easier?’” This sort of purposeful empathy may seem obvious, but it resulted in 75 initial use cases!
3) Dummy-proofing is your friend.
As the ways of addressing and using Workbot increased, so did the number of potential errors. Some of these errors stemmed from the challenges of natural language, Shetty explains, which is inherently flexible. “Once we made it so that users could informally address Workbot, we had to correct the algorithm to guess what they might be saying.”
Introducing NLP was a big step towards making Workbot useable for everyone, but it wasn’t enough. “People are used to pointing and clicking, not typing,” Shetty says. The solution? Adding buttons users can click to execute commands.
“The primary theme here is that users are simply expressing their intent,” he continues. “They don’t have to express it fully or perfectly; they can just start with the basic idea or the app they want to use.” In this respect, he says, Workbot’s interface mirrors something many people are already familiar with: Google’s autocomplete feature. “Even if you know exactly what you want to search for, Google shows other suggestions. And quite often, what you’re looking for is right there.”
The Product team also worked to reduce the likelihood of user error, a tall order when crafting integrations that sometimes require user input to work effectively.
“We had to keep Workbot powerful but also make it flexible,” Sim explains. “User inputs are required, but we wanted them to be intuitive. The challenge was finding a balance between how powerful a recipe should be vs. how intimidating it is to the user to go through the workflow. We had to continually ask, ‘What makes sense for a first-time user? What’s going to look weird to them?’”
Customer Success Lead Ryan Koh (who helped Sim build the first 75 integrations) agrees, recalling a particularly challenging use case. “We built a notification recipe for sales or service reps, so they could have relevant information about a new customer delivered to them via Slack. We picked a target data source and used Slack as the destination. But we had to build a smart notification system, so we had to pick the right inputs to define the notifications—to define the expected output, and to hyperlink to the apps the user will most likely to want to take action in next.”
But simplifying the UX made building the recipe more complex. “We wanted to make it dummy-proof—to make sure that the user couldn’t mess up. It was difficult. It took up almost 80% of the entire process.”
4) Be a continual work-in-progress.
Unlike other projects, building a bot isn’t a one-and-done process. Because bots are live, they require maintenance and updates on a rolling basis.
The Engineering team sources Workbot improvements from several channels. “Slack is continuously improving their platform,” says Shetty, “so we are continuously adapting Workbot to incorporate or work with new features that would be useful to our users, like Message Menus.”
From a technical perspective, he says, the biggest improvement was Eventing: ‘’What used to happen was that you had to have a special server that interacted with Slack. But about a week after launching Workbot, we already had few thousand users. Maintaining live connections with the server and with Slack—it was pretty problematic from reliability perspective. Initially, we were responsible for making sure the connection remained stable. If it dropped, Workbot would disconnect. We had to create architecture that would keep the connection stable.”
Shetty explains that mid-2016, Slack introduced a new infrastructure called Eventing, which helped the Workbot team move away from traditional architecture. “It made the entire thing much simpler for us and them!”
Besides architectural changes and external features, the Product, Marketing, and Engineering teams collaborate to implement user-driven improvements. “We look at the usage stats—how are people using a particular command? How do they interact with Workbot in real life?—to see which areas need improvement.”
The most important feedback channel? The customer, according to Shetty. “They’re constantly asking us to add new things!” Koh adds that the Product team carries out extensive user testing to ensure that Workbot meets users’ needs. “We want to make sure Workbot is truly user-friendly, even for our non-technical customers.”
Ready to get started with Workbot? Get Workbot for Slack here or learn about Workbot for Teams here.
