Implementing the customer success bot Zoe in Slack
What we learned about simplicity, iterative development, and community
Zoe is a new bot we developed at Totango that allows users to ask questions about customers and customer segments directly in Slack.
A typical use case might be a CEO asking “@zoe, tell me about Acme.” Zoe will respond in Slack with KPIs for the customer Acme Inc, displayed alongside recent interactions a customer success team had with that client .
Or, a product manager might ask Zoe to “list all premium customers using feature xyz.” Zoe will respond by displaying a segment of users from premium accounts who have adopted that feature.
Zoe is built as an overlay over our core customer success technology platform, which does the heavy lifting of building out a rich set of insights from separate systems, such as an organization’s Salesforce CRM or a Segment.io data feed. In Slack, Zoe’s conversational interface makes it easier to access this key information in a straightforward way that all users – regardless of their understanding of Totango – can access.
In this post, I’ll share some lessons we learned as we developed the first Zoe implementation. In hindsight they seem quite obvious, but I wish someone would have pointed them out to me when we embarked on this mission 🙂
Give users only what they need
When we began developing Zoe, one of our biggest considerations was data density.
Zoe is built on top of Totango DNA-CX, our proprietary data architecture which contains multiple metrics and dimensions of customer data.
When you’re building a traditional web-based UI, you can use many techniques to allow users to gradually discover and explore data. For example, in order to gauge the process of an account, a customer success manager might need to review the week-over-week growth of a certain metric. The Totango UI supports that need by allowing a manager to click on a metric to drill down into a trend.
But when you’re building a bot, your visualization and interaction options are more limited.
Slack messages attachments are quite flexible — they can include buttons, attachments, emojis and other goodness — but their paradigm is closer to a command line than to a web UI: you type in some text, and get a short text response back. This took us some time to get used to, and our first designs spat out pages of metrics to even the most simple request for data.
However, our usability tests and analytics told a different story: we were overwhelming users with data. We discovered that as we reduced the density of information, users were able to better understand and act on Zoe’s responses.
The rule became: “Between simplicity and depth of information, always opt for simplicity.”
We kept removing stuff until we could not remove anything else. In many cases we had to let go of a certain dimension of data or work harder on the back end to translate several data points into a simpler insight.
Our current bot interface translates our web UI with multiple charts, tabs, and drilldowns into a card view with five options to show more. Not only is this a better design paradigm in the chat interface, it’s also better for Zoe’s users, who are typically on the go and require the “Cliff’s notes” version.
Users get the option to link out to a more detailed interface, but otherwise the high level of information keeps the conversation going.
Choose your SDKs wisely
Early on, we knew we wanted an abstraction layer over Zoe’s communication with Slack. We decided to try Botkit.
Botkit is an open-source bot development kit that makes it easy to build bots over many platforms, like Slack, Facebook, or Kik.
You can use Botkit’s neat plugin architecture to connect anything — from custom logging to NLP engines — into your bot’s conversations. We were able to easily plug in support for our own operational logging and metrics without much effort or fuss, which is always great when adopting a new framework.
It was very easy to get started with Botkit, and the project has a strong open-source community and great documentation. I highly recommend it.
Separate your bot interface and business logic into separate microservices
Our first iteration of Zoe included a microservice that took care of fulfilling a Zoe-related request end to end: everything from listening for incoming Slack messages, to parsing them, resolving them, and applying the logic to translate them into a request for our platform.
However, that structure made it difficult for us to iterate quickly. Each time we wanted to change our code to tweak our response message format, for example, we had to consider the impact of the change on the rest of the business logic before testing and eventually deploying the change.
We eventually decomposed the service into two microservices, each responsible for different parts of the user experience:
- Zoe Bot — The interface to Slack and other platforms. This microservice processes incoming user commands, interprets them, and passes the request to the business logic layer.
- Zoe Brain — The business layer that processes requests and pulls the needed information from Totango’s core data platform.
You can think of this as an implementation pattern for bots in general: separate your bot interface from your app’s core business logic.
Beyond separating concerns and increasing development agility, you’ll be able to keep each service stateless, making it easier to scale your app as your user base grows.
Quick iterations help balance simplicity and information density
With a bot, the difference in adoption between an okay experience and a great one are staggering. Users have very little patience to work with a bot that provides irrelevant responses.
For that reason, you need the mindset and the tools to deploy many versions of your bot, and then iterate quickly based on your learnings.
We made it a point to release the first version of Zoe one week after we started working on it. But we used this as a base to gradually expose new versions to new users and gather feedback.
We were able to iterate over a dozen versions of Zoe’s basic response in a single development sprint, enabling us to reach a format that was the “just right” balance of content and information density.
Think beyond the bot
A truly conversational interface isn’t just about building a bot interface. A conversation doesn’t always start with “@zoe,” and it does not always end with Zoe spitting out information back to the user.
For instance, we discovered that customer success managers often need to loop in other people, like an engineer, while working from the native Totango application. Sure, they could switch their application over to Slack to do that, but sharing information to Slack with a “Share to Slack” feature was more convenient.
Building a conversational interface means making it easy to get things done while interacting in the most frictionless way possible. Sometimes that involves speaking with a bot in a channel… but it can mean more than that.
Work with the community
Finally, work with the community.
Slack’s developer support team is awesome and has helped us every step of the way. From validating our architecture, recommending design patterns, sharing their roadmap and even publishing this blog :-)
In addition, the team at Botkit has been great resource.
We’ve spent the last few months building Zoe and have recently released it to the market. Even more exciting to us, we’re seeing new user types, such as engineers or executives, use Zoe to have more meaningful, data-informed conversations about customers….which means we’re closer to our vision of making customer success everyone’s business!
This post was mostly written by Oren Raboy, Totango co-founder & VP of Engineering
