Designing and building actions in the new Watson Assistant

IBM Watson Assistant’s new experience focuses the authoring process on conversations. Here, we look at a seasoned assistant author taking advantage of Actions for the first time.

Published in

IBM watsonx Assistant

8 min readOct 25, 2022

The new Watson Assistant experience revolves around Actions, a new way to author assistant content. Actions is the evolution of the Dialog skill from the classic experience, with a build interface organized around conversational steps. Actions consolidates elements that Dialog authors are familiar with (intents, entities, and slots) into a single page within the user interface.

In recent articles, IBM Senior Developer Dan O’Connor outlined how features from Dialog map on to Actions, and his colleague Andy Stoneberg broke down what’s changed and what hasn’t in the development of the V2 API. Today, we’ll look at a hypothetical example of a veteran assistant author building an action for the first time.

The author is a business user, not a developer, but he was part of the team that designed the company’s original assistant and has functional knowledge of all aspects of virtual assistant management. He’s written several flows independently and, although he’s comfortable authoring in Dialog, he’s researched the differences between the classic and new experiences and is ready to start experimenting with Actions.

Resolving a request

From **Conversational AI: Chatbots that work** by Andrew Freed, Chapter 3: Designing effective processes.

When developing new content for their first assistant, the customer care team reviews call center logs to determine if any common requests can be automated. Recently, the most frequent customer requests involve starting dispute-of-debit tickets for duplicate transactions.

The bank’s mobile app already features a dispute-of-debit function, but customers are still calling in disputes. While they ultimately want their users to utilize the mobile feature, the team decides to have their assistant start the dispute ticket for the user, then inform the user about the mobile function to provide a comprehensive customer-care experience.

The author is tasked with creating a conversation where the assistant guides users through opening a dispute-of-debit step by step. Starting the ticket requires the assistant to obtain the customer’s account number, the transaction number in question, and confirmation of both before opening the ticket.

The author’s goals for the conversation are:

A) Ensuring the customer can open their dispute ticket

B) Informing the user about the mobile self-service option for future disputes

C) Accomplishing A and B without escalating the conversation to a live agent

If the conversation flow is successful, the assistant will deflect the customer from the call center, create a positive association with the assistant in the mind of the user, and empower the user to self-serve in the future.

To accomplish all of that in the span of a single conversation requires not just planning, but design.

Designing the conversation

The author scripts the conversation according to the step-by-step instructions pattern. He’s written flows using this pattern several times since it’s ideal for guiding customers through financial transactions.

After reviewing several transcripts of conversations between customers and call-center agents, the author begins scripting the conversation on a white board.

The assistant begins the conversation by identifying itself and offering help to the customer. The customer submits a request for help, then the assistant asks clarifying questions and obtains confirmation on the way to a resolution.

Once the assistant opens the dispute-of-debit ticket, it alerts the user to the mobile self-serve function, asks if it can help with anything else, then closes the conversation.

Agent (A): Hi! I’m Lendyr’s virtual assistant! How can I help you today?
User (U): I was double billed on my groceries last week!
A: Got it. Would you like to open a dispute-of-debit ticket?
U: Yes please!
A: Alright, let’s get started! Please enter your Lendyr account number.
U: @account_number
A: Great, now enter the transaction number for the charge you want to dispute (tap the transaction on your mobile app to find the full transaction number)
U: @transaction_number
A: To confirm, you want to open a dispute-of-debit for <5-digit transaction number> to <8-digit account number>?
U: Yes
A: We’ve sent you an email with your ticket number. Save that number in case one of our agents contacts you with any follow up questions.
A: Do you have any questions?
U: No, I’ve got it.
A: FYI, there’s a Dispute function next to transaction logs in your Lendyr mobile app. You can use that to open a dispute-of-debit ticket if this ever happens again. <link to walk through>
Is there anything else I can help you with?
U: No thanks.
A: Alright, thanks, and have a great rest of your day!

Notice that the author has included two bits of pseudocode at lines 8 and 10 for the account and transaction numbers. These numbers will be collected and saved as variables by the assistant so it can obtain confirmation from the user before proceeding with the transaction.

This flow represents what is referred to as the “happy path”, or what conversation analysts call a “no-trouble case”, where the assistant and customer understand each other at every turn. A more comprehensive flow would account for misunderstandings and build in opportunities for to repair those misunderstandings. For this hypothetical use case, we can proceed along the happy path.

Now that the conversational flow is defined, the author is ready to start building the action in the new Watson Assistant experience.

Building the action

The author starts the build by creating a new action, titling it “I was overcharged”, and entering multiple phrases in the Customer starts with: field to train the model on different ways customers can phrase the request.

Entering several example phrases trains the assistant to recognize the end user’s intent.

He then creates a series of steps that guide the user through the ticket creation process. The first step, where the assistant asks if the user would like to open a dispute-of-debit ticket, is taken without conditions. All subsequent steps in the conversation will be taken with conditions to ensure the assistant is getting the information it needs before the conversation continues.

Conditions guarantee the assistant receives the input it needs to resolve the request.

Since the conversation requires the assistant to both confirm customer requests and obtain two different numbers, the author uses the Define response feature to set parameters for the user input. For steps requiring the user to enter account and transaction numbers, the author defines the user response type as regex, with the patterns \d{8} for account number and \d{5} for transaction number.

Actions allows you to test your regex before applying changes.

He uses the Action variables function when writing step 5, where the assistant asks for confirmation before opening the ticket. He clicks Insert a variable, then selects the answers to questions 3 and 4 from the Action variables list.

Open the Action variables modal using the rich text editor.

You can also open the Action variables modal by typing the ‘$’ symbol.

Since this step requires confirmation from the user, the author defines the response as Confirmation, chooses the button option, and sets the options to ‘Yes’ and ‘No’.

The confirmation response type means authors don’t have to create a “Yes” intent.

Once the steps are authored, the author tests his action using the preview panel. The assistant is able to successfully guide him down the “happy path” without any bugs, so he proceeds to sharing his draft content with his colleagues and adding steps to manage potential misunderstandings.

Accelerating the process

What immediately impresses our author is how he can map his conversational design onto the Actions interface, and how quickly he can replicate his conversation in the product. In a single sitting, he’s able to write out the conversation, set the appropriate conditions, and share a preview of the action with his team.

The design of the new experience, along with the range of edge cases it covers, figure to be a huge time saver for our author. He wants to author new content for his assistant with Actions going forward, but he and his team already have a significant investment of time in their existing Dialog skill.

The good news is, they don’t have to choose between the two; the author enables Dialog in the new experience and transfers his existing content via a JSON upload. This gives the team the runway to migrate to actions gradually without interrupting the performance of their live assistant.

Now the author can employ his existing content while writing new content with Actions.

Tip: Once Dialog is activated, all user input will first be routed through the Dialog skill. Consult our product documentation on calling out to Actions from Dialog.

Teaching the user

To see Watson Assistant in action, visit Lendyr.com — yes, our fictional bank has a real website where you can see the full range of Watson Assistant’s capabilities. Designed as a showcase for Watson Assistant’s web chat integration, this demo site shows an alternative to the above conversational solution; integration with WalkMe, an orientation app that guides users through step-by-step processes. Type “I need to dispute a charge” into Lendyr’s assistant and follow the prompts.