Before You Ask For a Chat Bot...
Chances are if you’re working in a large enterprise today you've heard the request or perhaps even made it yourself. "We need a bot," or, "We should use AI to solve that," sounds like such a fantastic idea. I mean, we do live in amazing times filled with science fiction technologies that are moving very quickly to reality. So, this idea isn't at all wrong. In fact, it's a pretty good one.
I’ve heard it quite a bit myself in my role. So, I started to think about the questions to challenge the requests in order to test the commitment to make a chat bot work in the particular instance it’s being requested. Here are the key questions I think are necessary to ask when considering a bot:
- Do You Have the Data? Any bot discussion should start with a dialogue around the data source that will be used for ‘said’ bot. You see, absolutely critical in determining the success of a bot, one that people will come back to time and time again, is a treasure trove of rich data: Data that is typically more expansive and nuanced than your audience has the patience to wade through is usually what's driving the idea of creating a bot. A bot to answer questions about a complex policy, provide the user insights on years of financial data, or provide insights relative to mountains of knowledge capital in the form of terabytes of documents in a repository, will all do better with a rich set of data. And, of course, knowing what data you have will save the collective user base a ton of time as well as the organization as a whole. Bottom line: Make sure you're starting with a use case that has a comprehensive data source.
- Are You Committed to Curating the Information for the Bot? Are you willing to commit grey matter (i.e. a person or people) to making the bot smarter and smarter? I usually get the immediate response of, "What do you mean? This is a bot, it's supposed to learn and get smarter, right?" This is where real life and science fiction usually collide for the requester. Machine learning has come a very long way and the advancements are certainly promising. Scientists are setting up robots to learn how to walk, teaching them create to their own languages and a ton of other examples out there. But for the use cases being discussed in the enterprise right now, the vast majority will need human intervention to ensure the bot gets smarter and smarter to keep the users coming back for more. The way to do this is by ensuring that the bot has a mechanism (i.e. a human or team of humans) for surfacing the questions being asked by the users, the success rate of the responses, the level of user frustration (abandoned interactions), the return rate of individual users, etc. This is real work and will return handsomely on your investment if you commit some humans to the task.
- Are You OK if Your Bot Isn't the Center of Attention? This is a fun one to discuss. The use case for an individual bot can be extremely compelling. It surely will solve some pain points that many people have today or you wouldn't be contemplating it, right? But how exactly are your employees going to get to your bot? An important factor in launching a successful bot is simply access. Think about how your employees do their day-to-day work, where they do it, the complexity of their roles or teams, their technical environments, etc., and try to hone in on what is going to be quickest and most intuitive to your workforce so the bot can provide the value that you intended. For example, think about intelligent agents like Amazon Alexa, Apple Siri, or Microsoft's Cortana, and the fact that there's just one interface to remember and that one interface can handle a bunch of different questions or tasks. We need to pay particular attention to the reasons this works very well and avoid a confusing or cluttered user experience.
- Will You Trust the Answers & Let Them Stand? Putting a bot in front of your users - provided that bot is connected to your rich data (see #1), is constantly curated (see #2) and is easily accessible (see #3) - to answer their questions is more nuanced that it may first appear. Take, for instance, company policies. An employee consulting a bot to provide a definitive answer on any topic, especially one where they might not corroborate the answer with someone (for example HR or their Legal Department) means that your bot needs to be extremely accurate. The bot might not have the full context of who is asking the question. For example, someone who lives in the United States might be asking the bot about the travel policy and receive the perfect answer, but for someone living in Madrid, Spain the answer could be very different. When the employee makes a decision based on the bot response (which they will if that's what you tell them to do) it just highlights the importance of getting this right from the start. So, having all three of the first questions squarely addressed will make this accuracy issue fall more comfortably into place. However, that is not to say that having these three questions answered will ensure complete accuracy from the start. I am encouraging a continuous examination of your bot project to help achieve your desired state in #4.
These are fairly straightforward questions to ask at the start of whatever bot journey you might be taking. I have found that thoughtful reflection on these concepts helps to turf up not only which ideas should be taken forward to full deployment in your enterprise, but can also help the teams that have already deployed bots to consider how they can improve them.
The rise of bots is similar in many ways to the first big propagation of mobile apps in the enterprise. There were thousands of fantastic ideas for a mobile app that would become the "one stop shop" for all of your employees to get their most urgent tasks done on the go. Only a handful of these usually survived a few months in the hands of users and those were usually the ones that had similar characteristics of those where you could answer "Yes" to the kinds of questions above.