In early May, I flew out to Oracle HQ in San Francisco for an early look at their yet-to-be released Oracle Chatbot Cloud Service. The training left me ecstatic that the technology to quickly build great chatbots is finally here. However, the question remains, can chatbots provide real value for your business?

What is a chatbot?

A chatbot is a program that simulates a conversation partner over a messaging app. It can integrate with any kind of messaging client, such as Facebook, WeChat, WhatsApp, Slack, Skype, or you could even build your own client. If you’ve been following our blog, you may have already seen the chatbot (Atlas) we built as part of our annual hackathon.

Here is an example conversation I had with Atlas recently:

Chatbot Conversations

Chatbots use Natural Language Processing and Machine Learning algorithms to take what the user said and match it up against pre-defined conversations. Understanding how chatbots recognize phrases can help determine what conversations a user could have with a bot. Here is some chatbot terminology:

• An intent is something the users wants, and the bot maps this to an action. For example, the user might want to say some form of “Hi” to the bot, and we would want the bot to respond with a random greeting. A chatbot generally has up to 2,000 intents.
• Utterances are examples of different phrases that represent an intent. An intent might have 10-15 utterances. The bot will be able to match statements similar to those utterances to the intent, but what a user says doesn’t have to exactly match an utterance. This is where the language processing algorithms are used.
• Entities are key variables the bot can parse from the intent.

Suppose we are building an HR chatbot that can help users reset passwords. The goal is for our bot to understand that the user needs a password reset link, and then send the correct link to the user. Our intent could be called Password Reset. Since the user could have accounts for different services, we would need to create an entity called AccountType for our bot to parse from what the user said. AccountType could map to “Gitlab”, “WebCenter”, or “OpenAir”.

As a rough design, we could start with:

• Intent: Password Reset
• Utterances:
  • I’d like to reset my password.
  • How do I change my password for Gitlab?
  • I forgot my WebCenter pw, can you help?
  • Please assist me in receiving a new password.
  • Forgot my passcode for OpenAir.
  • Give me another password.
• Entity: AccountType (Gitlab, WebCenter, OpenAir)

Intents like this one will need to be set up for a bot to know what to do when a user says something. If a user asks the bot a question it doesn’t have an intent for, it won’t know what to do and the user will get frustrated. Our bot still won’t know how to order a pizza, but it could help with password resets.

Key Factor #1: Chatbots should have a purpose

A chatbot can only answer questions it is designed to answer. If I was building an HR Help chatbot, it probably would not be able to order a pizza, rent a car for you, or check the weather. It could, for example, reset passwords, report harassment, set up a new hire, and search for policies. Once the requirements are set, developers can build, design, and test to ensure the bot has those capabilities.

This makes it important to set expectations with the user on what types of questions they can ask it, without giving the user a list of questions. Introducing a bot along with its purpose will help with this. For example, we could have the HR Help Bot, the Travel Planning bot, or the Sales Rep Info bot. If we introduced the Fishbowl Ask-Me-Anything bot, users will start asking it a lot of questions we didn’t plan for it to be able to answer.

Conversations can be more complicated than a simple back and forth, or question and answer. The capability is there (Oracle’s solution gives developers full control over a Conversational State Machine), but I have yet to explore the full capabilities.

Once a purpose and a set of intents are identified, a chatbot could be a useful tool to engage customers or employees.

Key Factor #2: Design Architecture

Bots are great for interacting with difference services. The Oracle Chatbot Cloud Service is designed to make it easy for developers to make REST API calls and database lookups in between parsing what the user says, and returning a response.

Here are a few things to think about when designing a bot’s architecture:

• Integrations: What services will the bot interact with?
• Security: Are users typing their bank account number over Facebook chat?
• Human interaction: How will the bot flip users over to a human to help when they get frustrated?
• Infrastructure: What will be on premise and what will be in the cloud?
• Performance: How to minimize network requests?

Key Factor #3: Analytics

Analytics can be used to improve the bot’s capability over time and understand the impact on the company. Some companies may already have metrics around help desk call volume or customer conversion rates, and it would be interesting to compare that data from before and after a bot’s release.

Beyond that, bot analytics will be able to show the performance of the bot. Analytics could show the top questions a bot is asked but can’t answer, how many questions it answers successfully each day, and what questions it mistook for something else. The Oracle Chatbot Cloud Service solution will have some capabilities built in, and the platform is so flexible it will be possible to gather any data about a bot.

Key Factor #4: Bot Building Best Practices

There is a lot to do when it comes to building the bot. From setting up the infrastructure, connecting all the services, and filling out all the utterances. There are some best practices to keep in mind as well.

The bot should sound like a human. Personality can play a big role in giving users a better interaction.

As users become more familiar with chatbots, there will also be a set of questions they expect every bot to be able to answer. This list might start with:

• Hi.
• What do you do?
• Are you human?
• Help!
• Tell me a joke.
• How are you?

When the bot is going to run a query or API that may take a while, it is important to warn the user in advance and echo that the bot understood what the user wanted. Some apps will also support “is typing” statuses, which is another great way to show the bot is thinking.

Key Factor #5: Testing

Users have high expectations for the intelligence level of a chatbot. They expect the Machine Learning algorithms to work well, and the bot to seem smart. If the bot doesn’t meet their expectations on the first try, they are unlikely to use the bot in the future.

Testing and tuning utterances can make the difference for making a bot seem smart. The bot should be able to accurately map what a user says to the correct intent. The Oracle Chatbot Cloud Service solution has some nice testing capabilities around utterances and intents, and making sure what the users says maps correctly.

Chatbots are another piece of software, so it is important to do performance and user testing on it as well.

Conclusion

Chatbots are a great way to tie in a single user interface to a large variety of services, or automate repetitive conversations. There are plenty of business use cases that would benefit from a chatbot, but the ROI depends on thorough requirements gathering and using analytics to optimize the bot. That being said, companies that have already started down the path – like this Accounting Firm in Minneapolis – are seeing benefits from bots automating manual processes leading to a reduction in operating costs by 25 to 40%. Savings like this will vary across use case and industry, but overall the automation gains from a bot are there regardless of what the bot is being used for. We would love to discuss your ideas on how a chatbot could help your business. Leave a comment or contact us with any questions.