Why is it STILL so hard to build a useful chatbot?
By: Blake Mcgregor
Tags: Artificial Intelligence, Chatbots, Announcements, Wa Announcement, Watson Assistant

Why is it STILL so hard to build a useful chatbot?

HINT: We’ve got a solution

Creating a familiar, efficient, and personalized customer service experience takes a lot of hard work. But, as you know, great customer service is not optional. Your customers should be able to get their questions answered (on their channel of choice) without hitting frustrating dead ends or needing to provide redundant information.

Chatbots (we call them assistants) can act as a way for you to provide this kind of familiar and personalized customer service, but building a really useful chatbot is often time consuming and costly. Across the market and even within our own dialog builder, we’ve seen the same problems come up repeatedly for those trying to launch great chatbots:

Too complicated for a non-developer to build and manage The building process focuses more on config and debugging than it does on the actual content It takes too long to build meaningful conversations that cover all of the pitfalls the user could fall into Builders often have to choose between telling the system what bits of information need to be gathered (slot filling) or authoring very explicit step by step process flows with branches It takes too long to refactor a flow when an improvement needs to be made

Announcing Actions in Watson Assistant (Beta)!

At Watson Assistant, we’re passionate about not only solving these issues, but finding a way for every assistant to be helpful and meaningful to your customers. That’s why we’ve totally re-envisioned how you build an assistant from the ground up with Actions.

1 | Anyone Can Build

Most chatbot tools are either squarely focused on a developer builder or require a PhD in a bunch of adjacent concepts (e.g. entities, slots, options, variables) to figure out how to use them. That’s why we’ve created a build experience tailored to the people talking directly to customers — like customer service agents, copywriters, product managers, or marketers. It’s easy to learn within a few minutes rather than a few months.

Now, Actions and Steps are the only two things you need to know to build an assistant. Easy as that!

What is an Action?

A problem or a task that your customer wants to resolve

Actions are modular units that contain the initial language recognition for the topic (i.e. the intent) as well as all of the steps needed to complete the action.

What is a Step?

A “back and forth” interaction between the assistant and the user

Simply put, steps represent the clarification questions or final answers in the action. Everything else that the step needs to function like the logic, the response options, or the storage of the user’s response is contained within it!

Note (if you’re a dialog user today): We’ve collapsed a lot of the concepts from our dialog skill into actions and steps without losing the flexibility that dialog provides.

2 | Content (not config) First

We believe that content (not config) is king, so we re-oriented the interface around the actual content of the conversation to help you understand what you’re actually saying to your customers.

A step’s primary focus is the rich content being shown to your customer, not the nitty gritty configuration.

And as you test your actions, you get to see exactly what your customers will end up seeing. Cool right?!

3 | 60% Faster to Build

Most chatbot tools make you think through every potential path the conversation might take. This often times leads to large, brittle tree structures that take a long time to build and perfect.

We’ve done a few things with Actions to speed up build time and reduce the number of error paths that need to be built into the system.

Reducing Redundant Concepts

Most tools (including our own dialog builder) make you build and reference redundant concepts to ask a question of the end user (e.g. button options for user assistance, entities for language recognition, variables for response storage). Actions combine all of these things into one unit automatically—we call that a step.

With steps, we’ve seen our own customers build over 60% faster than the dialog skill we have today!

Built In Error Validation

Error validation is also built into each step that asks a question of the user. This means that you no longer need to build other steps or flows to check the validity of a response, re-prompt if something goes wrong, or fail over after a few attempts.

We’ve launched with a simple validation experience and plan to expand upon this as we introduce new “response types” like date/time, number, percentage, etc…

4 | Question Skipping meets Business Process

We’ve found that most chatbot tools on the market make you choose between simply telling the system what bits of information needs to be gathered/skipped (aka slot filling) or authoring a very explicit, step by step business process with branches.

Skipping Questions

Often the user of a chatbot may mention the answer to a question in their initial ask, for example “I want to pay my cable bill.” In this case, it would be strange to next ask the user “What type of account — cable, internet, or phone?” That’s where “slot filling” comes in — it’s a feature within many chatbot platforms (including our own) that lets the system skip questions when the answer is stated up front.

Some tools emphasize slot filling as the primary or only mechanism for building a chatbot. This is often too simplistic to handle the realities of most business processes which dictate the rules the conversation needs to follow.

Here’s an example:

Slots are nice when some information is stated in the initial request — so in this case the account type (cable) is filled in advance. But imagine you need to only ask for account number in certain scenarios. Or that location only matters if the account type is “cable.” This model breaks down really quickly without the ability to serve up conditional responses.

Business Process

The tools that emphasize tree-like branching structures are easier to visualize, but often lead to either inflexible conversations or redundant content strewn about (or both).

Here’s another example:

This layout is flexible in that it allows branching based on responses at each step in the conversation. But after about 3 layers of clarification questions, the tree starts to balloon and becomes unmanageable.

Furthermore, the final answer for the internet and phone branches as well as the “account number” question are redundant. And any advance “slot filling” beyond the initial step (what type of account) is likely not happening.

Actions offers the Best of Both Worlds

The reality is that most conversation flows would benefit from mixing slot filling with explicit business rules. And that’s exactly what we’ve done with Actions in Watson Assistant.

A final example:

In this example, there are only as many steps and final answers as are truly dictated by business rules. This may seem trivial for a simple use case, but it becomes critical as additional business rules get added.

Furthermore, all of the steps (without conditions) can be skipped if the information is mentioned up front… We’re working on updating this behavior so that any step in the flow can be skipped (even those with conditions). An example like this should be possible within a few weeks time:

Let’s say a user with an IP address from Massachusetts states “I want to pay my bill for account 17635.” Given the above example image, the system would only need to clarify the account type (i.e. Cable) before responding with the final answer.

5 | Super Easy to Refactor

After you launch your assistant, it’ll undoubtedly need some updates based on real life usage. With most tools (including our own dialog skill), the process of updating is brittle and error prone. We’ve found that when a builder needs to make flow logic changes, he or she usually ends up needing to just start over with an entirely new flow.

That’s why we made it super easy to drag and drop the priority order of steps in the flow without breaking the entire action. Unlike most other tools, when you move a step to a new spot, it simply changes the priority of that step within the action, but it doesn’t break the dependencies other steps may have on it. It’s super easy to switch up the step logic if needed as well.