User Response Flexibility Added To IBM Watson Assistant Actions
And Enhancing Medium Agnostic Conversation Design
Introduction
ON 13 January 2022 IBM launched new setting options for customer responses. This launch was in Watson Assistant Actions. The new list option setting allow users to toggle the options for customers to respond with.
So a selection list can be presented to the users or an open question with no menu guidance.
This is helpful with different mediums, like text/SMS, messaging applications, web chat or telephone integration.
As part of this change, all customer response types now have a Settings icon. Allow skipping has moved from Edit Response and is now found in the new settings.
User Input Options
The approach here by IBM Watson Assistant is to allow for flexibly in the way users can input data to a menu. The raking of the displayed options can also change. One can regard this as almost a manual version of IBM’s Watson Assistant Auto Learning.
Option ranking can be tweaked based on popularity…
As seen above, menu options can be moved up and down in the order it will be presented. Synonyms assists with menu input resilience and a light approach to built-in disambiguation.
On the far left, the use of synonyms is visible. Especially in a voice interface, an user might want to refer to the option by it’s position. In the middle Preview, the button is selected to progress the conversation. On the right, a synonym is again used.
The newly added functionality allows for the list options to not be displayed. This is especially useful for voice interfaces, but also for mediums which do not support buttons, like SMS.
A last example the buttons or options are not displayed and the user seemingly have an open menu to input their selection. This approach can also be useful to collect data on on customer speak, and how users phrase their input.
Considerations
Looking at IBM Watson Assistant Actions in general…
The Good
- IBM is simplifying the process of getting a bot to production.
- Integration to cloud call center solutions are simplified for live agent transfers.
- Integration to conversational mediums are also made easy, to mediums like SMS/text, WhatsApp, Facebook Messenger, phone integration etc.
- Actions have been improved with elements like digression, variable management, response types etc.
- Conversational topics can be addressed in a modular fashion.
- Conversational steps can be dynamically ordered by drag and drop.
- Variable management is easy and conversational from a design perspective.
- State conditions can set.
- Design and Development are combined.
- Integration with current solutions and developed products
- Formatting of conversational presentation.
The Not So Good
- Finetuning of the conversational experience is absent. Complex implementations will outgrow Watson Assistant Actions.
- Highly configurable mediation layers will be required on the mediums end of the solution and also the services integration.
- If used in isolation scaling impediments will be encountered.
- Remains a State Machine Approach to dialog management.
- Linear Design interface.
Observations
Firstly…Watson Assistant Actions will surely impress in the speed with which one can develop a prototype chatbot or voicebot conversation, with medium and live agent integration. However, as the conversation and functionality grows, finetuning will be required to the conversation.
Out of the box integration will not suffice and a mediation layer or intelligent connector will be necessitated for transfer to live agents and medium integration.
Secondly…As I have written below, Actions implemented in a way it was not intended will lead to impediments in scaling and leveraging user input in terms of intents and entities.
The initial implementation scenario for Actions was to act as an extension to Dialogs. To create quick and re-useable extensions to dialogs. These extensions can be for customer satisfaction surveys…capturing specific data etc.
Thirdly…On 7 October 2021, the new Watson Assistant experience became available. The new Watson Assistant focusses on the Dialogs approach, and integration. All new development seemingly is currently taking place here. What is referred to as the classic Watson Assistant seems to be static at this stage.
If a Dialogs approach (as seen in classic Watson Assistant) is not incorporated in the new Watson Assistant experience, scaling will always be problematic and Watson Assistant will not be favored for large implementations.
Fourthly…It seems like IBM is aligning with an Web 3.0 approach where the chatbot is very much integrated with the web, or an organizations website. And content is presented and organized according to the user’s input. With the chatbot acting as a conversational user interface in order to render the web content and media.
This is surely one implementation for a conversational agent, but there are many others. Taking a narrow approach, as it seems IBM is doing now, will have detrimental consequences in the future.
Fifthly…to democratize the access to chatbots, terms and concepts need to be simplified, and the user interface simplified. The real challenge is to do this, whilst not sacrificing functionality. As the functionality will be desperately needed as the conversational agent grows in complexity.
So how does companies maintain functionality whilst simplifying the development and management interface…there are a few examples in the market place. But it does not feel as if IBM is accomplishing it here.
A Few Key Features Of Actions
- You can think of an action as an encapsulation of an intent. An action is defined by a set of user input examples. No intents are defined, an Actions skill is an intent-less implement. A type of end-to-end approach. Deprecating the use of intents.
- An action is a single conversation to fulfill an intent and capture the entities. An conversational extension of the subject.
- A single action is not intended to stretch across multiple intents or be a horizontally focused conversation.
- Think of an action as a narrow vertical and very specific conversation.
Actions must not be seen as a replacement for dialog skills.
Actions can be used as a standalone implementation for very simple applications. Such simple implementations may include:
- Customer satisfaction surveys,
- Customer or user registration etc.
- Short and specific conversations.
Most importantly, actions can be used as a plugin or supporting element to dialog skills.
Of course, your assistant can run 100% on Actions, but this is highly unlikely or at least advisable. You will always have a collection of skills in your assistant.
The best implementation scenario is where the backbone of your assistant is constituted by one or more dialog skills, and Actions are used to enhance certain functionality within the dialog. And a search skill can be added for discovery.
This approach can allow business units to develop their own actions, due to the friendly interface. And subsequently, these Actions can then plugged into a dialog.
This approach is convenient if you have a module which changes on a regular basis, but you want to minimize impact on a complex dialog environment.
Within a dialog node, a specific action that is linked to the same Assistant as this dialog skill can be invoked. The dialog skill is paused until the action is completed.
An action can also be seen as a module which can be used and reused from multiple dialog threads.
When adding actions to a dialog skill, consideration needs to be given to the invocation priority.
How NOT To Use Actions
It does not seem sensible to build a complete digital assistant / chatbot with actions. Or at least not as a standalone conversational interface. There is this allure of rapid initial progress and having something to show. However, there are a few problems you are bound to encounter…
Conversations within an actions skill are segmented or grouped according to intents. Should there be intent conflicts or overlaps, inconsistencies can be introduced to the chatbot.
Entity management is not as strong within Actions as it is with Dialog skills. Collection of entities with a slot filling approach is fine.
For more advance conversations, where entities need to be defined and detected contextually Actions will not suffice.
Compound entities per user utterance will also pose a challenge
Compound intents, or multiple intents per user utterance is problematic.
If you are use to implementing conversational digression, actions will not suffice.
Conclusion
As mentioned before, simplification is important, but over simplification can lead to the diminishing of functionality, which in turn impedes scaling of the chatbot.
Ensuring the customization of chatbot responses based on the medium will always be relevant, but for complex enterprise-scale implementations, a coded mediation layer will be required. The services needs to be independent of each other so so that even if one service is replaced or changed, the other services can seamlessly interact with new services.
