Part II Of “Why Chatbots Can’t Read Your Mind”

Chatbots break down into two parts: the “chat” and the “bot.”

Previously, we covered “chat” and the general reasons why chatbots may misinterpret your request or have trouble understanding what you’re asking. In this post, we will cover the problems that the “bot” side of chatbots face.

For a chatbot to do what you ask of it, it must have adequate “action-taking” capabilities to fulfill your request, be it retrieving information or making a change. Broadly, this capability is best broken down into two elements: workflows and system connections.

In the chatbot context, workflows are simply the sequential actions a chatbot must do in the pursuit of fulfilling a request. They’re the manual that the chatbot follows to verify if it should execute a task and how to go about it.

System connections are the “hooks” the chatbot has into other systems. How a given chatbot goes about connecting into other systems varies depending on the given chatbot platform but broadly falls into one of four categories: in-platform connections, APIs, integrations, and intermediated or RPA-like:[i]

  • In-platform connections are the most straightforward type of system connections, where a given platform has a chatbot capability specifically designed to take actions in that platform. In effect, it’s just two parts of the same application talking.
  • “Open” APIs are probably the most common method of chatbots interacting with other systems. Usually REST/SOAP-based, “open” APIs refer to the “public” connections a given applications offers so that a secure connection can be negotiated and information transferred between applications. These types of APIs are common today but vary in what information can be transferred, their degree of preconfiguration, and strength of documentation. Most open APIs are customizable but require manual configuration for effective connections.
  • Integrations are prenegotiated connections between systems with specific connection points already configured. While they are, in some cases, simply a variation on an application’s open API, integrations are usually more plug-and-play system connection types, trading customizability for reduced manual configuration.
  • Intermediated (RPA-like) connections are the least familiar of the four categories but broadly refer to software robots that are tasked with acting as an intermediary between a chatbot and a given system, executing their own workflow and utilizing their own connections into whatever application the chatbot request designates. While this category doesn’t refer to robotic process automation (RPA) specifically, many RPA platforms are used as this intermediary, as they have a unique method of taking action in other systems, such as providing UI access to websites and internal systems (RPA is an outgrowth of early screen-scraping tech), combining with text analytics to access content in emails or documents.

In order to take a given action, a chatbot not only has to understand what you are asking but then must match that to a workflow and lastly be able to pass/retrieve information from a given system.

For example, if you say to a chatbot, “I wish to reset my password to my email,” the chatbot, using its marvelous powers of deduction, identifies that you (User A) wishes to change your password in the email system (Generic Office Suite Email). In order to help you, in the simplest of circumstances, the chatbot will have to:

  • Draw on its password reset workflow.
  • Connect into your organization’s identity and access management (IAM) platform.
  • Execute a verify-user identity task and send this information to the IAM platform to check and see if you are authorized to do this.
  • If successful, facilitate the new password creation and verify this again with your IAM platform.
  • Verify that all of this information is saved.
  • Log a completed password reset request with your record-keeping platform.
  • Communicate back to the user.

To execute a relatively simple task, the chatbot must integrate into two separate systems, in addition to having a workflow to guide it in the completion of the user task. This isn’t even considering the language processing element, which identified the task you wanted (password reset), the target system (email), and user (self, or User A).

For each task a chatbot is asked to complete, a workflow has to be developed and connections to relevant systems have to be facilitated. While some adopting organizations may be able to plug into large systems of work, like an ESM or CRM platform with predefined workflows and hooks into multiple other systems, if you want your chatbot to be a main point of contact for your organization, you need to have these chatbots be able to facilitate connections into whatever system that the work touches — and that tends to be more than you think.

While these workflows and integrations are relatively easy to develop, their sheer number can prove prohibitive. As such, many organizations are pursuing a gradual rollout of new use cases, with chatbots facilitating ticket creation for requests not yet supported.

Chatbot platform skill/workflow development will improve over time but for now remains an intensely manual effort. There are signs of more advanced functionality coming that could allow for emergent workflow development/chatbot problem solving, but today, like humans, chatbots must be taught how to do things. To compensate for this manual effort, many vendors today are building out their out-of-the-box workflow and integrations to better support the variety of demands placed on these applications, but development is still ongoing. This gap today leads to the eternally asked question: “Why can’t this stupid thing do what I want it to?”

[i] Please forgive some gross generalizations. There are exceptions of characteristics in each type of system connection.