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

Introducing actions, a brand new way for you to build virtual assistants that will increase your time to launch, unlock team synergies, and drive improvements across every iteration

Blake McGregor
IBM watsonx Assistant
8 min readOct 28, 2020

--

We know that getting a streamlined, efficient, and personalized customer service experience up and running takes a lot of hard work. But, great customer service is not an optional in today’s marketplace. Your customers require you to answer their questions on their channel of choice without hitting frustrating dead ends or needing to provide the same information over and over again.

Your virtual assistant acts as a way for you to provide this kind of familiar and personalized customer service, but building a truly useful chatbot is time consuming and costly. Across the market and even in the evolution of our own product, we’ve seen the same problems come up repeatedly:

  1. It’s too complicated for a non-developer to build and manage.
  2. The build process focuses more on configuration and debugging than it does on the actual content.
  3. It takes too long to build meaningful conversations that cover all of the requirements in even some of the simplest use cases.
  4. Builders often need to choose between telling the system what bits of information need to be gathered (i.e. slot filling), or authoring very explicit step by step process flows with branches.
  5. Refactoring a flow takes way too long when any improvements need to be made.

Watson Assistant announces actions!

Our dual purpose is to solve the above problems, as well as make it possible for every assistant to be helpful and meaningful to your customers. That’s why we’ve totally re-envisioned how you build with Watson Assistant from the ground up with actions.

The actions editor is the focal point of the Watson Assistant build process.

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. It’s as easy as that!

What is an action?

An action is any problem or a task that your customer wants your assistant 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 in its entirety.

What is a step?

A step is the “back and forth” interaction between the assistant and your user or customer inside of an action.

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 types, or the storage of the user’s response (variables) is contained within it!

Pro-tip: 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 over configuration

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.

Each step contains a back and forth interaction between your assistant and your customer.

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

You can preview what your customer will see as you build.

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 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.

Some additional characteristics of steps.

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.

More validation options to keep the conversation on track.

We’ve launched with a simple validation experience and that introduces new “response types” like date/time, number, percentage, and the list is constantly growing.

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 (slot filling), or authoring a very explicit, step-by-step business process with branches.

Skipping questions

Chatbot users may often 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 that lets the system skip questions when the answer is stated up front.

Some products 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 an 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 in Watson Assistant.

A final example:

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.

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.

5 | Super easy to refactor

After you launch your assistant, it’ll undoubtedly need some updates based on real life usage. With most tools, 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 start over from the beginning with an entirely new flow.

Detail of step and condition builder functionality.

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.

Actions in Watson Assistant is now available for all Lite, Plus, and Enterprise customers!

If you’re ready to move forward with this exciting new way to build virtual assistants, you’re going to want to plan it for success: Check out our planning guide.

You can also skip straight to our getting started series or documentation

Happy building!

Blake McGregor is the product management leader for Watson Assistant based in NYC. Years of research amongst lots and lots of brilliant people went into this beautiful feature release, so he shall not take credit for any of this (besides writing the blog).

--

--

Blake McGregor
IBM watsonx Assistant

I love to ski, eat, travel, and eat. And in my spare time, I work in the natural language/AI space as the product management lead on IBM Watson Assistant.