Editor’s note: Over the course of our two-and-half-year quest to build an enterprise grade Bots Platform, we’ve fielded hundreds of questions from developers, businesses, analysts, and reporters about the capabilities and uses of chatbots. The conversations started incredibly basic, like “What is a chatbot?” or “How is it different from an app?” But now, just like chatbot technology itself, the market knowledge is evolving, and we want to let you in on the types of discussions we’re having daily at Kore.ai. Hopefully, these bi-weekly blogs will serve as sort of a running chronicle of all things related to chatbot development, and give you a greater glimpse of what to expect when considering bots for your company. You can also watch our webinar “Entering The Conversational Era” here.
1. Will I have to write scripts for the bot and anticipate everything users might say? This is a common fear customers have - that the journey to getting a chatbot NLP enabled and truly ready for customer interaction seems long, arduous, and never ending. Let’s take this question apart piece-by-piece. The first part of the question, “Will I have to write scripts for the bot?” is a pretty easy one to answer. The script for the bot is dependent on the task you create, and most NL engines will come pre-programmed with formatted responses. For example, in Kore.ai’s Bot Builder, a task like “get me the current temperature” wouldn’t need much of a script. The bot would simply ask for a location, give the desired forecast, and that’s that. The script for more complex tasks like, transferring money to a friend via a banking bot, or setting up a crane inspection workflow for an industrial site via a logistics bot, may require some customization of formatted responses, added buttons, images, or forms. But all of that can be done fairly simply, especially if you choose a development platform with a Dialog Builder. This would allow developers to create more human-like, even brand-specific bot responses.
As for the second part of the question, “Will I have to anticipate everything users might say?” the answer is generally, “No.” You should always try and anticipate as many scenarios in which users could speak to the bot but it will ultimately help you improve your UX and adoption, but doesn’t mean you have to specifically train the bot for every single variation - and here’s why. Chatbots can be built intelligently enough to anticipate word variations. Natural language engines, especially ones that thrive on a synonym model (like Kore.ai’s) instead of a machine learning only model, can do a lot of the leg work for you. All a developer would have to do is think of different synonyms for the intent and field data necessary to complete a task and add them to the NL engine. The chatbot instantly has a library from which to draw understanding from. For all the “out there” ways users could speak to a bot, a developer could use their own imagination and add them via machine learning, or use success and failure chat logs from bot-to-user interactions to look for additional corrections to refine the bot’s NLP.
2. My employees or customers are going to hate the experience and feel like they’re talking to a robot. There’s some trepidation in the market about the chatbot “experience,” probably because of the early missteps of developer (not enterprise) led chatbots and because most of the time when people are talking to a phone tree, or an automated live chat service on a website they think they’re talking to an AI-rich chatbot, but they’re not.
Chatbots built with advanced NLP and AI capabilities can not only understand more natural language variations, as discussed above, but they can draw from more structured and unstructured data sources, leverage more contextual data in real time to make helpful actions, take conversations across communication platforms, hand-off seamlessly to live agents, and many other things that extend far beyond the frustrating experiences users may have had in the past. Chatbot development capabilities are growing more intricate and useful daily, which means it won’t feel like talking to a robot because the functionality can be robust, and the experience more intuitive and less work for the user.
At the heart of what frustrates users with typical self-service experiences is often repetition of inputs or commands, too many steps and added time to get simple things done, and not enough burden being removed from them and put on the system. Bots solve for all three of those problems by reducing clicks, screens, and sign-ins, guiding workflows in natural language, linking to back-end systems for quick problem resolution, and handling more of the process “workload” than the user.
3. Is maintaining and scaling the bot going to be a pain in the neck? For the types of enterprise customers we work with, scalability is probably their #1 concern. Platform selection is key when thinking about how chatbots will scale across your business, and if you don’t build chatbots with a platform at all, it can be incredibly hard to keep consistent when it comes to features and functionality as your user base or user needs grow in complexity. Building with an enterprise-grade Platform can virtually eliminate all of the hurdles that might come up when trying to scale, such as
- Can I build various types of tasks into my bot?
- Can I build one bot and deploy it in multiple channels or do I have to build a separate one for each?
- Does the platform have a built-in NLP and intelligence engine, or do I have to piece together technology from multiple vendors?
- Can I integrate easily with different systems like SAP solutions, ServiceNow, Salesforce, etc.
- How do I secure and manage the bot? Is there built-in analytics and administration in the platform?
- Is the technology compliant for highly regulated industries?
A true enterprise grade platform should answer all these questions and more. The last thing a company needs en route to innovation is to herd multiple technologies and vendors just to build and scale a bot effectively. It not only adds cost, but strips you of resources and time.